On 21. Jun 2011, at 10:51, Daniel Pfeifer wrote: > Nice. But why didn't it get a repository of its own? Maybe I > would like to install Equalizer via apt and then hack on the > Sequel source code without distraction.
Because right now it requires the latest Equalizer version due to a number of minor changes. Once it stabilizes I will separate the repositories, probably with the next release. There is also some non-trivial infrastructure work (CMake, version, packaging, etc.). > Yes, this is much needed. This is obviously the right > approach. But in my opinion it does not go far enough. It's a first incremental shot - so yes, it does not go far enough. > Is there a strong reason for not using RAII? What places are you referring to? I hope you don't want to do Application::init in the ctor, since this would break other design principles. > If you want to provide a narrow interface instead of > exposing a bunch of classes, maybe it would be a good idea > to seperate (public) headers that provide this interface > from the rest of internal source files? They are separated!? All internal stuff is in sequel/detail. >> The API documentation can be found here: [link]. I'll >> update the remaining documentation and website >> incrementally during the next weeks. > > I find it confusing that the API reference contains the > examples. Any good documentation contains examples as well > as a reference. But there should be a clear distinction. 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? > * Don't provide any 'init' functions. > * Don't provide any 'exit' functions. I don't want to do this work in the ctor/dtor. > * Don't force clients to provide 'destroy' functions. I don't. I *allow* them to provide destroy functions - or am I overlooking something? > * Don't provide boolean return values indicating success/failue. > > Classes should be initialized in the constructor and > deinitialized in the destructor. Further, anything that > needs to be initialized and/or deinitalized should be > wrapped in a class. -- RAII > > (Really) smart pointers should be able to provide reference > counting without any requirements to the pointee type > (nonintrusive). It should be possible to provide a custom > delete function. The only ref-counted object is Application which is a RefPtr since it inherits from eq::Client. That will only change when the Equalizer interface changes to shared_ptrs. > 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. > Calling multiple functions each of which provides a boolean > result value requires a cascade of if-not-successful-then-bail > checks. Using exceptions here can simplify both library and > client code by a great deal. Now we are entering religious territory. We've tried that with the runtime reliability work, and no, it does not make the code simpler or more readable. It's funny that the proponents of exceptions always bring them up, while real C++ codes use them sparingly - including boost. Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
