On 21. Jun 2011, at 18:16, Daniel Pfeifer wrote: > 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. ;) 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. >> They are separated!? All internal stuff is in sequel/detail. > > Hm. So everything not in sequel/detail is public? I see some .cpp files > there; are they part of the interface declaration? I will not separate the header from the implementation into separate directories unless one can provide new arguments. The .cpp are the implementation of the interface and tend to be trivial. >> 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? >>> * Don't provide any 'init' functions. >>> * Don't provide any 'exit' functions. >> >> I don't want to do this work in the ctor/dtor. > > This is exactly what I meant by "I am not sure whether it is a good idea to > hesitate the use of some good programming guidelines just for the sake of > consistency". > You actually DON'T have a reason, it is simply because you have always done > it like this, right? See my first paragraph above. >>> * Don't force clients to provide 'destroy' functions. >> >> I don't. I *allow* them to provide destroy functions - or am I >> overlooking something? > > Either way, the width of the interface could be reduced without the loss of > functionality. Forcing people to use boost::shared_ptr is a loss of functionality. You have to realize that I am not the extreme of 'doing things like I've always done', quite the opposite. Real-world codes often are older than 10 years and have been not always been written by good software engineers. > 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. >>> Qt windows then could be created like this: >>> return shared_ptr<QWindow>(new QWindow(), bind(&QWindow::deleteLater, _1)); >> >> Fair enough - But Sequel is far from this type of customization. > > Not as far as you might think. Using smart pointers, you could bind a deleter > that calls the appropriate destroy function of the current NodeFactory. This > would provide full compatibility to already customized NodeFactories but > would reduce the interface width for new NodeFactories by 50%! I was focusing on the Qt part. To answer your comment: 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. Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
