Yes, initializing a class in the constructor is a key element in the
RAII principle.
Which other design principles could be negatively affected by this
approach?
Reality. ;)
Not a design princible at all B-)
Apart from some initial misunderstanding on my part, there is now the
open issue that the current initialization calls virtual methods on
the same object which are overwritten in the subclass.
I see. Fixing this would be rather straight forward, but very time
consuming I guess. Nevertheless, we should remember it for the future
and strive for RAII in newly written code.
I will not separate the header from the implementation into separate
directories unless one can provide new arguments.
I know. I will bring them in due time :-)
They are separated by namespace:
API:
http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseq.html
Example:
http://www.equalizergraphics.com/documents/Developer/API/sequel/namespaceseqPly.html
Is this not clear enough a distinction?
On this page, yes. Otherwise, nope.
So what do you suggest?
Providing a documentation per component. Each component's documentation
should include sections for introduction, tutorial, reference and
examples. But this should be postponed until after the modularization
effort.
Forcing people to use boost::shared_ptr is a loss of functionality.
I could agree that it will make the code more complicated for average C
programmers. But how can it lead to loss of functionality?
Both createRenderer() and createViewData() return (dumb) pointers. I
am not suggesting to replace RefPtr by shared_ptr. I am suggesting to
use (really) smart pointers where dumb pointers are used currently.
Smart pointers are useful if the ownership of an object is not
clearly defined. They tend to encourage people to not think about
ownerships and therefore can lead to bad design. I don't see what
value a smart_ptr brings here.
Exactly what you said. The pointers returned from the above functions
do not have a clearly defined ownership (the factory should be able to
create and forget them), which makes them perfect candidates for smart
pointers.
If an object has a clearly defined ownership, pointers would bring no
value (smart or dumb), you also could use references in that case.
... you hide the
complexity in the bind which makes it harder to use and understand
for
mere mortals. You, and to a certain degree I, have no problem writing
and understanding this, but *imo* it adds nothing in clarity or
accessibility. I guess we'll never reach stable ground on this type
of
discussion, but that doesn't mean that we have a stalemate.
C'mon, this is not some Voodoo like Boost.Proto or Boost.Fusion, this
is just a lambda. Students learn stuff like that on the Bachelor level
nowadays. How low does the entry level need to be? (This is a serious
question, not meant to offend anybody.)
cheers, Daniel
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
