2009/4/5 Donny Viszneki <donny.viszneki at gmail.com>:
I nominate: SDL_UnionRect -> SDL_BoundingRect
I’ve actually got a whole treatise on naming of things and what have
you, but I think that ‘Enclose’ is an equally-good or better
candidate.
OTOH, if you know that the return type is a rect, you know it can’t
literally be the union, it must be a bounding box.
Ahh… but that assumes you know that it returns a Rect - what about
the case where someone is not so familiar with the APIs and is just
reading the code? What about the case where the programmer is tired
and forgets that ‘union’ actually means ‘enclosure’? Shakespeare once
asked 'What’s in a name?" - a whole bloddy lot, I can tell you!!!
I think I should pull my finger out and post my more lengthy (and
measured) thoughts on naming etc… Which probably won’t happen soon,
as I start a new job tomorrow and am currently in a B&B!
Another shameless plug about a C++ SDL wrapper: there exists also OSDL
(for Object-oriented Simple DirectMedia Layer), which is still in active
development (main supported platform: GNU/Linux).
OSDL is a C++ library encapsulating a lot of SDL, SDL_image, SDL_ttf,
SDL_gfx, SDL_mixer and PhysicsFS.
Personal feedback: in the course of development I have not found yet
many places where templates were really useful, except for specific
tasks like defining some generic caches or a flexible MVC framework.On the contrary, being able to rely on exception handling prooved very handy; the user code is quite shorter and more reliable. More generally, I think that having to define classes and inheritance schemes tends to result in higher-level services than raw SDL; actually the C API and a C++ API would not serve exactly the same purpose, in my opinion. For example I guess a C++ user would expect his screen surface to update (flip) smartly, depending on OpenGL being used or not. The C library may/should remain a thin abstraction layer, whereas actually most C++ libraries are bound to become game engine frameworks. Olivier. Vassilis Virvilis a ?crit : Pierre Phaneuf wrote:
On Thu, Apr 2, 2009 at 7:08 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:
No, there are not, but there already are SDL C++ bindings, I wasn’t
sure how much more functionality one might need to justify another
SDL/C++ mating, so I suggested this!
Making a razor-thin one that came standard with SDL and wouldn’t add
any build-time requirements for games would be pretty cool, I think.
You’re quite right that there are some, looking around on the library
registry on libsdl.org (and pruning the dead links):
I would add http://libwt.sourceforge.net/ also to the list.
Although libwt tries to be the Qt equivalent, build on top of SDL with
signal / slots,
widgets, layout and its own event loop, libwt does provide an
independent SDL layer (in wt/sdl*.{h,cpp})
which basically wraps the SDL in C++ and has none of the above GUI
features.
Although libwt tries to be the Qt equivalent, build on top of SDL with
signal / slots,
widgets, layout and its own event loop, libwt does provide an independent
SDL layer (in wt/sdl*.{h,cpp})
which basically wraps the SDL in C++ and has none of the above GUI features.
Furthermore:
It doesn’t do exceptions
It uses boost for surface management
it also wraps the sdlmixer
I might have seen it on libsdl.org (or if I’m mistaken and it’s not
there, you should go add it!), but I would have skipped it on the
basis of “too many features”, I was specifically restricting my list
to libraries that claimed to wrap SDL in C++, and little else.
Not at all saying your library isn’t good or anything like that!On Sun, Apr 5, 2009 at 3:34 AM, Vassilis Virvilis wrote:
I had several reasons for my point about ‘SDL++’ being written with
exceptions / ‘if you don’t use exceptions, you may as well use the
naked C’:
In practice, if a developer is more concerned about not paying the
exception overhead, then they will be integrating C SDL call directly
into their own class heirarchy; writing RAII wrappers is trivial.
Multiple methods of error handling are an ABSOLUTE no-no; providing
EITHER C-style OR exceptions reduces the complexity of your code and
improves certainty for the user. I just don’t think that adding C++
wrappers without using exceptions adds enough value to justify the
effort. If we were talking about a ‘pure’ C++ library, then, yes, I
can see the need for exception and non-exception code (but I’d still
say dual error-handling is wrong), but we’re not, we’re talking about
a C++ wrapper for a C library…
Those are both good points, I agree. I’m a bit weary of some libraries
that really go exception-happy, and you need to have try/catch blocks
at every other corner, just for normal operations, but that’s what
peer-review is for.
I agree, having Boost as a dependency would be less than ideal. As to
not being a fan of Boost… that is unfortunate, as it is the
semi-official (the main developers head-up the C++ standards
committee) future library / prototyping area for C++ standard library.
In fact, many elements of Boost have already been integrated into
TR1.
I agree that we probably don’t want to use Boost. I think if we
provided iterators for a few things where it made sense (scanlines in
a surface and pixels in a surface come to mind quickly), you’d be able
to use a bunch of C++ stuff (including Boost) with that.On Sun, Apr 5, 2009 at 4:58 AM, Edward Cullen wrote:
Ahh… but that assumes you know that it returns a Rect - what about
the case where someone is not so familiar with the APIs and is just
reading the code? What about the case where the programmer is tired
and forgets that ‘union’ actually means ‘enclosure’? Shakespeare once
asked 'What’s in a name?" - a whole bloddy lot, I can tell you!!!
A “union” is a standard mathematical concept
(http://en.wikipedia.org/wiki/Union_(set_theory) for more info), for
which that of two rectangles can be expressed as a rectangle only in
some degenerate cases. A “minimum bounding rectangle” (also often
referred to as a “bounding box” in graphics, see http://en.wikipedia.org/wiki/Minimum_bounding_rectangle) is also a
standard mathematical concept, which is what this function is actually
doing. I’m not thrilled by “enclose”, but “union” is just totally
misleading, and that is bad!
I was just proposing the extremely widely-used in graphics programming
term for what this function did (try searching for “bounding box”,
“enclose” and “enclosing” on Google Scholar, for example).On Sun, Apr 5, 2009 at 4:45 PM, Edward Cullen wrote:
Ahh… but that assumes you know that it returns a Rect - what about
the case where someone is not so familiar with the APIs and is just
reading the code? What about the case where the programmer is tired
and forgets that ‘union’ actually means ‘enclosure’? Shakespeare once
asked 'What’s in a name?" - a whole bloddy lot, I can tell you!!!
A “union” is a standard mathematical concept
(http://en.wikipedia.org/wiki/Union_(set_theory) for more info), for
which that of two rectangles can be expressed as a rectangle only in
some degenerate cases. A “minimum bounding rectangle” (also often
referred to as a “bounding box” in graphics, see http://en.wikipedia.org/wiki/Minimum_bounding_rectangle) is also a
standard mathematical concept, which is what this function is actually
doing. I’m not thrilled by “enclose”, but “union” is just totally
misleading, and that is bad!
That is excactly why I was saying that union was a bad name… I just
assumed I didn’t need to be verbose about it. (Sorry for assuming that
people on the list have some basic understanding of set theory )
I was just proposing the extremely widely-used in graphics programming
term for what this function did (try searching for “bounding box”,
“enclose” and “enclosing” on Google Scholar, for example).
Granted, bounding box is a well-defined term… I was thinking more
along the lines of a verb; in this context, I feel that ‘enclose’ is
a clearer verb than ‘bound’. If one wanted to go down the noun route
of method naming, then BoundingBox or BoundingRect would probably be
the least ambiguous choice.
As I said, I’ve got a whole lot of ideas in my head that relate to
naming that are slightly more cohessive…
Eddy> On Sun, Apr 5, 2009 at 4:45 PM, Edward Cullen <@Edward_Cullen> wrote:
Are you against using something like Boost?? I believe Boost has a very
well tested smart pointer that could effectively replace your homegrown
wrapper class.? While I’m not suggesting your code is bad, I think not
reduplicating effort would be good.? As far as I know, the Boost::shared_ptr
class is a header-only class, so you could (license allowing) merely ship
this with the wrapper.? I also believe this class is being added to C++0x,
so you could effectively phase the Boost header out over time.
Boost is real cool, however the aim is for the wrapper to be
completely self-contained (except STL). However, in the future I’d
gladly update it to std::tr1 ( as you may note, shared_ptr’s are there
already, and also fun things like tuple ).
After a really brief, shallow look, I am not very comfortable with your
surface class inheriting from a templated wrapper class.? Do you need to
inherit from it?? Unless you’re doing something far more complex than I saw,
I think you could get away without any inheritance.? In relation to the
previous question, you could instantiate and free (with a custom delete) a
boost::shared_ptr fairly effectively:
Usage for the end user must be completely self-explanatory. The reason
for multiple surface classes comes from the fact that display surfaces
are handled quite differently then draw surfaces.
How do you plan to implement ownership semantics with a free() method
in
the surface class? If you explicitly free the SDL_Surface that is used by
many of your surface classes, won’t something bad happen eventually?
A Surface class is a wrapper over a single SDL_Surface struct – hence
there will be no possibility to twice free the same surface ( the
surface will be freed in the destructor ).
I think Herb Sutter talks about how exception specifications are
generally NOT a good thing to include in your code (like you did in the
wrapper class).? Though this article is from 2002, I think at least some of
it is still relevent: http://www.gotw.ca/publications/mill22.htm
I don’t plan including exception specifications ( rationale : see
boost rationale ).On Sat, Apr 4, 2009 at 6:32 AM, Cody Miller wrote:
Another shameless plug about a C++ SDL wrapper: there exists also OSDL
(for Object-oriented Simple DirectMedia Layer), which is still in active
development (main supported platform: GNU/Linux).
OSDL is a C++ library encapsulating a lot of SDL, SDL_image, SDL_ttf,
SDL_gfx, SDL_mixer and PhysicsFS.
It’s a nice library indeed, however, with a completely differnent
approach than what I want to achieve. OSDL is not a wrapper – it’s a
platform based on SDL that also has other prerequisites. It also
provides a lot of functionality that SDL doesn’t. The wrapper I’m
trying to create differs mostly in these contextes:
extremely lightweight – header only, no dependencies except SDL and STL.
extremely portable – tested on all C++ standard conforming
compilers that compile SDL itself.
SDL 1.3 targeted and based
For example I guess a C++ user would expect his screen surface to update
(flip) smartly, depending on OpenGL being used or not. The C library
may/should remain a thin abstraction layer, whereas actually most C++
libraries are bound to become game engine frameworks.
This is the goal I’m trying to achieve – provide a interesting and
useful C++ layer handling abstractions but also default values,
without turning the headers into a graphics engine framework.On Sun, Apr 5, 2009 at 11:12 PM, Olivier Boudeville <olivier.boudeville at online.fr> wrote:
2009/4/6 Pierre Phaneuf :
Granted, bounding box is a well-defined term… I was thinking more
along the lines of a verb; in this context, I feel that ?‘enclose’ is
a clearer verb than ‘bound’. If one wanted to go down the noun route
of method naming, then BoundingBox or BoundingRect would probably be
the least ambiguous choice.
I just insist that English sucks and we should do whatever we can to
make the API easy to understand and remember, even if it means
ignoring rules like ‘use a verb to get a result’ or ‘use all nouns’.
Jonny DOn Mon, Apr 6, 2009 at 3:08 AM, Edward Cullen wrote:
On Sun, Apr 5, 2009 at 4:45 PM, Edward Cullen wrote:
)