| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> people how would I formulate in c++ a cl*** hiearchy that has to call init() in it's ctor? do I have to call myself init() in every ctor of derived cl***es? ( having a virtual call to init() from base ctor doesnt work )
<1> mozai: that seems weird..
<1> if the init function is part of derived cl***es, why don't derived constructors choose whether to call it/what to do?
<0> well, init() is a pure virtual method. It is used to initilaise "properties" and it has to be called by all derived cl***es
<0> i though i could enforce it by calling a this->init(); in base cl*** ctor
<0> but it doesn't work because the object containing init() haseb't been initialised yet
<1> well you can't. Can't you just leave it up to the constructors of derived cl***es to initialize (or not) whatever they wnt)?
<1> or is init a function that's called more than just once-off on construction?
<0> The_Vulture: I think i will have no choice :-/
<0> no, only in ctor
<0> one time deal
<0> if I do the init() approach on an individual basis in derived cl*** ctors, then I will have to use something like a hasBeenInit() flag. Because in my base clase I have "proxy" methods, that depends on object being initialised via init(), that end up calling the 'real' virtual methods
<1> not sure what you're getting at. Why even have the init function at all?
<1> it's just a requirement that the derived ctors initialize these properies in some way..
<1> what exactly are these properties? is there any reason they can't be parameters to the base cl*** ctor?
<1> thus p***ed in the init list of the derived ctor?
<0> well, the properties is a map of 'key' 'values'. Each object must load default proprs on runtime.
<0> they props can be overridden afterwards.
<0> they = these
<0> i could do without an init() funtion, i just find it 'cleaner' to call init() in the ctor then to dump the code that creates the properites
<1> I don't see how it would be cleaner.
<0> i might later decide to make init() public for example, so it is cleaner to seperate the init() logic
<1> Why don't you p*** in the properties to the base cl*** ctor?
<1> When you decide that init needs to be public (which would mean that an object can be explicitly re-initialized.. whatever that would mean), then do that.
<0> The_Vulture: I have an overloaded ctor that takes as well props as params
<0> but even that ctor must load default props as well, and override them with given ones
<0> just in case the given properities are 'incomplete'
<0> ok, so basically it has to be done manually in every derived cl***
<1> I don't see what you mean.
<1> The derived cl*** ctor should just p*** in its set of properties to the base cl*** ctor in the init list.
<0> yeah, but it has to initialize them first
<0> example prop.add("mykey","myVal')
<0> etc..
<0> then p*** that guy to the base ctor
<0> that takes a prop
<1> could just create a way of creating a prop object inline, ala boost::***ign
<2> I'd do it with an init function myself. Constructors have no way of really signifying initialisation failure.
<2> People try to do too much in constructors IMO.
<0> The_Vulture: i have no idea what boost:***ign does. I will look that up
<1> Def: Seems to me it should just be part of the nature of the base object - to have properties p***ed to it. The any base object would be properly initialized. Is there any "failure" case here that needs to be represented, or are you just making a general point?
<2> Just a general observation.
<2> And now I have to go freeze my arse off waiting for a bus home.
<0> What I thought at the beginning is that if I can do somethling like Cl*** Base{protected Properties p;Base(){this->init();} virtual init() = 0} | Cl*** Derived:Base{init(){prop.put("ee","dd");prop.put("ff",ff");p = prop;}
<1> I don't really see why that's any more benificial than doing it in a derived cl*** ctor
<1> the author of the derived cl*** still has to write the code to init the properties object..
<0> I kind of "enforce" the call to init()
<0> yes
<1> unless you need to do stuff with derived-specific propertis in the base cl*** ctor..
<0> but if he forgets to call it :-~
<1> No. Like I've said before: there's no value in an init function.
<1> He can just write it in a ctor.
<1> If he chooses not to init any properties, that's his choice.
<0> the problem is that my base methods rely on that properties to be initialsed
<1> Does your base _constructor_ rely on it?
<0> no
<1> so what's the problem with the derived ctor initializing whatever properties it wantsn to?
<1> what do you gain by putting it in a separate function?
<0> none, honestly. It is a 'clutter' matter for me.
<0> anyways, if it doesn't seem that i can enforce a call to init() so there is no purpose in having it.
<1> I don't see why there would be a purpose in having it even if you could enforce it
<1> it's just like trying to create second constructor invokation..
<1> just because it has a name ("init") doesn't make it any more meaningful/helpful/useful in getting a derived cl*** to initialize properties they could do equally well in a ctor..
<0> because the emplementor would go "hey a virtual pure initProperties()!...maybe that is where I should init the props"
<1> *shrugs*
<0> and without him needing to call it explicitly, the base cl*** would call it for him...of course he could choose not to do anything in initProperties() and shaft me anyways
<1> I still think it's just a matter of the constructor doing whatever it wants to. If that means initing some properties, fantastic.
<1> If all derived cl***es _MUST_ override properties, then I might be inclined to have it as a ctor parameter to the base cl*** forcing anything constructing a base instance (including a derived cl*** ctor) to p*** in properties
<0> I see...so no need for a isPropsInit flag this way because they would have to call teh base ctor with a prop
<1> I still don't see a need for that flag even if they don't p*** them as ctor parameters.
<1> It's up to the derived cl*** to init the properties in the ctor in order to make a complete object.
<1> If they don't, then it just means they didn't have any properties they wanted to initialize.
<0> you know, just to make sur that the props have been initialised. I could also of course check the m_props member for non null
<0> The_Vulture: they have to initialize default properties.
<1> I thought the defaults were provided by the base cl***..
<0> no, the defaults are loaded by each and every derived cl***
<1> each derived cl*** has different defaults?
<0> yes
<1> I thought you meant the base cl*** provided some defaults, and each derived cl*** overrode some or all of them..
<1> Can property values change throughout the life of an instance in this hierarchy? or after construction are they meant to be fixed in stone?
<0> nah. each child cl*** initilize it's own defaults. If you p*** a prop to the ctor then these props override the default ones.
<0> The_Vulture: the properties can change at any timr
<1> *shrugs* then I don't see any reason not to just leave it entirely up to the derived ctor.
<0> evetually that is what is going to happen. I just though I could enforce the dervied cl***es to iniate the default props because it is critical for them to do so.
<1> having a separate function is no more "enforcing" the requirement than having them do it in the ctor.
<1> if you wanted to be overly heavy-handed you could take the base-cl*** parameter option I outlined previously.. but whatever
<0> no, but being able to call derived->initProps() from base::ctor() would have been nice
<1> *shrugs*
<1> I don't think it would have been, but that's just me.
<0> lol, ok
<0> i will do it such as the base ctor only takes a prop object, as you suggested, so as the drivers have to provide a prop object
<0> ****, that would't work. because the ctor of the base cl***, the one that takes the props is called before the ctor of the derived cl***, the one that created the props!!
<1> that's why I said you'd need a way to initialize props inline..
<1> so when you write the derived cl*** ctor you could do something like: Derived() : Base(props()("foo", "bar")("baz", "wombat")...) { }
<1> I think boost's ***ign library has something for that already
<0> I see. I will take at that boost:***ign, or let it go, and not enforce anything at all
<0> they derived cl***es have to initialise the parameters, and if they don't...too bad. I think i might be thinking too much about this for nothing
<0> so the ctor of derived cl*** would create a new prop object, fill it in, and then ***ign m_prop to prop
<1> if you're still on the base cl*** parameter idea then no..
<1> he derived cl*** creates temporary properties objec inline, I showed one way this migth be done (boost::***ign provides something similar to what I suggested, I believe..)
<1> p***ing it straight to the base cl*** ctor
<1> which then uses the value to init the properties..
<0> The_Vulture: what you personaly advise? an inline initialised object p***ed to base ctor? or derived ctor initilises in body and sets the member m_prop to the property created?
<0> ...and base ctor isn't enforced
<1> I'd probably have the derived ctor do it. What type is m_prop?
<0> my own properties object. Wraps around a map
<1> oh, and do these derived cl***es actually have different functions, or they just have different sets of properties?
<0> same fucntion signatures, different props, different methd implementations
<1> so there are some virtual functions that are overriden and actually have real changes in behaviouR?
<0> yes
<0> example: Open() Cl*** D might do : devicedriver.open(prop.get("port")) while cl*** E might do : iplayer.connect(prop.get("ipaddress"))
<0> Open is a pure virtual
<1> what is it that this common base provides? where do you use it polymorphically/why?
<1> seems a bit too general to be useful..
<0> the common base provider is for example. readerDevice
<1> ok, so some kind of stream system.. more or less.
<0> yes
<0> it streams the same type of data
<1> I don't see the value in having a generic properties system for that.
<3> does it have any value
<0> through different "hardware"
<3> hmmmmm
<1> it's just asking for breakage when someone messes up the properties.
<3> so instead of Pi it is sh
<1> no type safety to unsure properties have the right types, no safety to ensure the right set of properties is specified, etc.
<3> is there any chivos in here
<0> Well, the properties I made the generic mainly because I will receive the properties from a Java application
<1> why not just have each derived cl*** have real member variables to represent these things?
<1> if you're using Java - why not use the Input/OutputStream concept..
<3> why not have the tiger and lion be one
<1> seems to be what you're trying to do (ok, your IO migh be a bit higher level, but could use a similar concept)
<3> the heap
<3> gotta remember the heap
<0> The_Vulture: there is type checking and range checking, etc... I just didnt mention it as not to complicate matters
<1> snoop_1: are you contributing anything constructive at this point?
<3> I think that I am
<0> the fact is that the initProperties() also load properties "domains"
<1> mozai: Yes, but even with such checking, it's runtime & suchlike, rather than compile time.
<0> yes, it is runtime
<3> hmmmmm
<1> why not do it all nicely at compile time by just having real member variables..
<3> of course while the program is running
<3> because it is registered
<1> snoop_1: do be quiet
<3> and the block is not external
<3> that is why
<3> rand not internal
<0> because I want to do it generic enough so I don't have to say DeviceOne.setPort = "1". Instead i rather say. Reader.setProperties(prop); and reader is my base cl***
<3> it is none
<3> sounds like you dont like crashes
<3> that should work
<0> so my code can still work if i change the reader device
Return to
#c++
or
Go to some related
logs:
#chat-world
punjabi nicks
#allnitecafe
#allnitecafe
#allnitecafe
lesbooooooo
#allnitecafe
genseng plants
#india
#india
|
|