Am Dienstag, den 21.06.2011, 12:24 +0200 schrieb Stefan Eilemann
<[email protected]>:
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.).
Piece of cake. I did something similar for a much larger project (~100
components).
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.
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?
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.
Hm. So everything not in sequel/detail is public? I see some .cpp files
there; are they part of the interface declaration?
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?
On this page, yes. Otherwise, nope.
* 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?
* 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.
* 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.
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.
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%!
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.
bool foo()
{
if(!bar())
return false;
if(!baz())
return false;
return true;
}
vs.
void foo()
{
bar();
baz();
}
Which one is simpler and more readable? Please show me the code in
Boost or the C++ standard libraries where a boolean return value
indicates success.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
