Discussion:
Effective use of C++ exceptions
(too old to reply)
Robert Segal
2005-05-12 21:10:52 UTC
Permalink
I've been reading various reviews of using exceptions in C++. Some for and
some against, has anyone here used them with reasonable success? If so how
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all that
beneficial. However a part of me wonders if I'm missing out on something by
not making use of them?
Phlip
2005-05-12 21:32:17 UTC
Permalink
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for and
some against, has anyone here used them with reasonable success? If so how
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all that
beneficial. However a part of me wonders if I'm missing out on something by
not making use of them?
Exceptions decouple an object's error handling from its clients. They
may call the object's methods secure in the knowledge that if
something goes wrong they won't live long enough to need to worry
about it.

The other good news is C++ exceptions are incredibly difficult for a
large project to get right. All code should be written with the
expectation that any intermediate state must roll back to a valid
state. The /Exceptional C++/ books by Herb Sutter cover all these
topics.

Also, when game developers profile their code, the overhead of the
exception handling code becomes noticable. Guess what game developers
typically do then. ;-)
--
Phlip
Jon Watte
2005-05-12 22:07:35 UTC
Permalink
Post by Phlip
Also, when game developers profile their code, the overhead of the
exception handling code becomes noticable. Guess what game developers
typically do then. ;-)
Exceptions make sense IF you believe that you can "fix" whatever
went wrong. However, for real-time systems like games, there's some
question about whether you really can or not.

Some compilers, like MSVC, actually emit code for try/catch blocks,
which makes exceptions slower. Other compilers, like CodeWarrior,
emit no extra code, but emit rather large walk-back tables, so that
the right thing can happen, should an exception actually be thrown.

Cheers,

/ h+
Peter
2005-05-12 21:54:06 UTC
Permalink
I think they have a place in tools, but not in game engines. Part of my
objection is pragmatic - it's actually NOT easy to write exception
handlers. I think that they easily give an illusion of a simple,
comprehensive solution to the problem of handling error conditions. But
in a game engine it's pretty rare to have errors that are that easily
dealt with.
In a tool or non-game application it's often an acceptable solution
if you can prevent too much loss of data and give the user a chance to
restart an operation. It's more important to preserve the integrity of
his data than it is to keep running. Exceptions make it easier to
trigger graceful shutdown, or to offer the user some choices about how
to handle a problem.
In a game, you don't want the user to know about any errors. Errors
must be prevented (if serious) or ignored if possible - for example, if
you're out of sound channels, you can drop gunshot sounds but you'd
better find a way to play any voice-over that gives important
information to the player. So you need much more specific error
handlers. I don't think the C++ exception handler syntax offers an easy
way to do that. And I find the syntax ugly, too - it doesn't make it
easier to read the algorithms. And it's slow... And it bloats your code...

Peter
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for and
some against, has anyone here used them with reasonable success? If so how
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all that
beneficial. However a part of me wonders if I'm missing out on something by
not making use of them?
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Scott Henderson
2005-05-12 22:45:02 UTC
Permalink
I agree with Peter! I use C++ exceptions in almost every tool I write.
It's great for saving important data if an error occurs and relaying
error information. In our exporters it's crucial that objects and
materials get setup properly and we use exceptions and ::MessageBox() to
relay what's wrong to our artist. So when they break the Spec the
information is right there in front of them without having to bother
me...:)

Peter...
"So you need much more specific error handlers. I don't think the C++
exception handler syntax offers an easy way to do that."

You can create different types of exceptions inherited off
std::exception or you own base class, and "catch" those specific
exceptions at runtime and handle those cases differently. Is that what
you meant?


Scott

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Peter
Sent: Thursday, May 12, 2005 5:54 PM
To: sweng-***@midnightryder.com
Subject: Re: [Sweng-gamedev] Effective use of C++ exceptions

I think they have a place in tools, but not in game engines. Part of my
objection is pragmatic - it's actually NOT easy to write exception
handlers. I think that they easily give an illusion of a simple,
comprehensive solution to the problem of handling error conditions. But
in a game engine it's pretty rare to have errors that are that easily
dealt with.
In a tool or non-game application it's often an acceptable solution
if you can prevent too much loss of data and give the user a chance to
restart an operation. It's more important to preserve the integrity of
his data than it is to keep running. Exceptions make it easier to
trigger graceful shutdown, or to offer the user some choices about how
to handle a problem.
In a game, you don't want the user to know about any errors. Errors
must be prevented (if serious) or ignored if possible - for example, if
you're out of sound channels, you can drop gunshot sounds but you'd
better find a way to play any voice-over that gives important
information to the player. So you need much more specific error
handlers. I don't think the C++ exception handler syntax offers an easy
way to do that. And I find the syntax ugly, too - it doesn't make it
easier to read the algorithms. And it's slow... And it bloats your
code...

Peter
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for
and some against, has anyone here used them with reasonable success?
If so how did you make use of them? If you didn't make use of them,
why not?
Post by Robert Segal
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all
that beneficial. However a part of me wonders if I'm missing out on
something by not making use of them?
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder
.com
Peter
2005-05-12 23:12:21 UTC
Permalink
Post by Scott Henderson
Peter...
"So you need much more specific error handlers. I don't think the C++
exception handler syntax offers an easy way to do that."
You can create different types of exceptions inherited off
std::exception or you own base class, and "catch" those specific
exceptions at runtime and handle those cases differently. Is that what
you meant?
yes - it can be a big job to design all the exception types and to
structure your code so that everything throws the right thing (and
everything above catches and handles it correctly). It seems to me that
the C++ system is designed to do two things: first (and really maybe the
most important) to allow you to fairly easily deal with cleaning up
objects as you bail out of a scope, and secondly to propagate error
reports up to fairly generic handlers that allow the problem to be
resolved. In a game, I think you usually can (and should) deal with
failures locally in the code where it happens. Many failures are fatal
and can't be handled; they need to be solved during development. The
ones you can solve often need to know a lot about the context of the
error. That needlessly complicates the objects you're throwing - it's
easier to handle it right in the scope where it happens.
Kyle Wilson
2005-05-12 23:39:07 UTC
Permalink
Post by Robert Segal
I've been reading various reviews of using exceptions in C++.
Some for and
some against, has anyone here used them with reasonable success?
I would dearly love to use exceptions in games, but the benefits just don't
justify the costs on the current generation of hardware. When we turned off
exception handling on MechAssault 2, the game got about 1% faster and our
memory usage dropped by 740K. The memory difference, particularly, is a
really big price for console developers to pay for cleaner error-handling
and the ability to return errors from constructors.

I think that when we're developing for the PS/4 and the Xbox 720, the
advantages of error codes over exceptions will be a lot less compelling.
And if we're using Visual C++/CLI then, we may have to handle exceptions
thrown by the CLR anyway. In the meantime, writing exception-safe code is
always good practice, wherever the expense is tolerable. There's not that
much functional difference between failing with an error result and throwing
an exception. You don't want to leak resources in either event.

Regards,
Kyle
Luis Villegas
2005-05-13 00:16:40 UTC
Permalink
Peter mentioned something very important, IMHO the main issue is not
only that exception handlers are hard to write, but that writing
exception safe code in general is hard:

- You need to make sure everybody on your team understands exception
safety and understands how to write exception safe code.
- Your code needs to follow an RAII approach in order to behave
correctly when exceptions are thrown. Note also that copying objects
around needs to be safe in the presence of exceptions (i.e. copy
constructors and assignment operations)
- The components of the engine need to be designed keeping in mind what
are exceptional conditions, and what are expected error conditions.

The benefit is that in exceptional conditions your application is on a
consistent state and the application can respond accordingly; in real
time software most exceptional conditions are fatal and there is nothing
you can do.

As far as runtime performance goes in consoles and embedded systems the
cost might be prohibitive (or exception support might not even be
there), on PCs it might be more sustainable (I think at some point I
heard that 64bit processors would make the cost even higher but do not
remember the details), and it is very unlikely that exceptions are the
bottleneck on your code, but then again it is a cost to be paid with
very little justifiable benefit. Note also that most of the cost is
there when exceptions are thrown, which should not happen often.

Measuring runtime performance of exceptions on an engine is hard since
you go into the chicken and egg problem; you need to design your engine
with exceptions in mind in order to measure the cost of exceptions, and
then if you are using exceptions incorrectly you pay a higher price, but
it is not because exceptions are expensive but because are not being
used for exceptional situations only.

The Exceptional C++ series of books cover the requirements for designing
and implementing code with exceptions in mind.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Peter
Sent: Thursday, May 12, 2005 2:54 PM
To: sweng-***@midnightryder.com
Subject: Re: [Sweng-gamedev] Effective use of C++ exceptions

I think they have a place in tools, but not in game engines. Part of my
objection is pragmatic - it's actually NOT easy to write exception
handlers. I think that they easily give an illusion of a simple,
comprehensive solution to the problem of handling error conditions. But
in a game engine it's pretty rare to have errors that are that easily
dealt with.
In a tool or non-game application it's often an acceptable solution
if you can prevent too much loss of data and give the user a chance to
restart an operation. It's more important to preserve the integrity of
his data than it is to keep running. Exceptions make it easier to
trigger graceful shutdown, or to offer the user some choices about how
to handle a problem.
In a game, you don't want the user to know about any errors. Errors
must be prevented (if serious) or ignored if possible - for example, if
you're out of sound channels, you can drop gunshot sounds but you'd
better find a way to play any voice-over that gives important
information to the player. So you need much more specific error
handlers. I don't think the C++ exception handler syntax offers an easy
way to do that. And I find the syntax ugly, too - it doesn't make it
easier to read the algorithms. And it's slow... And it bloats your
code...

Peter
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for
and
Post by Robert Segal
some against, has anyone here used them with reasonable success? If so
how
Post by Robert Segal
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all
that
Post by Robert Segal
beneficial. However a part of me wonders if I'm missing out on
something by
Post by Robert Segal
not making use of them?
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder
.com
Tom Plunket
2005-05-13 00:33:59 UTC
Permalink
Post by Luis Villegas
Peter mentioned something very important, IMHO the main issue
is not only that exception handlers are hard to write, but
I would say the same if it hadn't been said already many times.
:)
Post by Luis Villegas
- Your code needs to follow an RAII approach in order to
behave correctly when exceptions are thrown. Note also
that copying objects around needs to be safe in the presence
of exceptions (i.e. copy constructors and assignment
operations)
I don't know that true RAII is necessary, but I do know that
you've got to tear down your objects properly, and not
initializing them properly will make that difficult if not
impossible. ;)
Post by Luis Villegas
- The components of the engine need to be designed keeping in
mind what are exceptional conditions, and what are expected
error conditions.
This is actually the root of my apprehension about the addition
of exception handling to a game engine. What is an exceptional
condition in games? I mean, we have to handle everything. You
can't just throw up an error box and shut down if the player
pulls controller 1 out of the machine. If you get a CD read
error, you can't well print an error message and abort, either.

I am aligned with the other respondent who said that you've
really got to handle everything locally. I feel very strongly
that errors can not propogate through the system; the file
loader should deal with read errors by retrying a few times.
The model loader should deal with missing assets by putting in
obviously-bad models. The controller code should handle the
missing controller by zeroing the inputs and then waiting for a
reconnect (or hunting for the next controller, depending on
your design requirements). Etc.

Then there are things like normalizing a zero-length vector, or
any number of other degenerations that we see regularly enough
to write "assert()" in. These aren't exceptional either, these
are programming errors, and should probably be handled with
code fixes in the first place, not handling exceptions
generated because of errant code.
Post by Luis Villegas
The benefit is that in exceptional conditions your application
is on a consistent state and the application can respond
accordingly;
I've found in my own development that exceptions are fun to use
and throw, but that the code isn't really any more readable
because of them. Again, I don't want a texture load failure to
throw an exception that causes the model I'm trying to load to
not come in. I just want the missing texture to be noted in
the log, and have something obviously-wrong on-screen.
Post by Luis Villegas
...in real time software most exceptional conditions are fatal
and there is nothing you can do.
I disagree, but only because I don't think there's anything
exceptional (or at least, there shouldn't be) about anything
that happens inside the game engine.
Post by Luis Villegas
As far as runtime performance goes in consoles and embedded
systems the cost might be prohibitive...
Until people can show to me that there's a high degree of
probability that everyone on my team can write exception-safe
code in their sleep, I don't care about the performance
implications. ;)
Post by Luis Villegas
The Exceptional C++ series of books cover the requirements
for designing and implementing code with exceptions in mind.
I would agree. It was Herb Sutter's writing that made me
consider the use of exceptions in games to generally be a Bad
Thing in the first place, if only that it was so hard for the
Common Programmer to understand. I mean, if people still
forget to revoke or implement copy semantics for their objects
that need it (or even worse, implement them explicitly for
objects that don't need it), then how can we expect them to
implement their objects in an exception safe manner?

-tom!
Luis Villegas
2005-05-13 00:26:36 UTC
Permalink
BTW - Also note that the C runtime does not provide rich information
about exceptions (i.e. file, function, line, callstack), which makes
them less than ideal for debugging purposes.

It is possible to write an exception hierarchy that contains this
information but this makes throwing exceptions cumbersome.

The .NET framework provides rich context information for exceptions,
which makes exceptions more powerful and incredibly useful for debugging
purposes.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Luis Villegas
Sent: Thursday, May 12, 2005 5:17 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions

Peter mentioned something very important, IMHO the main issue is not
only that exception handlers are hard to write, but that writing
exception safe code in general is hard:

- You need to make sure everybody on your team understands exception
safety and understands how to write exception safe code.
- Your code needs to follow an RAII approach in order to behave
correctly when exceptions are thrown. Note also that copying objects
around needs to be safe in the presence of exceptions (i.e. copy
constructors and assignment operations)
- The components of the engine need to be designed keeping in mind what
are exceptional conditions, and what are expected error conditions.

The benefit is that in exceptional conditions your application is on a
consistent state and the application can respond accordingly; in real
time software most exceptional conditions are fatal and there is nothing
you can do.

As far as runtime performance goes in consoles and embedded systems the
cost might be prohibitive (or exception support might not even be
there), on PCs it might be more sustainable (I think at some point I
heard that 64bit processors would make the cost even higher but do not
remember the details), and it is very unlikely that exceptions are the
bottleneck on your code, but then again it is a cost to be paid with
very little justifiable benefit. Note also that most of the cost is
there when exceptions are thrown, which should not happen often.

Measuring runtime performance of exceptions on an engine is hard since
you go into the chicken and egg problem; you need to design your engine
with exceptions in mind in order to measure the cost of exceptions, and
then if you are using exceptions incorrectly you pay a higher price, but
it is not because exceptions are expensive but because are not being
used for exceptional situations only.

The Exceptional C++ series of books cover the requirements for designing
and implementing code with exceptions in mind.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Peter
Sent: Thursday, May 12, 2005 2:54 PM
To: sweng-***@midnightryder.com
Subject: Re: [Sweng-gamedev] Effective use of C++ exceptions

I think they have a place in tools, but not in game engines. Part of my
objection is pragmatic - it's actually NOT easy to write exception
handlers. I think that they easily give an illusion of a simple,
comprehensive solution to the problem of handling error conditions. But
in a game engine it's pretty rare to have errors that are that easily
dealt with.
In a tool or non-game application it's often an acceptable solution
if you can prevent too much loss of data and give the user a chance to
restart an operation. It's more important to preserve the integrity of
his data than it is to keep running. Exceptions make it easier to
trigger graceful shutdown, or to offer the user some choices about how
to handle a problem.
In a game, you don't want the user to know about any errors. Errors
must be prevented (if serious) or ignored if possible - for example, if
you're out of sound channels, you can drop gunshot sounds but you'd
better find a way to play any voice-over that gives important
information to the player. So you need much more specific error
handlers. I don't think the C++ exception handler syntax offers an easy
way to do that. And I find the syntax ugly, too - it doesn't make it
easier to read the algorithms. And it's slow... And it bloats your
code...

Peter
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for
and
Post by Robert Segal
some against, has anyone here used them with reasonable success? If so
how
Post by Robert Segal
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all
that
Post by Robert Segal
beneficial. However a part of me wonders if I'm missing out on
something by
Post by Robert Segal
not making use of them?
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder
.com
_______________________________________________
Sweng-gamedev mailing list
Sweng-***@lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
Tom Plunket
2005-05-13 00:44:21 UTC
Permalink
Post by Luis Villegas
BTW - Also note that the C runtime does not provide rich
information about exceptions (i.e. file, function, line,
callstack), which makes them less than ideal for debugging
purposes.
That's why you put a breakpoint inside your base exception
ctor, e.g. "__asm int 3" or "asm("break 0");" or whatever.
Then you have all of the information you could ask for.

Alas, you can do the same for your assert macro, or simply
write code that doesn't require either of them in the first
place... (Yeah, I know it's heresy, but I also know it's
possible.)

[wow that's an amazing amount of quoted material!]

-tom!
Luis Villegas
2005-05-13 01:28:36 UTC
Permalink
Inline...

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Tom Plunket
Sent: Thursday, May 12, 2005 5:34 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions
Post by Luis Villegas
Peter mentioned something very important, IMHO the main issue
is not only that exception handlers are hard to write, but
I would say the same if it hadn't been said already many times.
:)
Post by Luis Villegas
- Your code needs to follow an RAII approach in order to
behave correctly when exceptions are thrown. Note also
that copying objects around needs to be safe in the presence
of exceptions (i.e. copy constructors and assignment
operations)
I don't know that true RAII is necessary, but I do know that
you've got to tear down your objects properly, and not
initializing them properly will make that difficult if not
impossible. ;)

[Luis] Partially agree :-). There are a lot of problems by not doing
true RAII, the init/terminate idiom is error prone, having calls to
"terminate object" inside destructors is error prone, composites are
problematic. But I also understand that true RAII is hard to implement,
in C++ objects that throw during construction never existed, and
constructors for composites are hard to get right and to be exception
safe for true RAII.
Post by Luis Villegas
- The components of the engine need to be designed keeping in
mind what are exceptional conditions, and what are expected
error conditions.
This is actually the root of my apprehension about the addition
of exception handling to a game engine. What is an exceptional
condition in games? I mean, we have to handle everything. You
can't just throw up an error box and shut down if the player
pulls controller 1 out of the machine. If you get a CD read
error, you can't well print an error message and abort, either.

I am aligned with the other respondent who said that you've
really got to handle everything locally. I feel very strongly
that errors can not propogate through the system; the file
loader should deal with read errors by retrying a few times.
The model loader should deal with missing assets by putting in
obviously-bad models. The controller code should handle the
missing controller by zeroing the inputs and then waiting for a
reconnect (or hunting for the next controller, depending on
your design requirements). Etc.

Then there are things like normalizing a zero-length vector, or
any number of other degenerations that we see regularly enough
to write "assert()" in. These aren't exceptional either, these
are programming errors, and should probably be handled with
code fixes in the first place, not handling exceptions
generated because of errant code.

[Luis] There are certain things that can be handled locally, and then
you can argue that those things are exceptional or not exceptional
depending on the design. Your design might support trying reads
multiple times in case a read failed, then that becomes non exceptional,
but then you encounter an exceptional case when the max retry count has
been exceeded. What do you do? Do you show a dialog box from your
reading code? (In that case the design has added coupling between the UI
and IO component), do you use error codes and propagate error codes up?
(In such case you are emulating exception propagation using an error
prone technique), you can use exceptions and decouple the reporting from
the reporting code (Being UI or something else), or you can just do
nothing and halt the game which is what happens in many exceptional
cases for console games and that is when they freeze (If you cannot even
load your data for displaying any UI then there is nothing you can do),
in PC you can go back and use the WIN32 APIs to report the problem.
Post by Luis Villegas
The benefit is that in exceptional conditions your application
is on a consistent state and the application can respond
accordingly;
I've found in my own development that exceptions are fun to use
and throw, but that the code isn't really any more readable
because of them. Again, I don't want a texture load failure to
throw an exception that causes the model I'm trying to load to
not come in. I just want the missing texture to be noted in
the log, and have something obviously-wrong on-screen.

[Luis] This is an exceptional case for a shipped game, the customer is
not going to be happy by seeing something obviously-wrong on-screen.
Your texture loader might return a default texture on DEBUG to make
testing easier and to unblock the different disciplines during
development, but it might throw and exception on RELEASE.
Post by Luis Villegas
...in real time software most exceptional conditions are fatal
and there is nothing you can do.
I disagree, but only because I don't think there's anything
exceptional (or at least, there shouldn't be) about anything
that happens inside the game engine.


[Luis] Game engines are data driven systems, load and operate on
external data. The engine can get into a state (For internal or
external factors) in which it cannot access the data or in which the
data loaded is bogus, you do not think this is exceptional? The fact
that exceptional conditions can be handled via different techniques
(i.e. error codes) and that the engine can respond to those error codes
in different ways does not make these conditions less exceptional. IMHO
Exceptional conditions are subject to be defined during design, and
different games could consider different situations exceptional
depending on how much they degrade the user experience or how much
functionality is lost by the exceptional case.
Post by Luis Villegas
As far as runtime performance goes in consoles and embedded
systems the cost might be prohibitive...
Until people can show to me that there's a high degree of
probability that everyone on my team can write exception-safe
code in their sleep, I don't care about the performance
implications. ;)

[Luis] Agreed, developer education is one of the biggest problems.
Post by Luis Villegas
The Exceptional C++ series of books cover the requirements
for designing and implementing code with exceptions in mind.
I would agree. It was Herb Sutter's writing that made me
consider the use of exceptions in games to generally be a Bad
Thing in the first place, if only that it was so hard for the
Common Programmer to understand. I mean, if people still
forget to revoke or implement copy semantics for their objects
that need it (or even worse, implement them explicitly for
objects that don't need it), then how can we expect them to
implement their objects in an exception safe manner?

[Luis] Agreed :-)

-tom!
Javier Arevalo
2005-05-13 02:02:22 UTC
Permalink
Post by Luis Villegas
[Luis] Partially agree :-). There are a lot of problems by not doing
true RAII, the init/terminate idiom is error prone, having calls to
"terminate object" inside destructors is error prone, composites are
problematic.
I strongly disagree with this. In my last project we used init/terminate
heavily, but the guidelines for that in our coding standards were probably
half a page. I would estimate that debugging and fixing badly written
init/term and resource leakages accounted for less than 1% of our total
debugging time - much better than I expected. The team was not very
experienced, so this might just be the effect of enforcing a discipline (ANY
discipline), but the fact remains that we saw absolutely no bad side
effects, while the benefits in resource allocation and error handling
patterns were very real.

If you think, as described in
http://sourceforge.net/docman/display_doc.php?docid=8673&group_id=9028 ,
that the true nature of RAII is to guarantee _deallocation_ during
_termination_ (RTID), then we were definitely doing RTID. However, your
comment about terminating objects in destructors being error prone does not
point in this direction. :)

As far as exceptions go... as others have pointed out, they just don't seem
very useful in a game engine, few people have solid experience with them,
and they can cost resources. Lots of pain for little gain.

---
Javier Arévalo
http://www.iguanademos.com/Jare
Tom Plunket
2005-05-13 03:18:17 UTC
Permalink
Post by Luis Villegas
Post by Tom Plunket
I don't know that true RAII is necessary, but I do know that
you've got to tear down your objects properly, and not
initializing them properly will make that difficult if not
impossible. ;)
Partially agree :-). There are a lot of problems by not
doing true RAII, the init/terminate idiom is error prone,
having calls to "terminate object" inside destructors is
error prone, composites are problematic.
Oh, I didn't mean to imply that RAII is anything other than The
One True Way, because I most certainly believe that it is.
However the autistic engineer pedant in me just wanted to say
that true RAII isn't necessary for proper exception handling.
I don't even believe that exception handling would be easier in
true RAII systems. There are a lot of things that /do/ benefit
from RAII though, and those things are the reason why I'm a
fan.


-tom!
Luis Villegas
2005-05-13 01:41:17 UTC
Permalink
In such case you are translating the C++ exception mechanism to the
structured exception handling mechanism, which is not platform agnostic.

And not only do you need to add this to the exception ctor but you also
need to have an strategy for catching, handling, and reporting these
user breakpoints when you give the build to your test team.

No asserts? Heresy!!! Heresy!!!!

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Tom Plunket
Sent: Thursday, May 12, 2005 5:44 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions
Post by Luis Villegas
BTW - Also note that the C runtime does not provide rich
information about exceptions (i.e. file, function, line,
callstack), which makes them less than ideal for debugging
purposes.
That's why you put a breakpoint inside your base exception
ctor, e.g. "__asm int 3" or "asm("break 0");" or whatever.
Then you have all of the information you could ask for.

Alas, you can do the same for your assert macro, or simply
write code that doesn't require either of them in the first
place... (Yeah, I know it's heresy, but I also know it's
possible.)

[wow that's an amazing amount of quoted material!]

-tom!
Luis Villegas
2005-05-13 03:20:01 UTC
Permalink
Very interesting.

What I mean with true RAII is that objects allocate resources on construction, deallocate/destruct resources on destruction, and after the constructor has been executed the object has fully constructed all the internal resources it would need. Partially constructed objects (which are the objects that have to call init to be fully constructed) do not fall in the category of true RAII in my definition.

And to make sure I clarify what I am trying to say here, I am not saying that the init idiom should never be used, I am saying that it is error prone and that RAII makes life easier, but at the same time I am acknowledging that writing correct RAII code is challenging and it works best in the presence of exceptions for which designing and writing code is also challenging.

Why I thing init/terminate is error prone? (Item E.3.5.1 from "The C++ Programming Language"):

- Could forget to call init
- Could forget to test the return of init
- Could forget that init might throw (Not really an issue if you are not using exceptions)
- Could end up using the object before calling init

The following code snippets depict the issues:

SomeClass obj1, obj2;

if (obj1.init() && obj2.init())
{
// operate on obj1 and obj2
obj1.operation1();
obj2.operation1();

obj1.terminate();
obj2.terminate();
}
else
{
// What do we do here?
}

// Somewhere in a cpp
bool SomeClass::init()
{
bool success= false;

m_pointer= new (std::nothrow) bla();

if (m_pointer!=NULL)
{
success= true;
}

return success;
}
void SomeClass::operation1()
{
assert(m_initialized);

if (m_initialized)
{
// perform operation
}
else
{
// What do we do here?
}
}

// assume destructor calls terminate which deallocates

Or:

SomeClass obj1, obj2;

obj1.operation1();
obj2.operation1();

// Somewhere in a cpp
SomeClass::SomeClass() :
m_pointer(new bla()); // throws on memory allocation failure
{}

void SomeClass::operation1()
{
// perform operation
}

// assume destructor deallocates


The second case seems more natural and less error prone to me, note also that mixing classes that require init with classes that do not require init makes even easier to forget to call init on the classes that require it.

For a code base of 20,000 lines of code or more which is supposed to last over the next 5 years and which might end up being modified by over 30 different programmers over that time period I would rather have and enforce true RAII than enforcing the init idiom. And with a lot of discipline the init idiom (and its variations) has been used successfully and will still be used successfully but it is still error prone.

Until exceptions become widely understood, until the cost of having them becomes negligible in PC, Consoles, and other devices (i.e. phones), until compiler support is uniform for exceptions, until we can get rich data from thrown exceptions, until then we are stuck with variations of the init patterns and we need to make sure we are disciplined enough to ship products using them.

Most of the successful languages that have evolved from C++ have taken exceptions to a new level and are forcing developers to think more seriously about them (i.e. Java and C#)

BTW - Some examples of how challenging it could be to write exception safe code under true RAII take a look at: http://www.gotw.ca/gotw/066.htm

Thank you,
Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com [mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com] On Behalf Of Javier Arevalo
Sent: Thursday, May 12, 2005 7:02 PM
To: sweng-***@midnightryder.com
Subject: Re: [Sweng-gamedev] Effective use of C++ exceptions
Post by Luis Villegas
[Luis] Partially agree :-). There are a lot of problems by not doing
true RAII, the init/terminate idiom is error prone, having calls to
"terminate object" inside destructors is error prone, composites are
problematic.
I strongly disagree with this. In my last project we used init/terminate
heavily, but the guidelines for that in our coding standards were probably
half a page. I would estimate that debugging and fixing badly written
init/term and resource leakages accounted for less than 1% of our total
debugging time - much better than I expected. The team was not very
experienced, so this might just be the effect of enforcing a discipline (ANY
discipline), but the fact remains that we saw absolutely no bad side
effects, while the benefits in resource allocation and error handling
patterns were very real.

If you think, as described in
http://sourceforge.net/docman/display_doc.php?docid=8673&group_id=9028 ,
that the true nature of RAII is to guarantee _deallocation_ during
_termination_ (RTID), then we were definitely doing RTID. However, your
comment about terminating objects in destructors being error prone does not
point in this direction. :)

As far as exceptions go... as others have pointed out, they just don't seem
very useful in a game engine, few people have solid experience with them,
and they can cost resources. Lots of pain for little gain.

---
Javier Arévalo
http://www.iguanademos.com/Jare
Luis Villegas
2005-05-13 03:22:41 UTC
Permalink
Understood, I am a fan and a sinner. A fan for loving and preaching the
concept, a sinner for not being able to apply it in practice in C++ (C#
on the other hand....)

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Tom Plunket
Sent: Thursday, May 12, 2005 8:18 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions
Post by Luis Villegas
Post by Tom Plunket
I don't know that true RAII is necessary, but I do know that
you've got to tear down your objects properly, and not
initializing them properly will make that difficult if not
impossible. ;)
Partially agree :-). There are a lot of problems by not
doing true RAII, the init/terminate idiom is error prone,
having calls to "terminate object" inside destructors is
error prone, composites are problematic.
Oh, I didn't mean to imply that RAII is anything other than The
One True Way, because I most certainly believe that it is.
However the autistic engineer pedant in me just wanted to say
that true RAII isn't necessary for proper exception handling.
I don't even believe that exception handling would be easier in
true RAII systems. There are a lot of things that /do/ benefit
from RAII though, and those things are the reason why I'm a
fan.


-tom!
Tom Plunket
2005-05-13 03:27:27 UTC
Permalink
Post by Luis Villegas
Understood, I am a fan and a sinner. A fan for loving and
preaching the concept, a sinner for not being able to apply
it in practice in C++ (C# on the other hand....)
Success with RAII comes easily with three words:

Test-Driven Development

:)

-tom!
Kelly Brock
2005-05-13 05:15:08 UTC
Permalink
Post by Tom Plunket
Post by Luis Villegas
Understood, I am a fan and a sinner. A fan for loving and
preaching the concept, a sinner for not being able to apply
it in practice in C++ (C# on the other hand....)
Test-Driven Development
Amen! :)

KB
Latimerius
2005-05-13 13:03:41 UTC
Permalink
Post by Robert Segal
I've been reading various reviews of using exceptions in C++. Some for and
some against, has anyone here used them with reasonable success? If so how
did you make use of them? If you didn't make use of them, why not?
Exceptions have largely remained an obscure feature of C++ to me and I
haven't really read any great arguments to suggest they would be all that
beneficial. However a part of me wonders if I'm missing out on something by
not making use of them?
My opinion is admittedly PC-centric.

I can see basically just one strong argument against exceptions - their
run-time overhead. However, compilers are adopting more efficient
implentations of exception handling and for example gcc (and some
others) already use the zero-cost scheme that IIRC doesn't impose any
run-time overhead by trading it for some space overhead. This deal
should be almost always acceptable on PC's where time is a more precious
resource compared with space. I don't have any direct experience with
consoles.

On the other hand, my experience tells me that, simply put, either you
use exceptions or you don't (consistently) handle errors at all. Status
codes aren't an option as it is too painful to check them consistently
and systematically and even if you do that, you turn your code to an
unreadable mess. Moreover, it's impossible in C++ to use status codes
in a lot of functions (constructors are a widely known examples but e.g.
some operators (typically [] and others) are no much different).

It bugs me that complexity of code using exceptions is routinely
accounted to the C++ exception mechanism. This doesn't seem right. The
thing is that dealing with errors (deciding what to do in case of error
and how to do it right) is *inherently* hard, regardless of the
mechanism you use for implementing your error-handling policy. C++
exceptions seem hard and status codes seem great mostly just because
status codes allow you to ignore the issue whenever you don't feel like
solving it (i.e. much of the time), while exceptions tend to force you
to deal with it.

Also, you can't escape writing exception-safe code completely anyway
since the language itself throws.

As for the C++ exceptions' intelectual overhead - exceptions are no hot
new feature so I would say not understanding them is rather intolerable
for any self-respecting professional C++ developer. ;-)

Just my $.02, anyway.

latimerius
Crosbie Fitch
2005-05-13 14:02:36 UTC
Permalink
I suspect the problem with exceptions is that they appear to be a panacea to
whose who would do away with status codes.

The problem is not exceptions per se, but their liability for misuse.

Perhaps exceptions should be considered a æruntime-assertÆ?

Normal asserts enable you to assert your assumptions concerning your logic,
algorithms, and function parameters - for which you are entirely in control.

Exceptions enable you to assert realistic assumptions concerning the
environment and that your interface contracts will not be broken.

A rule IÆm inclined to adopt is that you should never throw an exception
that could not be avoided by a more rigorous use of your API - unless the
sky truly has fallen. And the corrolary to this is that try/catch blocks
should be regarded as exceptional a practice as the use of goto.

Asserts and exceptions are UNEXPECTED failures. No-one should be forced to
design their code to EXPECT them.
Scott Shumaker
2005-05-13 18:47:21 UTC
Permalink
-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com] On
Behalf Of Crosbie Fitch
Sent: Friday, May 13, 2005 7:03 AM
To: 'sweng-***@midnightryder.com'
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions
Post by Crosbie Fitch
Asserts and exceptions are UNEXPECTED failures. No-one should be forced to
design their code >to EXPECT them.

This is the salient point, in my opinion. I have seen a large number of
libraries that throw exceptions as a matter of course (when a routine
operation fails, like connecting to a remote socket). If there's an API
function that has a decent chance of failure, it should return a status code
and be handled by the program. Do you really want CopyFile to throw an
exception if the copy fails? :)

Exceptions should be infrequently used when there's a real chance for
recovery, and used more as a means to achieve a graceful exit. In a game
environment, it's only when something goes horribly awry that you should
have to deal with exceptions. For example, in the middle of a file read the
file system goes away (a drive on a networked PC, for example). In tools,
there's potentially more use for them, because the user doesn't expect a
seamless experience and you probably already have plenty of error-reporting
mechanisms in place. That said, even on tools they can be problematic, as
it's often difficult to debug where the error occurred (if a high-level
exception handler catches it). And having exceptions without garbage
collection is also problematic.

In tools, my rule of thumb is to never just 'throw' an exception, but rather
to always throw through a specific function (so you have one access point
for the point of failure, and you can add additional stuff to the function,
like ASSERTs in debug builds, logging, etc).

On a console, where you technically have control of the entire user's
system, exceptions probably have less value. There's very little that can
happen that's out of your control. Even if you encounter something like a
damaged disc, you have to retry at least a few reads before giving up and
displaying a failure message. Even then, you want to be able to continue if
the user cleans the disc and puts it back in.

Scott
cruise
2005-05-16 08:22:10 UTC
Permalink
In a standard signal/messaging system of a game, you have a specific game object
and method that can be called for a particular message, either via callback, or
preset message->method mappings.

However, when the game objects are constructed from properties (ie. Game Object
1 has Health=100, Model=data/model.shp, etc.) then there is no actual code
associated with that object, simply a list of values. If a message is sent to
this object, what handles it?

I can see two options. One, "properties" can include actual classes, so you
could have a "SignalHandler" class created and assigned to an object as one of
it's properties. Two, have a global "SignalHandler" function that deals with all
messages, doing whatever needs to be done to the objects addressed.

I can see issues with both, and I'm wondering if there's an accepted way of
dealing with this, and situations like it.

Thanks.
--
[ cruise / casual-tempest.net / transference.org ]
"quantam sufficit"
Jon Watte
2005-05-16 16:12:36 UTC
Permalink
Post by cruise
However, when the game objects are constructed from properties (ie. Game Object
1 has Health=100, Model=data/model.shp, etc.) then there is no actual code
associated with that object, simply a list of values. If a message is sent to
this object, what handles it?
Typically, at least one of the properties will be a reference to code.
That reference could be to some default classes ("dumb rock" etc), or
to some composite of behaviors. That reference could also be to a script,
and the script figures out what (if any) host code to call.

Cheers,

/ h+
Daniele Benegiamo
2005-05-16 11:12:09 UTC
Permalink
Post by Scott Henderson
-----Original Message-----
Behalf Of Crosbie Fitch
Sent: Friday, May 13, 2005 7:03 AM
Subject: RE: [Sweng-gamedev] Effective use of C++ exceptions
Post by Crosbie Fitch
Asserts and exceptions are UNEXPECTED failures. No-one should be forced to
design their code >to EXPECT them.
This is the salient point, in my opinion. I have seen a large number of
libraries that throw exceptions as a matter of course (when a routine
operation fails, like connecting to a remote socket). If there's an API
function that has a decent chance of failure, it should return a status code
and be handled by the program. Do you really want CopyFile to throw an
exception if the copy fails? :)
Yes. I think that exceptions must be evaluated also about the
simplification that them use can apply to source code. Compare the
following code (hypothetic class Socket used to receive 100 bytes
client-side, designed without exceptions and with them, assuming smart
pointers):
SocketPtr client = Socket::create_new ();
if (client == NULL)
{
// Error!
}

Socket::error_code err =
client->init (Socket::ip4 (127, 0, 0, 1), Socket::port(1234));
if (err != 0)
{
// Error!
}

err = client->connect ();
if (err != 0)
{
// Error!
client.close ()
}

char buf [100];
err = client->receive (buf, 100);
if (err != 0)
{
// Error! (err)
client.close ()
}

err = client->close ();
if (err != 0)
{
// Error! (Maybe less important...)
}

<<<

char buf [100];
try
{
Socket::create_new (Socket::ip4 (127, 0, 0, 1),
Socket::port(1234))->connect ()->receive (buf, 100);
}
catch (Socket::error_code err)
{
// Error! :)
}
catch (...)
{
// Error!
}
I think the second form is more simple to write, mantain and debug...


Daniele.
Luis Villegas
2005-05-13 19:15:31 UTC
Permalink
->Asserts and exceptions are UNEXPECTED failures. No-one should be
forced to
->design their code to EXPECT them.

What do you mean exactly?

Do you mean that in the presence of an exception the system should not
care about proper cleanup?

Do you mean that the developer should not worry about program behavior
in the presence of exceptions?

Luis Villegas
Crosbie Fitch
2005-05-13 21:50:27 UTC
Permalink
Post by Luis Villegas
->Asserts and exceptions are UNEXPECTED failures. No-one should be
forced to
->design their code to EXPECT them.
What do you mean exactly?
Do you mean that in the presence of an exception the system
should not care about proper cleanup?
Not at all. Exceptions are fine for what they are, and it should be possible
to catch them cleanly. I'm just arguing that they should be reserved for
exceptional circumstances - and not merely as a 'more convenient' mechanism
for handling expected failures.
Post by Luis Villegas
Do you mean that the developer should not worry about program
behavior in the presence of exceptions?
Yes, pretty much, but with some qualification.

If the developer is developing software that _expects_ to generate or
encounter exceptional circumstances (that ordinary software would not), then
sure, they may well need to try-catch their 'exceptionally stressful' code.

However, a developer utilising a well designed API will have all the
necessary mechanisms for catering for _expected_ failures in the API itself,

I'm suggesting that exceptions /could/ be generated for expected failures,
but only because the user of the API has failed to test for these failures
via the mechanisms provided via the API. In other words, an expected failure
that the user has failed to handle, indeed has carried on regardless, can
legitimately be escalated to an exception. But, no API should oblige the
user to utilise exceptions to handle expected failures - the user should
always be provided with non-exception generating mechanisms to ascertain
them.
Luis Villegas
2005-05-13 22:38:28 UTC
Permalink
If I am understanding correctly then what you are trying to get at is
that lower level APIS should not force the user to catch exceptions in
order to process different error conditions. It should be configurable.

What is interesting is that different languages take this concept
further to different directions. i.e. Java forces to catch exceptions
specified in the API which becomes cumbersome for situations that the
application does not consider the situation exceptional, .NET has APIs
that allow you test return codes or catch exceptions using different
member functions and in the exception case you are not forced to catch
the exception specified (there are some examples of this in the IO
namespace). In C++ you can make the design choice as long as the code
is in your control.

If your low level APIs require exception handling then the code for
expected errors (non exceptional cases) becomes painful and ugly to
write:

// My function to connect to a database
// Retry for X minutes every Y number of seconds (pseudo-code)
void func()
{
bool try_again= true;

while(try_again)
{
try
{
// Call external low level API for which I have
no control
connect_to_database();
}
catch(const database_connection_exception &ex)
{
// Log retry
// Sleep
if (timeout_exceeded)
{
try_again= false;
}
}
}
}

In such cases exceptions become structures for control flow for
non-exceptional cases. As I mentioned on an earlier post, IMHO
exceptional cases are domain specific, and having a configurable API as
you mentioned would make code that deals with expected error conditions
cleaner. Since most of the low level APIs out there favor return codes
then it would be easy to write wrappers that are configurable and throw
exceptions on application specified cases.

I would disagree about not having to worry about exceptions on the
design side (in C++ at least), in C++ due to construction semantics you
have to worry about the way you design your classes, the way they are
constructed, and the way they get cleaned up. RAII helps you make
everything cleaner for the client code, but the classes have to provide
well defined exception safety semantics and guarantees which means that
you need to worry about the way you are building your class library.

Luis Villegas




-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Crosbie Fitch
Sent: Friday, May 13, 2005 2:50 PM
To: 'sweng-***@midnightryder.com'
Subject: [Sweng-gamedev] RE: [Sweng-gamedev] Effective use of C++
exceptions
Post by Luis Villegas
->Asserts and exceptions are UNEXPECTED failures. No-one should be
forced to
->design their code to EXPECT them.
What do you mean exactly?
Do you mean that in the presence of an exception the system
should not care about proper cleanup?
Not at all. Exceptions are fine for what they are, and it should be
possible
to catch them cleanly. I'm just arguing that they should be reserved for
exceptional circumstances - and not merely as a 'more convenient'
mechanism
for handling expected failures.
Post by Luis Villegas
Do you mean that the developer should not worry about program
behavior in the presence of exceptions?
Yes, pretty much, but with some qualification.

If the developer is developing software that _expects_ to generate or
encounter exceptional circumstances (that ordinary software would not),
then
sure, they may well need to try-catch their 'exceptionally stressful'
code.

However, a developer utilising a well designed API will have all the
necessary mechanisms for catering for _expected_ failures in the API
itself,

I'm suggesting that exceptions /could/ be generated for expected
failures,
but only because the user of the API has failed to test for these
failures
via the mechanisms provided via the API. In other words, an expected
failure
that the user has failed to handle, indeed has carried on regardless,
can
legitimately be escalated to an exception. But, no API should oblige the
user to utilise exceptions to handle expected failures - the user should
always be provided with non-exception generating mechanisms to ascertain
them.
Crosbie Fitch
2005-05-14 09:32:16 UTC
Permalink
Post by Luis Villegas
I would disagree about not having to worry about exceptions
on the design side (in C++ at least), in C++ due to
construction semantics you have to worry about the way you
design your classes, the way they are constructed, and the
way they get cleaned up. RAII helps you make everything
cleaner for the client code, but the classes have to provide
well defined exception safety semantics and guarantees which
means that you need to worry about the way you are building
your class library.
Don't get me wrong, I'm all for writing exception-safe code as standard
practice. I meant that the user shouldn't have to worry about exceptions
being thrown AND having to handle them, unless of course, they're expecting
to operate in the abnormal realms of exceptional circumstances.

There's a quid pro quo though: All good coders should write exception
friendly classes, but then all good coders should provide
non-exception-raising mechanisms to signal expected errors .


Raising an exception should be the equivalent of:

0) I have encountered an unexpected and exceptional situation
1) This API has provided the caller with every means possible to pre-empt
this exception if it could have been expected and avoided
2) There is no failsafe action I can take
3) I have no means of indicating failure
4) That the current situation has occurred is good cause to lose confidence
in system integrity and/or safe continued exection of the current program.
To continue would be worse than to abort.
5) I will signal that the program should abort
Robert Blum
2005-05-14 18:54:34 UTC
Permalink
While conceptually agree with those statements(*), I have a question
rooted in the reality of messy APIs - Let's assume I have a data
loader that imports a 3rd party format that is quite complex.

As a result, the loader has quite a call graph to show when executed.
Failure, of course, occurs in the leaf nodes. While it's technically
not that exceptional to have bad data in a file, exceptions are a
trivial way to bounce that information up all the way - and I thought
that's another area where they are applicable: non-local flow control.

Of course, I might just think that because I'm an old fart and have
seen and used setjmp/longjmp. Any ideas/suggestions/war stories how
to handle that situation cleanly and exceptionless?

- Robert
Post by Crosbie Fitch
0) I have encountered an unexpected and exceptional situation
[... rest snipped ...]
Crosbie Fitch
2005-05-14 19:58:34 UTC
Permalink
When I said try/catch should be as rare as goto I actually wanted to say as
rare as setjmp/longjmp, but thought I'd stick to something a little more
familiar. :)

I'm not anti-exceptions, I'm just trying to say how I believe they are
misused.

In the example you give, it's likely that there are still ways to achieve
the same result with failure codes, but typically, that would result in
messier code.

As I tried to say earlier, IF you know you are going to bring your use of an
API into exceptional circumstances, then you can exploit exception handling
- that's a decision for the caller - in this case one that the caller
believes results in a cleaner, more elegant solution.

All, I'm saying is that the callee should not oblige the caller to catch
exceptions.
Post by Scott Henderson
-----Original Message-----
Sent: 14 May 2005 19:55
[Sweng-gamedev] Effective use of C++ exceptions
While conceptually agree with those statements(*), I have a
question rooted in the reality of messy APIs - Let's assume I
have a data loader that imports a 3rd party format that is
quite complex.
As a result, the loader has quite a call graph to show when
executed.
Failure, of course, occurs in the leaf nodes. While it's
technically not that exceptional to have bad data in a file,
exceptions are a trivial way to bounce that information up
all the way - and I thought that's another area where they
are applicable: non-local flow control.
Of course, I might just think that because I'm an old fart
and have seen and used setjmp/longjmp. Any
ideas/suggestions/war stories how to handle that situation
cleanly and exceptionless?
Crosbie Fitch
2005-05-16 13:32:47 UTC
Permalink
Post by Daniele Benegiamo
char buf [100];
try
{
Socket::create_new (Socket::ip4 (127, 0, 0, 1),
Socket::port(1234))->connect ()->receive (buf, 100); } catch
(Socket::error_code err) {
// Error! :)
}
catch (...)
{
// Error!
}
I think the second form is more simple to write, mantain and debug...
As long as this 'Socket' API permits use without having to catch exceptions,
that's fine. You then have the choice of using this idiom, rather than being
forced to.
Latimerius
2005-05-16 13:44:24 UTC
Permalink
Post by Crosbie Fitch
Post by Daniele Benegiamo
char buf [100];
try
{
Socket::create_new (Socket::ip4 (127, 0, 0, 1),
Socket::port(1234))->connect ()->receive (buf, 100); } catch
(Socket::error_code err) {
// Error! :)
}
catch (...)
{
// Error!
}
I think the second form is more simple to write, mantain and debug...
As long as this 'Socket' API permits use without having to catch exceptions,
that's fine. You then have the choice of using this idiom, rather than being
forced to.
But couldn't the same be said about the status codes approach, vice
versa? I.e. the API shouldn't force me to plow through status code
checking (as demonstrated by Daniele).

Actually, I don't think that every API should support both idioms (it's
sometimes not even possible to report errors through a return value, as
I pointed out before). It might be better for the API author to decide
what makes more sense for the API in question, and support the chosen
idiom.

latimerius
Kyle Wilson
2005-05-16 14:43:52 UTC
Permalink
Post by Latimerius
But couldn't the same be said about the status codes approach, vice
versa? I.e. the API shouldn't force me to plow through status code
checking (as demonstrated by Daniele).
Status codes are functionally identical to exceptions, with a few exceptions
(no pun intended).

The advantages of exceptions are:
* Exceptions can be thrown where status codes can't be returned (in
constructors and functions returning references)
* Exceptions automatically are passed up the stack until they're handled
* Exception-handling allows unified treatment of your own errors and errors
in exception-throwing standard library functions (std::new, stream >>
operators, etc.)

The advantages of status codes are:
* Prettier/more intuitive syntax
* More control over performance/memory overhead

That's it. If your code isn't exception-safe, then it won't behave well in
the presence of status code-indicated failure, either. Your preference for
exception handling or status codes will depend on the relative weights you
give to the items listed above.

Kyle
Charles Nicholson
2005-05-16 15:24:28 UTC
Permalink
Post by Kyle Wilson
* Exceptions automatically are passed up the stack until they're handled
I think the biggest difference between status codes & exceptions is
that when ignored, status codes do the 'wrong' thing- nothing! A
status code of "massive failure" will go unnoticed by a programmer
whose code doesn't explicitly check for it. It can be hard to find
these _lacks_ of checks, until you're in a debugger following up on a
bug report and you see the return code of the function in the 'auto'
pane of dev studio :). Ideally, you'd crash as close as possible to
the error spot.

Exceptions are much more aggressively defensive, in the spirit of
"make it very hard to do the wrong thing"- by default the program
terminates! Errors are known much more immediately, and that's a good
thing. If you're fortunate enough to work on a platform with SEH, you
can get much more rich information (full call stack at time of
would-be crash, even on null ptr dereferences or other 'oops' moves).

Alexandrescu outlined another approach in the CUJ a few months ago
(the article was named "3 micro-ideas" or something similar),
something along the lines of much more active return codes that assert
if you don't investigate them:

(disclaimer- code is off the top of my head, it may nuke your hard drive)

-------------------------------------------------------
class IgnoreError {};

template< typename T >
class ErrorCode
{
public:
ErrorCode(const T& code) : code_(code), read_(false) {}
ErrorCode(const ErrorCode& rhs) : code_(rhs.code_), read_(rhs.read_)
{
rhs.read_ = true;
}

~ErrorCode() { assert(read_); }

operator T() const { read_ = true; return code_; }
operator IgnoreError() const { read_ = true; return IgnoreError(); }

private:
mutable bool read_;
T code_;

ErrorCode& operator =(const ErrorCode&);
};
-------------------------------------------------------

Usage is like this:

-------------------------------------------------------
ErrorCode< int > Foo() { return S_OK; }

void Bar()
{
// normal usage
if (Foo() == S_OK) ....

// intentional ignore
(IgnoreError) Foo();

// this will assert at runtime
Foo();
}
-------------------------------------------------------

The uniform syntax for ignoring error codes is good too because they
are easily found with search.

chas
Post by Kyle Wilson
Post by Latimerius
But couldn't the same be said about the status codes approach, vice
versa? I.e. the API shouldn't force me to plow through status code
checking (as demonstrated by Daniele).
Status codes are functionally identical to exceptions, with a few exceptions
(no pun intended).
* Exceptions can be thrown where status codes can't be returned (in
constructors and functions returning references)
* Exceptions automatically are passed up the stack until they're handled
* Exception-handling allows unified treatment of your own errors and errors
in exception-throwing standard library functions (std::new, stream >>
operators, etc.)
* Prettier/more intuitive syntax
* More control over performance/memory overhead
That's it. If your code isn't exception-safe, then it won't behave well in
the presence of status code-indicated failure, either. Your preference for
exception handling or status codes will depend on the relative weights you
give to the items listed above.
Kyle
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Tom Plunket
2005-05-16 19:32:58 UTC
Permalink
Post by Charles Nicholson
Post by Kyle Wilson
* Exceptions automatically are passed up the stack until
they're handled
I think the biggest difference between status codes &
exceptions is that when ignored, status codes do the 'wrong'
thing- nothing!
I find that "not-ignorable return code" to be interesting from
an academic viewpoint, but I do see it forcing things on the
people using your API that they may not want forced upon them.

Ignoring status return codes could be a bug, but it could be
intentional as well; maybe you don't care if a function fails
or not. Ignoring a failing return code, but then carrying on
as if the failure didn't happen is a bug to be sure.

Making status return codes "unignorable" is a decision that
needs to be made very carefully by the API designer. It may
just be that I don't care if a file failed to open or a surface
failed to lock, and I may also be just fine if file access
silently fails or render calls do nothing; if it was truly
important to me that the operation succeeded, I would check the
return codes.

I take the suggestion as "defense against poor co-workers,"
because problems that would have been obvious had a status code
been noticed are problems all the same, but someone was too
lazy to consider that a given function might fail for some
reason. However, you're still not protected from the case
where someone checks against one particular error code but not
others. This is akin to the problem one would have in
comparing values as "equal to true", where presumably anything
that's not "SUCCESS" is a failure, but checking against only
"SPECIFIC_FAILURE_49" leaves a potential hole there for other
error codes to not be noticed. Are those cases bugs though?
Maybe not, maybe it's fine that the device is still unattached,
or that a call to try to reattach some device fails because the
device isn't quite ready yet...

I dunno- I'm meandering, but I do feel strongly that API
designers shouldn't force me to think that their set of failure
conditions are all fatal. Personally speaking, I use a broad
range of techniques including failure codes and objects marked
as "bad" in my own code, but also tend to make the code that
follows resilient to the fact that something I'm working with
may actually be in a state other than "everything's ok."


-tom!
Mat Noguchi (BUNGIE)
2005-05-16 15:43:31 UTC
Permalink
Here's an interesting question then: How many ways does standard C++
handle out of memory conditions?

MSN
-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Kyle Wilson
Sent: Monday, May 16, 2005 7:44 AM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] RE: [Sweng-gamedev] Effective use of C?++
exceptions?
Post by Latimerius
But couldn't the same be said about the status codes approach, vice
versa? I.e. the API shouldn't force me to plow through status code
checking (as demonstrated by Daniele).
Status codes are functionally identical to exceptions, with a few
exceptions
(no pun intended).

The advantages of exceptions are:
* Exceptions can be thrown where status codes can't be returned (in
constructors and functions returning references)
* Exceptions automatically are passed up the stack until they're handled
* Exception-handling allows unified treatment of your own errors and
errors
in exception-throwing standard library functions (std::new, stream >>
operators, etc.)

The advantages of status codes are:
* Prettier/more intuitive syntax
* More control over performance/memory overhead

That's it. If your code isn't exception-safe, then it won't behave well
in
the presence of status code-indicated failure, either. Your preference
for
exception handling or status codes will depend on the relative weights
you
give to the items listed above.

Kyle
Kyle Wilson
2005-05-16 16:40:56 UTC
Permalink
Post by Mat Noguchi (BUNGIE)
Here's an interesting question then: How many ways does standard C++
handle out of memory conditions?
As far as I know, two. The std::new operator throws std::bad_alloc if an
allocation fails. The nothrow version of std::new, as well as malloc,
calloc and realloc, return NULL if an allocation fails.

Kyle
Crosbie Fitch
2005-05-16 15:57:00 UTC
Permalink
Post by Kyle Wilson
* Exceptions can be thrown where status codes can't be
returned (in constructors and functions returning references)
This is one of the biggest culprits for exception misuse in my book.

"Oh, neat! I always wanted to be able to return a success/failure code from
a constructor. Now, with exceptions, I can do so..."
Post by Kyle Wilson
:-(
There is a good reason why constructors don't have return values. They
aren't EXPECTED to fail.

Sure, you may need to throw exceptions in constructors, but that should not
oblige the caller to wrap normal construction in a try/catch block - unless
of course, the caller was using the 'wait until the shit hits the fan, then
rewind' idiom rather than the 'if you look before you leap you'll be safe'
one.


So if there's a class like this:

class OpenFile
{
OpenFile(const char* name) throw(x)
{ if (can't open file)
throw Failure;
}
};

I'd like to see a method like this:

static bool Openable(const char* name);

Failing that, an alternative class like this:

class File
{ File();
bool Open(const char* name) // May still throw unexpected
failures, e.g. 'out of memory'
{ ...
return success;
}
};
Tom Plunket
2005-05-16 19:14:08 UTC
Permalink
Post by Crosbie Fitch
Post by Crosbie Fitch
"Oh, neat! I always wanted to be able to return a
success/failure code from a constructor. Now, with
exceptions, I can do so..."
There is a good reason why constructors don't have return
values. They aren't EXPECTED to fail.
Sure thing- however it is also possible to consider a world
where a constructor fails to do something key for the object,
so instead of throwing an exception, you create a "dead"
object.
Post by Crosbie Fitch
Sure, you may need to throw exceptions in constructors, but
that should not oblige the caller to wrap normal construction
in a try/catch block...
I would agree.
Post by Crosbie Fitch
class OpenFile
{
OpenFile(const char* name) throw(x)
{
if (can't open file)
throw Failure;
}
};
static bool Openable(const char* name);
class File
{
File();
bool Open(const char* name) // May still throw unexpected
failures, e.g. 'out of memory'
{ ...
return success+ADs-
}
};
Both of those options can be wrapped up in a factory function
on File, as well. E.g.

class File
{
public:
static File* Open(const char* filename)
{
if (IsOpenable(filename))
return new File(filename);
else
return NULL;
}

// etc. functionality
};

void TestFunction()
{
File* myFile = File::Open(filename);
}

-tom!
Mat Noguchi (BUNGIE)
2005-05-16 16:54:08 UTC
Permalink
There is also set_new_handler, which demonstrates another way of
handling errors: in cases of expected failure, e.g. running out of
memory or losing connection with a remote device, propagate the error to
another object directly rather than through an exception mechanism.

MSN
-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Kyle Wilson
Sent: Monday, May 16, 2005 9:41 AM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] RE: [Sweng-gamedev] Effective use of C?++
exceptions?
Post by Mat Noguchi (BUNGIE)
Here's an interesting question then: How many ways does standard C++
handle out of memory conditions?
As far as I know, two. The std::new operator throws std::bad_alloc if
an
allocation fails. The nothrow version of std::new, as well as malloc,
calloc and realloc, return NULL if an allocation fails.

Kyle
Luis Villegas
2005-05-16 18:29:26 UTC
Permalink
I agree that this is source of exception misuse, but moving construction
to a different "init" function is also exception misuse. Once you move
construction to an init function it means that you are willing to live
with partially constructed objects and all the problems that come with
them and with no gain since you are already supporting exception
handling and you will still have to catch exceptions during
initialization.

OpenFile is a good example of a low level API that does not know if the
situation is exceptional for the client and that allows the client to
handle the problem in different ways. I have seen implementations where
the client can choose to construct IO objects choosing different
functions, some throw, some do not throw. The client makes the choice,
but I imagine that implementing a dual construction API that supports
exceptions and the init idiom can become very painful especially in a
middleware environment.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Crosbie Fitch
Sent: Monday, May 16, 2005 8:57 AM
To: 'sweng-***@midnightryder.com'
Subject: [Sweng-gamedev] RE: [Sweng-gamedev] RE: [Sweng-gamedev]
Effective use of C?++ exceptions?
Post by Kyle Wilson
* Exceptions can be thrown where status codes can't be
returned (in constructors and functions returning references)
This is one of the biggest culprits for exception misuse in my book.

"Oh, neat! I always wanted to be able to return a success/failure code
from
a constructor. Now, with exceptions, I can do so..."
Post by Kyle Wilson
:-(
There is a good reason why constructors don't have return values. They
aren't EXPECTED to fail.

Sure, you may need to throw exceptions in constructors, but that should
not
oblige the caller to wrap normal construction in a try/catch block -
unless
of course, the caller was using the 'wait until the shit hits the fan,
then
rewind' idiom rather than the 'if you look before you leap you'll be
safe'
one.


So if there's a class like this:

class OpenFile
{
OpenFile(const char* name) throw(x)
{ if (can't open file)
throw Failure;
}
};

I'd like to see a method like this:

static bool Openable(const char* name);

Failing that, an alternative class like this:

class File
{ File();
bool Open(const char* name) // May still throw unexpected
failures, e.g. 'out of memory'
{ ...
return success;
}
};
Chuck Walbourn
2005-05-16 19:57:01 UTC
Permalink
Once upon a time the solution to the software quality "crises" was to
encourage everyone to write "defensive" code: code that would never
crash even if it was given garbage as inputs. The problem with
"defensive" code is that it will fail quietly or in unpredictable ways,
adds a lot of extra (often forgotten) code paths for testing, and is
typically lower performing and a bit bloated with all those extra
checks.

Models like "Design by Contract" say that instead you should write code
that handles error conditions, but not bad use of the API. Asserts and
other debug-only checks should check for this to make it clear that
misuse of the API is a bug without having to pay this overhead in
production builds. This makes it a 'fatal error' to give the API
anything that isn't reasonable and valid input or to call methods while
objects are in an invalid state.

It seems like we've come full-circle again with all the worries around
code security. Trying to be 'catch-all' rather than 'specific' in our
focus of conditions we check and handle in our code is an important
aspect of writing secure code. It isn't enough that that the API
generally work, but misuse of the API should not leave the system open
to security exploits. Exceptions have the advantage over return codes
in this area, although a lot of programmer discipline is needed to avoid
resource leaks in the presence of exceptions, extra testing needs to be
around to check the exception code paths, and requires some new
debugging skills.

There is no "silver bullet" for dealing with error conditions, API
misuse, or security concerns. For a console, where crashing the machine
is not as catastrophic, disabling exceptions completely might make
sense. Typically, though, your code still has to handle a number of
'exceptional' conditions even in a console environment. It is more
clear-cut what things you'll be tested on but that doesn't mean it
covers everything that your game might have to contend with in the real
world. For a desktop and even some consoles, your code defects
shouldn't put private information at risk to hackers or leave the system
in a messy potentially insecure state.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
Mat Noguchi (BUNGIE)
2005-05-16 20:05:06 UTC
Permalink
I guess this all gets back to: "Error handling is hard."

MSN
-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Chuck Walbourn
Sent: Monday, May 16, 2005 12:57 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C?++ exceptions?

Once upon a time the solution to the software quality "crises" was to
encourage everyone to write "defensive" code: code that would never
crash even if it was given garbage as inputs. The problem with
"defensive" code is that it will fail quietly or in unpredictable ways,
adds a lot of extra (often forgotten) code paths for testing, and is
typically lower performing and a bit bloated with all those extra
checks.

Models like "Design by Contract" say that instead you should write code
that handles error conditions, but not bad use of the API. Asserts and
other debug-only checks should check for this to make it clear that
misuse of the API is a bug without having to pay this overhead in
production builds. This makes it a 'fatal error' to give the API
anything that isn't reasonable and valid input or to call methods while
objects are in an invalid state.

It seems like we've come full-circle again with all the worries around
code security. Trying to be 'catch-all' rather than 'specific' in our
focus of conditions we check and handle in our code is an important
aspect of writing secure code. It isn't enough that that the API
generally work, but misuse of the API should not leave the system open
to security exploits. Exceptions have the advantage over return codes
in this area, although a lot of programmer discipline is needed to avoid
resource leaks in the presence of exceptions, extra testing needs to be
around to check the exception code paths, and requires some new
debugging skills.

There is no "silver bullet" for dealing with error conditions, API
misuse, or security concerns. For a console, where crashing the machine
is not as catastrophic, disabling exceptions completely might make
sense. Typically, though, your code still has to handle a number of
'exceptional' conditions even in a console environment. It is more
clear-cut what things you'll be tested on but that doesn't mean it
covers everything that your game might have to contend with in the real
world. For a desktop and even some consoles, your code defects
shouldn't put private information at risk to hackers or leave the system
in a messy potentially insecure state.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
Gareth Lewin
2005-05-16 21:26:47 UTC
Permalink
Which is a subset of "Programming is hard."

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Mat Noguchi (BUNGIE)
Sent: Monday, May 16, 2005 1:05 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C?++ exceptions?

I guess this all gets back to: "Error handling is hard."

MSN
-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Chuck Walbourn
Sent: Monday, May 16, 2005 12:57 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Effective use of C?++ exceptions?

Once upon a time the solution to the software quality "crises" was to
encourage everyone to write "defensive" code: code that would never
crash even if it was given garbage as inputs. The problem with
"defensive" code is that it will fail quietly or in unpredictable ways,
adds a lot of extra (often forgotten) code paths for testing, and is
typically lower performing and a bit bloated with all those extra
checks.

Models like "Design by Contract" say that instead you should write code
that handles error conditions, but not bad use of the API. Asserts and
other debug-only checks should check for this to make it clear that
misuse of the API is a bug without having to pay this overhead in
production builds. This makes it a 'fatal error' to give the API
anything that isn't reasonable and valid input or to call methods while
objects are in an invalid state.

It seems like we've come full-circle again with all the worries around
code security. Trying to be 'catch-all' rather than 'specific' in our
focus of conditions we check and handle in our code is an important
aspect of writing secure code. It isn't enough that that the API
generally work, but misuse of the API should not leave the system open
to security exploits. Exceptions have the advantage over return codes
in this area, although a lot of programmer discipline is needed to avoid
resource leaks in the presence of exceptions, extra testing needs to be
around to check the exception code paths, and requires some new
debugging skills.

There is no "silver bullet" for dealing with error conditions, API
misuse, or security concerns. For a console, where crashing the machine
is not as catastrophic, disabling exceptions completely might make
sense. Typically, though, your code still has to handle a number of
'exceptional' conditions even in a console environment. It is more
clear-cut what things you'll be tested on but that doesn't mean it
covers everything that your game might have to contend with in the real
world. For a desktop and even some consoles, your code defects
shouldn't put private information at risk to hackers or leave the system
in a messy potentially insecure state.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
_______________________________________________
Sweng-gamedev mailing list
Sweng-***@lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
Chuck Walbourn
2005-05-16 22:01:09 UTC
Permalink
The general issue with error handling is that when a developer creates
and tests their code, they typically get the 'standard' path debugged
and working. It takes a lot of effort to test for error conditions. It
takes even more effort to test for 'exceptional' conditions that the
developer may not even really be considering in the first cut of the
implementation.

Exception handling, just much of C++, gives programmers both a lot of
expressive power and a lot of rope to hang themselves, the project, and
the rest of their team. I personally think C++ is a great language, but
the 'minimum bar' of proficiency can be pretty high.

BTW, Meyer's "More Effective C++" has a lot of great advice for writing
good exception-friendly C++ code.

Another good trick to know when you are debugging exceptions with MSVC:
There is an 'Exceptions' dialog under debug that lets you control the
debuggers reaction to exceptions. Setting it to break on exceptions
means you'll get debugger control at the point of throw.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
Tom Plunket
2005-05-16 23:46:17 UTC
Permalink
Post by Chuck Walbourn
The general issue with error handling is that when a
developer creates and tests their code, they typically
get the 'standard' path debugged and working.
It amazes me that people still refuse to do comprehensive unit
testing as they're developing their code. At least with unit
tests you can exercize all of your code, even if you're not
combinatorially running every possible path.
Post by Chuck Walbourn
It takes a lot of effort to test for error conditions.
It takes even more effort to test for 'exceptional'
conditions that the developer may not even really be
considering in the first cut of the implementation.
Unit testing, of course, largely solves this entire problem.
Test-driven development helps quite a bit as well, wherein you
are not allowed to write any code that does not have a
corresponding failing unit test.

At the next level up, we have the case where the file handling
code gets some new error return codes. Since it's against the
grain to try to explicitly test all of those codes for all of
the code that uses files, you've got to rely on a yet-higher
level mechanism to do interesting things for you. This is the
realm of functional and acceptance tests.
Post by Chuck Walbourn
I personally think C++ is a great language, but the
'minimum bar' of proficiency can be pretty high.
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.

-tom!
Michael Walter
2005-05-16 23:54:57 UTC
Permalink
Post by Scott Henderson
-----Original Message-----
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.
Are you thinking of any specific languages?

Michael
Tom Plunket
2005-05-17 00:24:27 UTC
Permalink
Post by Michael Walter
Post by Tom Plunket
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.
Are you thinking of any specific languages?
Ruby, Python, and Lua all look like interesting places to start
investigation, but they all do what they do by allocating
memory whenever they feel like it.

So- I'd start with one of the above, and definitely consider
moving to a set of in-house domain-specific languages as such
things seemed appropriate. As much as possible, these
languages would also be driven by GUI-based tools, so
non-programmers could program, but... We'd have to see. When
I get my next $15M I'll let ya know. ;)

-tom!
Parveen Kaler
2005-05-17 16:47:46 UTC
Permalink
Post by Tom Plunket
Post by Michael Walter
Post by Tom Plunket
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.
Are you thinking of any specific languages?
Ruby, Python, and Lua all look like interesting places to start
investigation, but they all do what they do by allocating
memory whenever they feel like it.
The pros and cons of using Python and Lua for game scripting is quite
well known. For Lua specifically, you can write your own fast pool
based allocator. The annoying part is binding C++ to your scripting
language.

A more interesting choice would be C++/CLI. Does anyone have experience
that they would like to share?

At my previous employer (not a game development company), our volume
renderer was written in C/C++. It was wrapped by a Managed C++
interface with applications written in VB and C#.

It worked well for the most part. You can have a solid core of
developers working on the core. And less experienced developers working
on the applications.

There were pitfalls to adopting a 1.0 product. Such as there was no
profiler that can actually profile mixed managed/unmanaged code.

Parveen
--
http://parveenkaler.com
Kris Lamb
2005-05-17 18:56:27 UTC
Permalink
A free easy to use language to build a GUI map editing tool. It's a 2d tile
based engine I'm writing, fairly simple, I'm using openGL. I already
created one tool , but decided I need a better GUI for it, I'm using GLUI,
but it has too many limitations, does anyone have a suggestion for what I
could use to make this tool? (note: the editor does not need to be openGL
specifically, but it would just be easier since I already have a lot of the
graphic code written.)

I had thought about maybe just using MFC and binding openGL to a context
window, instead of using GLUI, but I'm open to any suggestions.

p.s. this is just a side project I'm working on for fun.
Phlip
2005-05-17 19:13:19 UTC
Permalink
Post by Kris Lamb
A free easy to use language to build a GUI map editing tool.
The Tk Canvas is available for a number of scripting languages,
including Python and Ruby.

The canvas is extraordinarily useful because it treats graphic
primitives as objects, not painted pixels. There are three kinds of
graphics - non-retained, retained, and object-oriented. This canvas
permits you to derive from graphic primitives, such as a rectangle
with a border. You can bind block closures to input events, to respond
to clicks on these graphic objects. And you can give any object any of
a number of string handles, and address entire groups of primitives by
their handle.

Here are a couple of example projects showing these features:

http://rubygarden.org/ruby/ruby?SvgCanvas
http://www.rubygarden.org/ruby?SlideRule

The canvas also makes a very good reference project to illustrate
Test-Driven Development for GUIs. Everyone seems to think that's hard.
If you start with object-oriented graphics it's easy to learn, and
then you can work your way down the evolutionary tree to the harder
situations.
--
Phlip
Kent Quirk
2005-05-18 03:39:39 UTC
Permalink
Python with PyOpenGL and PyGame. There are a ton of tools and libraries for
it, including GUI tools, Python is an incredibly productive language, and
it's almost certainly fast enough for your needs. (If you have lots of
array-based math to do, look at Numeric Python for performance.)

There are two good ways to interface C++ code to it. Personally, I like
boost::python, but then I like the STL as well. If you're not as enamored
of complex templates, look into SWIG.

OpenGL code in PyOpenGL is almost copy-and-paste from C-based sample code.
It pretty much just works the way you'd expect.

Easiest wrapper to get a window running is GLUT, but there are other
alternatives.

If you're working on a Mac, by chance, take a look at PyObjC, which lets
you write Cocoa applications without ever touching a line of Objective C
code. Sadly, you still kinda have to know *how* to write ObjC code, as it's
pretty much a 1:1 mapping.

Seriously. I wouldn't write an engine in python, but I just shipped an app
that uses it for the front end, and it's astoundingly productive for
tooling and UIs.

Kent
Post by Kris Lamb
A free easy to use language to build a GUI map editing tool. It's a 2d
tile based engine I'm writing, fairly simple, I'm using openGL. I already
created one tool , but decided I need a better GUI for it, I'm using GLUI,
but it has too many limitations, does anyone have a suggestion for what I
could use to make this tool? (note: the editor does not need to be openGL
specifically, but it would just be easier since I already have a lot of
the graphic code written.)
I had thought about maybe just using MFC and binding openGL to a context
window, instead of using GLUI, but I'm open to any suggestions.
p.s. this is just a side project I'm working on for fun.
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
----
Kent Quirk
CTO, CogniToy
Megan Fox
2005-05-18 04:29:06 UTC
Permalink
Has anyone maybe gotten a good background with both script-type GUI
solutions and C# or Java solutions, such that they could compare and
contrast the two?

For an editing framework, my first instinct is to go with C# or
Java/Eclipse (well, no, my first instinct is to go with previous
experience and MFC, but then I remember how horrible it was to work
with, ugh), but I've really no particularly sound reason for such
beyond having a general preference for compiled code over scripted
code for large-scale applications.

Is there any real clear winner here, or does it boil down to personal
preference?

Thanks,
-Megan Fox
Post by Kent Quirk
Seriously. I wouldn't write an engine in python, but I just shipped an app
that uses it for the front end, and it's astoundingly productive for
tooling and UIs.
Kent
Tom Plunket
2005-05-18 18:01:52 UTC
Permalink
Post by Kent Quirk
Python with PyOpenGL and PyGame. There are a ton of tools and
libraries for it, including GUI tools, Python is an incredibly
productive language, and it's almost certainly fast enough for
your needs. (If you have lots of array-based math to do, look
at Numeric Python for performance.)
I second this suggestion.

I built a game in Python a couple of years ago, and had this 16
year-old kid helping me out with some stuff. I gave him the
task of the level editor, with a good-sized list of
requirements, and it was done in two days. Two days while he
learned the language. Admittedly it was for a 2D game, and the
game and graphics engines were fairly robust, but still- the
tileset could be edited, new enemy types could be added,
properties on those enemies could be edited.

I estimate that my productivity with Python is easily 10x what
it is with C++. Alas- I have yet to try interfacing it with
C++, but it is allegedly very easy. I have used wxWidgets via
wxPython, though, which is an interface built using SWIG, I
believe, onto the C++-based wx.

I also don't care for interface designers. Laying out UIs by
hand seems to be the fast route to not-completely-user-friendly
UIs. wx comes with a lot of tools to allow you to fairly
easily build UIs programmatically.
Post by Kent Quirk
OpenGL code in PyOpenGL is almost copy-and-paste from C-based
sample code. It pretty much just works the way you'd expect.
Ditto the wx stuff. In fact, wxPython installs the default
wxWidgets documentation because the methods map over almost 1:1
to Python objects and methods.


-tom!
Brad Might
2005-05-18 15:30:30 UTC
Permalink
Post by Michael Walter
Post by Tom Plunket
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.
Are you thinking of any specific languages?
Try Common Lisp. If you really want a higher level language, its got more power
than any other general purpose language, as well as the flexibility of scripting
languages. We're using it for an MMO engine and clients. I"ve rambled a bit
about it at:
http://www.ptarmigangames.com/malcontent/archives/12
Tom Plunket
2005-05-19 06:17:09 UTC
Permalink
Post by Michael Walter
Post by Tom Plunket
I couldn't agree more. In fact, I would go so far as to
suggest that "next-gen" we really can't afford the rope that
C++ gives us, and would be best served developing most of our
code in higher-level languages, moving only the most
performance-critical code to C (which is preferable in some
ways) or C++.
Are you thinking of any specific languages?
I chatted with a group doing their primary game development in
EIC, an interpreted dialect of C. They had very fast iteration
times, and a full rebuild of the game was very fast as the only
code that was compiled was the interpreter and the bindings to
the middleware. This is exceptionally interesting to me because
if they find a function is too slow because it's interpreted,
they just cut'n'paste it into a file with a .c extension, or just
rename the file itself, and wham, it's compiled. This also means
that they can change a .c file to a .eic and iterate on it
easily, changing back to .c for checkin.

The negative of course is that they're using C, not exactly a
rapid-development language.

The positive is that not having to compile or link makes up a lot
of time. Another positive is reloading files while the game is
running sure sounds cool! ...and then of course there's the bit
that they don't have to port from one language to another when
they want to switch to compiled vs. not.

-tom!
Phlip
2005-05-19 14:28:39 UTC
Permalink
Post by Tom Plunket
The negative of course is that they're using C, not exactly a
rapid-development language.
Interpreted C++ implementations are available.
Post by Tom Plunket
The positive is that not having to compile or link makes up a lot
of time. Another positive is reloading files while the game is
running sure sounds cool! ...and then of course there's the bit
that they don't have to port from one language to another when
they want to switch to compiled vs. not.
Either way, after the Replace Language Refactor, all the automated
tests should still pass, including the high-level scenario tests that
ensure game balance.
--
Phlip
Jon Watte
2005-05-19 21:31:31 UTC
Permalink
Post by Tom Plunket
The positive is that not having to compile or link makes up a lot
of time. Another positive is reloading files while the game is
running sure sounds cool! ...and then of course there's the bit
that they don't have to port from one language to another when
they want to switch to compiled vs. not.
MSDEV has had edit-and-continue since version 6 (in 1998). It works,
too. However, the main draw-back is that you can't add members of
compound types using EAC. In a truly dynamic language, you could,
because names are typically looked up at runtime using hashing.

Cheers,

/ h+
Phlip
2005-05-19 21:38:20 UTC
Permalink
Post by Jon Watte
Post by Tom Plunket
The positive is that not having to compile or link makes up a lot
of time. Another positive is reloading files while the game is
running sure sounds cool! ...and then of course there's the bit
that they don't have to port from one language to another when
they want to switch to compiled vs. not.
MSDEV has had edit-and-continue since version 6 (in 1998).
If a compiler has an ability, you should use it.

However, leaning on edit-and-continue can be a sign your code is
insufficiently decoupled to get in and out of it with fast cycles of
edit/compile/test.
--
Phlip
Jon Watte
2005-05-19 22:18:09 UTC
Permalink
Post by Phlip
However, leaning on edit-and-continue can be a sign your code is
insufficiently decoupled to get in and out of it with fast cycles of
edit/compile/test.
The problem is often not the compile, but navigating yourself to
the point in the system where it exhibits the behavior you're
interested in. For a chess game, you can probably "load game" as
part of the command line. For an MMO where you simulate all the
server bits on your local machine, the situation is different...

Cheers,

/ h+
Paul Du Bois
2005-05-20 23:04:32 UTC
Permalink
Post by Phlip
However, leaning on edit-and-continue can be a sign your code is
insufficiently decoupled to get in and out of it with fast cycles of
edit/compile/test.
Edit and continue is also extremely handy for setting conditional
breakpoints. Yes, it's possible to have vs.net execute a predicate
each time a breakpoint is hit, but I've found it's much faster and
more stable to inject it straight into the code, eg:

if (pEntity->GetName() == "RazMeleeHand1") {
int jj=1; // set breakpoint here
}
Phlip
2005-05-20 23:24:02 UTC
Permalink
Post by Paul Du Bois
Edit and continue is also extremely handy for setting conditional
breakpoints. Yes, it's possible to have vs.net execute a predicate
each time a breakpoint is hit, but I've found it's much faster and
if (pEntity->GetName() == "RazMeleeHand1") {
int jj=1; // set breakpoint here
}
#define CHECK_POINT(x) if (x) { _CrtDbgBreak(); }

I had that in my copy buffer when you posted; your way works fine too.
One should also seek a way for CHECK_POINT() to cleanly disappear out
of code compiled in non-Debug mode. (My macro is not clean.)

My beef against Edit-and-Continue is simple: Leaning on advanced
debugging could indicate your call stack is not decouplable. Consider
a game where you can't create an actor, a texture, or a geometry,
without first loading the entire world from the sound stuff to the
network stuff.

In that environment, you must set a breakpoint, play the game, hit the
breakpoint, and remain there debugging as long as possible without
restarting.

If, instead, your architecture is completely decoupled, you can write
a unit test and run that over and over again, maybe also with a
breakpoint right below the test, in the called code. Because
restarting is completely free (the test sets up your scenario so you
don't need to play the game each time), you are more likely to restart
over and over again as you tune things.

Each time you change the code, tests will validate the change.
Edit-and-continue could morph the code - however temporarily - into
untestworthy states.

When people go to a more dynamic system than C++ they typically
discover their edit/check cycle improves. They could also get the same
benefits by staying in C++ and relying on unit tests much more than on
Edit-and-Continue.
--
Phlip
Robert Blum
2005-05-21 17:54:47 UTC
Permalink
Post by Phlip
If, instead, your architecture is completely decoupled, you can write
a unit test and run that over and over again,
The question is - how to get there? There's Mocks, for sure - any
other advice?

Simple example - place an actor in the scene by pick ray. Collide him
against the terrain to make sure he's right on the terrain. This
draws in a *lot* of subsystems. You need at least the actor, the pick
ray, terrain, and the appropriate collision libraries. If all your
actors happen to live in a database - you just added that to the mix.
(Not even to mention loading on the fly and other fun)

So how do you detangle that? I'm not too fond of mocks - they just
don't give me the same test value as testing the real thing, and
they're extra code to maintain. So, I'd be grateful for any advice!
Post by Phlip
breakpoint right below the test, in the called code. Because
restarting is completely free (the test sets up your scenario so you
don't need to play the game each time), you are more likely to restart
over and over again as you tune things.
Restarting is *free* ??? Not with my version of C++. There's the time
to compile the code. Compile the test. Compile the code again in the
test project (unless the original project is a .lib). Link the whole
thing. Reload tests (since auto-reload is rather bad for the debugger
(if you're mixed mode) ).

By now I've easily burned a minute or two. That's not exactly free
and tends to make the edit/test cycle longer than I would want.
Again, advice to improve that time is greatly appreciated.

(I'm still not using edit&continue - for the simple reason that
changing your program in the middle of execution might miss states
you'd enter on normal execution. That, and sometimes you need to
rebuild your project for no known reason - the linker just choked and
built something with no resemblance to the actual code)

- Robert
Justin Heyes-Jones
2005-05-21 18:12:45 UTC
Permalink
IME the link time is often way longer than the compile time, so
limiting your code changes really does nothing to improve your edit,
run, test cycle. Obviously being careful with header dependencies
helps out with that.

Not using edit and continue because sometimes it doesn't work seems a
shame. Sure something subtle could get messed up that you don't know
about, resulting in code that you think works but really doesn't. But
once you run again after a 'real' build you will find out for certain.
I have had very few problems with edit and continue.
Charles Nicholson
2005-05-21 18:23:05 UTC
Permalink
We have a 3-minute link time on the xbox right now (no kidding).
"Rapid iteration" is something of a joke for those of us working on
Live. :) It often takes longer to build the game than it does to
make the change and test it.
Post by Justin Heyes-Jones
IME the link time is often way longer than the compile time, so
limiting your code changes really does nothing to improve your edit,
run, test cycle. Obviously being careful with header dependencies
helps out with that.
Not using edit and continue because sometimes it doesn't work seems a
shame. Sure something subtle could get messed up that you don't know
about, resulting in code that you think works but really doesn't. But
once you run again after a 'real' build you will find out for certain.
I have had very few problems with edit and continue.
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Phlip
2005-05-21 18:42:35 UTC
Permalink
Post by Charles Nicholson
We have a 3-minute link time on the xbox right now (no kidding).
"Rapid iteration" is something of a joke for those of us working on
Live. :) It often takes longer to build the game than it does to
make the change and test it.
Interesting if the XBox supports Edit-and-Continue but not DLLs. One
can at least configure the PC Debug mode to use DLLs instead of long
links.

About setting up an actor and some geometry, the goal of Construction
Encapsulation and of the Proxy Pattern is not just to permit a few
mocks, but to ensure that test targets don't pull in useful
dependencies that then pull in useless ones. The buck stops here.
--
Phlip
Tom Plunket
2005-05-22 21:52:30 UTC
Permalink
Post by Charles Nicholson
We have a 3-minute link time on the xbox right now (no kidding).
"Rapid iteration" is something of a joke for those of us working on
Live. :) It often takes longer to build the game than it does to
make the change and test it.
...Enter the PSP. ;)

Anyway- this should be enough of a reason to embrace unit testing
all by itself. Your unit tests will certainly link faster
because you'll only be changing one library at a time. Even if
there are other library dependencies, it's highly unlikely you'd
need to do a full link like the game.

This also points out a good reason for writing as much of your
code as possible in a not-compiled language, at least initially.
No compile = no link. ;)

-tom!

Justin Heyes-Jones
2005-05-19 22:21:23 UTC
Permalink
Being able to edit and continue has been a fantastic debugging/code
writing tool. Lisp has had it for decades. I used to step through my
code after it was written to make sure it was all good, now I can step
through it and correct it as I go.
Post by Phlip
Post by Jon Watte
Post by Tom Plunket
The positive is that not having to compile or link makes up a lot
of time. Another positive is reloading files while the game is
running sure sounds cool! ...and then of course there's the bit
that they don't have to port from one language to another when
they want to switch to compiled vs. not.
MSDEV has had edit-and-continue since version 6 (in 1998).
If a compiler has an ability, you should use it.
However, leaning on edit-and-continue can be a sign your code is
insufficiently decoupled to get in and out of it with fast cycles of
edit/compile/test.
--
Phlip
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Phlip
2005-05-19 23:31:50 UTC
Permalink
Post by Justin Heyes-Jones
Being able to edit and continue has been a fantastic debugging/code
writing tool. Lisp has had it for decades. I used to step through my
code after it was written to make sure it was all good, now I can step
through it and correct it as I go.
Have you tried unit tests? They give exactly this benefit you
describe, sustainably.
--
Phlip
Tom Plunket
2005-05-19 22:34:12 UTC
Permalink
Post by Jon Watte
Post by Tom Plunket
The positive is that not having to compile or link makes up a
lot of time. Another positive is reloading files while the
game is running sure sounds cool!
MSDEV has had edit-and-continue since version 6 (in 1998). It
works, too.
Yeah I know about it and have used it on toy projects but it's
always failed to function meaningfully for reasons I didn't
pursue on Real Games. Plus there's the point about them not
supporting the PS2 which many studios still count as their
primary platform...
Post by Jon Watte
However, the main draw-back is that you can't add members
of compound types using EAC.
Neither can you change static data, which I found to be a
strange restriction. e.g. I have this table of data at file
scope, and I change it. I have to stop the debugger to build
those changes in?

-tom!
Nick Waanders
2005-05-17 19:52:15 UTC
Permalink
C#


-NickWaanders


-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Kris Lamb
Sent: Tuesday, May 17, 2005 11:56 AM
To: sweng-***@midnightryder.com
Subject: [Sweng-gamedev] Looking for:


A free easy to use language to build a GUI map editing tool. It's a 2d
tile
based engine I'm writing, fairly simple, I'm using openGL. I already
created one tool , but decided I need a better GUI for it, I'm using
GLUI,
but it has too many limitations, does anyone have a suggestion for what
I
could use to make this tool? (note: the editor does not need to be
openGL
specifically, but it would just be easier since I already have a lot of
the
graphic code written.)

I had thought about maybe just using MFC and binding openGL to a context

window, instead of using GLUI, but I'm open to any suggestions.

p.s. this is just a side project I'm working on for fun.


_______________________________________________
Sweng-gamedev mailing list Sweng-***@lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
Phlip
2005-05-17 20:06:04 UTC
Permalink
C#
Care to defend it?
--
Phlip
Nick Waanders
2005-05-17 20:28:40 UTC
Permalink
Sure.

The number one reason I have for using C# for tools would be
productivity. I found that I'm about a factor 4 times more productive in
C# than I am in C++. My experience in C++ is about a decade, while my C#
experience is a mere few months. You can get stuff done quickly, which
is handy for a home project, assuming you have a 40+hour job to do
besides that.

Antoher reason to use it would be how close it is to C/C++. It's easy to
learn, and while learning the language I had multiple cases where I was
thinking 'why isn't c++ like this'. For example the way enums are used,
foreach, properties, garbage collection, the tie in to the windows
controls (I know, this is a weak point because many other languages do
this very well).

Things I am missing/not liking so much: 'const', Count and Length in
different containers, ArrayList of specified types instead of general
objects (changing in 2.0).

Another con would be linking to C++, which is a bit of a bitch. This is
looking like it will change in C# 2.0.

In my experience for writing tools, C# is the way to go. Simple, fast,
productive. Of course this all depends on your C++ codebase, if you have
a killer C++ codebase already, then you might want to choose for C++.

But hey, what do I know. You'll have to make the choice for yourselves.
I just think it's worth looking at. :)

-NickWaanders


-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Phlip
Sent: Tuesday, May 17, 2005 1:06 PM
C#
Care to defend it?
--
Phlip
_______________________________________________
Sweng-gamedev mailing list Sweng-***@lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
Scott Graham
2005-05-17 21:57:05 UTC
Permalink
In addition, I would add:

- Strong IDE and debugger (except when in 1.0 mixed mode). When
compared to other scripting languages, there's pretty much, well, no
comparison. This is especially important for tools, I think, because
realistically, they tend to be maintained by a mess of ever-changing
people who may or may not understand the design/code.
Post by Nick Waanders
Sure.
The number one reason I have for using C# for tools would be
productivity. I found that I'm about a factor 4 times more productive in
C# than I am in C++. My experience in C++ is about a decade, while my C#
experience is a mere few months. You can get stuff done quickly, which
is handy for a home project, assuming you have a 40+hour job to do
besides that.
Antoher reason to use it would be how close it is to C/C++. It's easy to
learn, and while learning the language I had multiple cases where I was
thinking 'why isn't c++ like this'. For example the way enums are used,
foreach, properties, garbage collection, the tie in to the windows
controls (I know, this is a weak point because many other languages do
this very well).
Things I am missing/not liking so much: 'const', Count and Length in
different containers, ArrayList of specified types instead of general
objects (changing in 2.0).
Another con would be linking to C++, which is a bit of a bitch. This is
looking like it will change in C# 2.0.
In my experience for writing tools, C# is the way to go. Simple, fast,
productive. Of course this all depends on your C++ codebase, if you have
a killer C++ codebase already, then you might want to choose for C++.
But hey, what do I know. You'll have to make the choice for yourselves.
I just think it's worth looking at. :)
-NickWaanders
-----Original Message-----
On Behalf Of Phlip
Sent: Tuesday, May 17, 2005 1:06 PM
C#
Care to defend it?
--
Phlip
_______________________________________________
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Robert Blum
2005-05-19 16:58:50 UTC
Permalink
Post by Scott Graham
- Strong IDE and debugger (except when in 1.0 mixed mode).
Hrmpfh. Understatement of the week. If you *have* to go mixed mode,
I'd suggest using COM. Never put those things in the same project, at
least in VS.NET up to 2003. Whidbey is sitting on my desk, awaiting
evaluation, so I can't say anything about the debugger in there.

In fact, if you have to go mixed mode, I'd strongly suggest sticking
with C++ for now. I'm in a mixed mode project right now, and it's
causing quite a bit of pain.
Post by Scott Graham
comparison. This is especially important for tools, I think, because
realistically, they tend to be maintained by a mess of ever-changing
people who may or may not understand the design/code.
Ouch! Speak for yourself ;)

Seriously though - wouldn't it be better to fix that situation with
the *people* involved, instead of hoping that a tool takes magically
care of it?

- Robert
John Hall
2005-05-17 22:20:43 UTC
Permalink
Post by Nick Waanders
Sure.
The number one reason I have for using C# for tools would be
productivity. I found that I'm about a factor 4 times more productive in
C# than I am in C++. My experience in C++ is about a decade, while my C#
experience is a mere few months. You can get stuff done quickly, which
is handy for a home project, assuming you have a 40+hour job to do
besides that.
I second that. I took the C# plunge a weekend ago and coded up a command
line image conversion tool as a test project. Despite the fact that I
was constantly looking things up in the book (C# in a Nutshell), the
project went by very quickly, and ended up with a clean interface and
very good error handling. The framework class library (FCL) is powerful
and easy to use.

I'd probably be just as happy with Java, really. I learned C# out of
curiosity and liked it enough to continue. Notably missing in the
current version of C# is generics support, but that is supposedly coming
in the next major release. For now the convention is to downcast to the
Object class to store objects in containers, which is annoying, but not
a big deal.

.NET is ironically very portable for a Microsoft platform. I learned C#
on a Mac using Mono. My binaries run unchanged on Linux and Windows (on
Windows, they launch directly as EXE files). Some parts of the Mono FCL
are not complete (mainly the Windows GUI related classes), but there are
portable replacements for most of the missing classes (such as GTK#).
I've had no problems so far.

C# will be very easy for any C++ programmer to pick up. I learned it
quickly by reading O'Reilly's C# pocket reference cover to cover and
using C# in a Nutshell as a class library reference. You could also
refer to the online MSDN docs, but I find them hard to navigate.

-John
Phlip
2005-05-18 05:29:11 UTC
Permalink
Post by Nick Waanders
The number one reason I have for using C# for tools would be
productivity. I found that I'm about a factor 4 times more productive in
C# than I am in C++.
This experience appears to represent a burst of freedom from C++.
--
Phlip
Luis Villegas
2005-05-17 22:23:42 UTC
Permalink
Great tool set

Great debugger

Great framework (metadata, serialization, UI, networking, etc, etc)

Full programmatic access to the compiler which allows adding scripting
support for the tools (No need to generate binding code, and in overall
the effort for adding scripting is very small compared to the
alternatives)

VS has visual designers for the UI

Fast compilation times

Fairly fast execution time



Issues with writing tools with it:

Some effort is needed to get it up and running with an existing C++
renderer, but the benefits outweight the costs.

The original message asked for a free tool, and VS is needed in order to
unleash the full potential of C#, which might make C# not ideal for such
personal project.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Phlip
Sent: Tuesday, May 17, 2005 1:06 PM
C#
Care to defend it?
--
Phlip
Chris Dellario
2005-05-17 22:27:14 UTC
Permalink
Post by John Hall
I'd probably be just as happy with Java, really.
I'm curious about how people view the current state of Java in
comparison with C#. I've developed in both Java and C++ for several
years, but I never had the opportunity to spend much time with C#.
Anybody have opinions on how Java and C# match up for creating tools?


Chris Dellario
Lead Engineer
Whatif Productions LLC
http://www.whatif.info
John Hall
2005-05-17 22:51:28 UTC
Permalink
Post by Chris Dellario
Post by John Hall
I'd probably be just as happy with Java, really.
I'm curious about how people view the current state of Java in
comparison with C#. I've developed in both Java and C++ for several
years, but I never had the opportunity to spend much time with C#.
Anybody have opinions on how Java and C# match up for creating tools?
Some claim that the C# library is better. Java currently has generics
support. The Java tools have been around longer and are more mature.
Java is somewhat more portable. Both runtimes support JIT compilation
and offer decent performance.

Building native Windows UI's is easier in C#. C# has all of the benefits
of Visual Studio. There are probably UI builder tools for Java, but I've
never used them.

Dealing with raw binary data formats in Java can be less convenient. C#
supports reading binary data into packed structures. I don't believe
Java does. C# also allows you to drop into "unsafe" mode to directly
manipulate data with pointers. Java very adamantly does not.

Interfacing with C++ and other languages is probably easier in C#,
though I haven't tried it. I understand this is tricky in Java.

Java produces one .class file per class, which must carry the class'
name. C# does not impose this requirement; you can split a C# program
into whatever combination of .dll and .exe files you want. C# does not
have an equivalent of .jar files.

OO design is similar in both languages. Both support only single
inheritance with interfaces.

C# has some nice syntactic sugar, such as foreach, properties, and
indexers. These are entirely for convenience and don't increase the
actia; power of the language at all.

C# and Java both have documentation generation tools. C#'s is based on
XML (run through XSLT to produce HTML), whereas Java's produces HTML
files directly. I wonder if Doxygen supports either language; I'd prefer
to use it if possible, since I already use it for my C++ projects.

And of course C sharp is equivalent to D flat in music. Pick the name
you prefer. :)

-John
Sim Dietrich
2005-05-17 22:33:49 UTC
Permalink
I've been using managed C++ with .net windows forms and overall I like
it for tools, but there are serious issues.

I don't know if C# has the same issues with windows forms, but here they
are in case you run into them ( vs.net 2003 ).

1) I must delete the .suo file or the solution will hang on load. Other
projects don't have this issue.

2) The form designer gets out of sync with Form1.h file and likes to put
new variable declarations in Form1.cpp instead.

3) I can't for the life of me figure out how to capture mouse events
when its over a panel that contains my d3d window. So I'm reduced to
using scroll bars for moving around my 3D map.

Still, it seems pretty weak when compared to Delphi or C++ builder circa
1999. I miss the image grid control, for example.

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Luis Villegas
Sent: Tuesday, May 17, 2005 3:24 PM
To: sweng-***@midnightryder.com
Subject: RE: [Sweng-gamedev] Looking for:

Great tool set

Great debugger

Great framework (metadata, serialization, UI, networking, etc, etc)

Full programmatic access to the compiler which allows adding scripting
support for the tools (No need to generate binding code, and in overall
the effort for adding scripting is very small compared to the
alternatives)

VS has visual designers for the UI

Fast compilation times

Fairly fast execution time



Issues with writing tools with it:

Some effort is needed to get it up and running with an existing C++
renderer, but the benefits outweight the costs.

The original message asked for a free tool, and VS is needed in order to
unleash the full potential of C#, which might make C# not ideal for such
personal project.

Luis Villegas

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Phlip
Sent: Tuesday, May 17, 2005 1:06 PM
C#
Care to defend it?
--
Phlip
_______________________________________________
Sweng-gamedev mailing list
Sweng-***@lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com
Martin Slater
2005-05-19 00:02:06 UTC
Permalink
Post by Sim Dietrich
Still, it seems pretty weak when compared to Delphi or C++ builder circa
1999. I miss the image grid control, for example.
I'll agree with this, Borlands offerings were doing what c# attempts to
do a long time ago and do it far far better, its a bit of a shame that
c++ builder seems to be dying a bit. I think that ms got the head
designer of these products from borland and he is working on .NET
though. C# integration has massive issues with the vc2003 ide, trying to
debug across the language boundery is a complete nightmare with constant
hangs in the debugger requiring it to be killed in the task manager and
restarted as well as the slow start up speed of c# apps which is major
pain in tools that are meant to be run many times, ie a data converter..
Using a mixture of win32gui and boost all of my tools writing is
extremely quick and efficient but still nowhere as nice as using c++
builder. Unfortuantly builders c++ support is pretty lame and getting
things to work in both VC and builder is frustrating to say the least.

my 2c

Martin
Robert Blum
2005-05-19 17:02:48 UTC
Permalink
Post by Sim Dietrich
I don't know if C# has the same issues with windows forms, but here they
are in case you run into them ( vs.net 2003 ).
1) I must delete the .suo file or the solution will hang on load.
Other
projects don't have this issue.
That's easily solved - *never* close visual studio with a designer
window open.
Post by Sim Dietrich
2) The form designer gets out of sync with Form1.h file and likes to put
new variable declarations in Form1.cpp instead.
I've only seen that happen if you actually have code in Form1.cpp.
Post by Sim Dietrich
3) I can't for the life of me figure out how to capture mouse events
when its over a panel that contains my d3d window. So I'm reduced to
using scroll bars for moving around my 3D map.
Hm. We've got a separate window for the renderer, not just a panel. E-
Mail me off list for details... I'm surprised the gods of on-
topicness haven't struck us yet ;)

- Robert
Nick Waanders
2005-05-17 22:40:13 UTC
Permalink
Post by Sim Dietrich
3) I can't for the life of me figure out how to capture mouse events
when its over a panel that contains my d3d window. So I'm reduced to
using scroll bars for moving around my 3D map.


This might be obvious, but did you try to click on the panel in the
editor, go to it's properties, click on the little lightning bolt button
at the top, choose an item like MouseMove, and double click on the empty
box besides it? That should generate a new function for tracking mouse
items.

This works for me in both MFC and C# using forms.

-NickWaanders
Crosbie Fitch
2005-05-18 08:44:52 UTC
Permalink
There may even be a bigger factor when moving from COM based programming to
the C# equivalent - all the beauty of COM and none of the ugliness.

I've just spent 6 months using C# in which my attitude has progressed from
"C# is plastic scissors for C++ newbies" to "C# is to C++, as C is to
assembler".

Certainly don't write C# off as just Visual Basic with its syntax replaced
with C++ pseudo code.

Design your interfaces in C#, implement them in C# first (hooking up to
legacy/3rd party DLLs/COM modules/C++ code as necessary). Anything time
critical, rewrite in C++. For non-CLR platforms rewrite all C# to C++.
Preserve both implementations.

NB Don't waste time with managed C++ (except for porting over legacy
source). For the CLR platform write new code in C#. For unmanaged code use
C++.

JIT compilation with CLR probably represents a good candidate for the next
generation of programming technology - it's a good solution for
cross-platform portability,

I expect XNA embraces .NET so the CLR will appear on Xbox 360. I wonder if
the PS3 will support it? Perhaps via Mono?

Mono: http://www.mono-project.com/Main_Page
Check out RealmForge GDK too: http://realmforge.com/
Post by Phlip
Post by Nick Waanders
productivity. I found that I'm about a factor 4 times more productive
in C# than I am in C++.
This experience appears to represent a burst of freedom from C++.
Sim Dietrich
2005-05-18 21:20:57 UTC
Permalink
I could have sworn I tried that, but I can try again. Maybe it was that
Panel's can't have capture mouse events? I'll try it out later...

-----Original Message-----
From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com
[mailto:sweng-gamedev-midnightryder.com-***@lists.midnightryder.com]
On Behalf Of Nick Waanders
Sent: Tuesday, May 17, 2005 3:40 PM
Post by Sim Dietrich
3) I can't for the life of me figure out how to capture mouse events
when its over a panel that contains my d3d window. So I'm reduced to
using scroll bars for moving around my 3D map.


This might be obvious, but did you try to click on the panel in the
editor, go to it's properties, click on the little lightning bolt button
at the top, choose an item like MouseMove, and double click on the empty
box besides it? That should generate a new function for tracking mouse
items.

This works for me in both MFC and C# using forms.

-NickWaanders
Nick Trout
2005-05-19 01:41:57 UTC
Permalink
Post by Kris Lamb
A free easy to use language to build a GUI map editing tool. It's a
2d
Post by Kris Lamb
tile
based engine I'm writing, fairly simple, I'm using openGL. I already
created one tool , but decided I need a better GUI for it, I'm using
GLUI,
Post by Kris Lamb
but it has too many limitations, does anyone have a suggestion for
what I
Post by Kris Lamb
could use to make this tool? (note: the editor does not need to be
openGL
Post by Kris Lamb
specifically, but it would just be easier since I already have a lot
of
Post by Kris Lamb
the
graphic code written.)
Have a look at:

* OpenGL C++ GUI: http://glow.sourceforge.net/

* PyGame: Python solution

- http://www.pygame.org/gamelets/

http://www.pygame.org/gamelets/games/mapeditor.zip

and

- http://www.pygame.org/projects/

- http://www.mrexcessive.net/pyplace/

- http://members.optusnet.com.au/~cpbarton/

* Complete editor: http://tilestudio.sourceforge.net/

I might suggest http://doris.sourceforge.net/ but that uses GLUI as well
:-(

N
Nick Trout
2005-05-19 01:49:29 UTC
Permalink
Post by Luis Villegas
Behalf Of Tom Plunket
I estimate that my productivity with Python is easily 10x what
it is with C++. Alas- I have yet to try interfacing it with
C++, but it is allegedly very easy.
It's reference counted, so be careful. If you're going to interface
Python and C++ (in tools) use Boost.Python. It lets you write binding
code in Python style in C++.
Post by Luis Villegas
I have used wxWidgets via
wxPython, though, which is an interface built using SWIG, I
believe, onto the C++-based wx.
wxWidgets (what MFC should have been) is the largest, most portable GUI
library that I've found. wxPython is great and would be very good for
this tile editor. Mmmm, I just remembered you can embed PyGame in
wxPython, so tile editor using PyGame in wxPython would be very quick to
write.

N
Tom Plunket
2005-05-19 06:05:48 UTC
Permalink
Post by Nick Trout
Post by Luis Villegas
Behalf Of Tom Plunket
I estimate that my productivity with Python is easily 10x what
it is with C++. Alas- I have yet to try interfacing it with
C++, but it is allegedly very easy.
It's reference counted, so be careful. If you're going to
interface Python and C++ (in tools) use Boost.Python. It lets you
write binding code in Python style in C++.
Boost is the One True Way, of course. That was to be the first
path. ;)
Post by Nick Trout
Post by Luis Villegas
I have used wxWidgets via wxPython, though, which is an interface
built using SWIG, I believe, onto the C++-based wx.
wxWidgets (what MFC should have been) is the largest, most
portable GUI library that I've found. wxPython is great and would
be very good for this tile editor. Mmmm, I just remembered you
can embed PyGame in wxPython, so tile editor using PyGame in
wxPython would be very quick to write.
Indeed- while I have issues from time to time with the verbosity
that wx requires of me, I also find that my own local factories
for their objects that I create over and over again (e.g.
buttons, edit controls, etc.) centralizes a lot of the
look'n'feel settings that I might want to change, and it ends up
being pretty easy to get things up quickly.

Also- the wx/PyGame integration is a bit tricky at first, but the
Wiki at wiki.wxpython.org has a page on IntegratingPyGame that
discusses the pitfalls and the not-terrible workarounds. Let's
just say, though, it's all worth it in the case of an editor for
a 2D tile-based game. ;)

-tom!
Dr Andrew Perella
2005-05-19 09:44:58 UTC
Permalink
Maybe Boost.Python has improved, but I last tried it out 2 years ago when compiler support for the heavy template use
was so terrible that I just don't think it was practiacal for any large scale project - compiling could take 10 minutes
for one c++ file. We moved to SWIG and found it served us well. 95% of the binding to C++ is automatic so anyone can do
it. I would be interested in hearing experiences of anyone who has moved from swig to boost.python in case we should
look at that again.

Oh, and a great thumbs up to wxPython. Can't beat it.

Regards,
Andrew
Post by Scott Henderson
-----Original Message-----
Behalf Of Nick Trout
Sent: 19 May 2005 02:49
Post by Luis Villegas
Behalf Of Tom Plunket
I estimate that my productivity with Python is easily 10x what
it is with C++. Alas- I have yet to try interfacing it with
C++, but it is allegedly very easy.
It's reference counted, so be careful. If you're going to interface
Python and C++ (in tools) use Boost.Python. It lets you write binding
code in Python style in C++.
Post by Luis Villegas
I have used wxWidgets via
wxPython, though, which is an interface built using SWIG, I
believe, onto the C++-based wx.
wxWidgets (what MFC should have been) is the largest, most portable GUI
library that I've found. wxPython is great and would be very good for
this tile editor. Mmmm, I just remembered you can embed PyGame in
wxPython, so tile editor using PyGame in wxPython would be very quick to
write.
N
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended
recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or
other legal liability, apart from liability which cannot be excluded under English law.
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus
Control Centre.
www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law.

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
Phlip
2005-05-19 14:26:18 UTC
Permalink
Post by Nick Trout
wxWidgets (what MFC should have been)
+1 also. ;-)

wxWidgets does signals and slots using Noel L's favorite technique,
the Cute Macro from Hell.

The similarity to MFC stops there. The marketects of MFC did not want
to override a virtual method for every single window message in
Windows. There are tens of thousands, most won't be called, and no
compiler can optimize a virtual method out of its vtable slot. So you
must intercept a message for everything in MFC.

wxWidgets, by contrast, provides virtual methods to override for all
the high level things you need to do, like service a keystroke or
close a window.

For more on what MFC should have been, see WTL. This is an MS
skunkworks, published by an MS engineer, which the marketects
generally hold at arm's length. They don't want to support something
that doesn't serve their grand designs of eternal vendor lockin. WTL
is a super-light extension to ATL that catches messages like MFC, but
decouples everything from everything else. Unlike MFC.
--
Phlip
Kent Quirk
2005-05-20 00:18:03 UTC
Permalink
We looked at SWIG and decided on boost::python. You're right that it can
gag a weak compiler, but we've shipped a product using on MSVC 7.1, and
we're about to ship on GCC 3.3. It's SO easy to add methods, classes, etc.
You can inherit python objects from C++ and vice-versa.

We wrote a sweet event publish/subscribe system with event data passed as
python dictionaries. You can create an event bus on either side of the
boundary, listen to events from either side, and publish events from either
side. It's become the primary means of asynchronous communication in the
app. It's fast, too.

My take on the wx stuff is that it always looks not quite ready to ship.
Just a bit buggy, with just a few too many warts. I'd love to see them sit
down and really nail a solid release across all their platforms and then
sit on it. We ended up building our own, which was probably a waste of time.

Kent
Post by Dr Andrew Perella
Maybe Boost.Python has improved, but I last tried it out 2 years ago when
compiler support for the heavy template use
was so terrible that I just don't think it was practiacal for any large
scale project - compiling could take 10 minutes
for one c++ file. We moved to SWIG and found it served us well. 95% of
the binding to C++ is automatic so anyone can do
it. I would be interested in hearing experiences of anyone who has moved
from swig to boost.python in case we should
look at that again.
Oh, and a great thumbs up to wxPython. Can't beat it.
Regards,
Andrew
Post by Scott Henderson
-----Original Message-----
Behalf Of Nick Trout
Sent: 19 May 2005 02:49
Post by Luis Villegas
Behalf Of Tom Plunket
I estimate that my productivity with Python is easily 10x what
it is with C++. Alas- I have yet to try interfacing it with
C++, but it is allegedly very easy.
It's reference counted, so be careful. If you're going to interface
Python and C++ (in tools) use Boost.Python. It lets you write binding
code in Python style in C++.
Post by Luis Villegas
I have used wxWidgets via
wxPython, though, which is an interface built using SWIG, I
believe, onto the C++-based wx.
wxWidgets (what MFC should have been) is the largest, most portable GUI
library that I've found. wxPython is great and would be very good for
this tile editor. Mmmm, I just remembered you can embed PyGame in
wxPython, so tile editor using PyGame in wxPython would be very quick to
write.
N
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read,
copied and used only by the intended
Post by Scott Henderson
recipient. No communication sent by e-mail to or from Eutechnyx is
intended to give rise to contractual or
Post by Scott Henderson
other legal liability, apart from liability which cannot be excluded
under English law.
Post by Scott Henderson
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus
Post by Scott Henderson
Control Centre.
www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied
and used only by the intended recipient. No communication sent by e-mail
to or from Eutechnyx is intended to give rise to contractual or other
legal liability, apart from liability which cannot be excluded under
English law.
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Control Centre.
www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
----
Kent Quirk
CTO, CogniToy
Emmanuel Astier
2005-05-19 15:13:22 UTC
Permalink
I also tried both SWIG and boost a few years ago, and
boost gave me bloated code that was much more less
effective ( I could see it in my profiles ).

But I think they changed it quite a lot.

I also found wxPython a very efficient GUI maker.
But I still miss a very good IDE for Python.

Boa is quite good, and is a visual tool for wxPython,
but I miss a free IDE with refactoring feature for
Python.

Emmanuel
Post by Dr Andrew Perella
Maybe Boost.Python has improved, but I last tried it
out 2 years ago when compiler support for the heavy
template use
was so terrible that I just don't think it was
practiacal for any large scale project - compiling
could take 10 minutes
for one c++ file. We moved to SWIG and found it
served us well. 95% of the binding to C++ is
automatic so anyone can do
it. I would be interested in hearing experiences of
anyone who has moved from swig to boost.python in
case we should
look at that again.
Oh, and a great thumbs up to wxPython. Can't beat
it.
Regards,
Andrew
Post by Scott Henderson
-----Original Message-----
Behalf Of Nick Trout
Sent: 19 May 2005 02:49
Post by Luis Villegas
Behalf Of Tom Plunket
I estimate that my productivity with Python is
easily 10x what
Post by Scott Henderson
Post by Luis Villegas
it is with C++. Alas- I have yet to try
interfacing it with
Post by Scott Henderson
Post by Luis Villegas
C++, but it is allegedly very easy.
It's reference counted, so be careful. If you're
going to interface
Post by Scott Henderson
Python and C++ (in tools) use Boost.Python. It lets
you write binding
Post by Scott Henderson
code in Python style in C++.
Post by Luis Villegas
I have used wxWidgets via
wxPython, though, which is an interface built
using SWIG, I
Post by Scott Henderson
Post by Luis Villegas
believe, onto the C++-based wx.
wxWidgets (what MFC should have been) is the
largest, most portable GUI
Post by Scott Henderson
library that I've found. wxPython is great and
would be very good for
Post by Scott Henderson
this tile editor. Mmmm, I just remembered you can
embed PyGame in
Post by Scott Henderson
wxPython, so tile editor using PyGame in wxPython
would be very quick to
Post by Scott Henderson
write.
N
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_____________________________________________________________________
Post by Scott Henderson
This e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended
Post by Scott Henderson
recipient. No communication sent by e-mail to or
from Eutechnyx is intended to give rise to
contractual or
Post by Scott Henderson
other legal liability, apart from liability which
cannot be excluded under English law.
Post by Scott Henderson
This message has been checked for all known viruses
by Star Internet delivered through the MessageLabs
Virus
Post by Scott Henderson
Control Centre.
www.eutechnyx.com Eutechnyx Limited. Registered in
England No: 2172322
_____________________________________________________________________
Post by Dr Andrew Perella
This e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended
recipient. No communication sent by e-mail to or
from Eutechnyx is intended to give rise to
contractual or other legal liability, apart from
liability which cannot be excluded under English
law.
This message has been checked for all known viruses
by Star Internet delivered through the MessageLabs
Virus Control Centre.
www.eutechnyx.com Eutechnyx Limited. Registered in
England No: 2172322
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
_____________________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos !
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com
Michael Walter
2005-05-20 00:57:12 UTC
Permalink
Post by Scott Henderson
-----Original Message-----
On
Post by Scott Henderson
Behalf Of Phlip
Sent: May 19, 2005 7:32 PM
Subject: Re: [Sweng-gamedev] Effective use of C?++ exceptions?
Post by Justin Heyes-Jones
Being able to edit and continue has been a fantastic debugging/code
writing tool. Lisp has had it for decades. I used to step through my
code after it was written to make sure it was all good, now I can
step
Post by Scott Henderson
Post by Justin Heyes-Jones
through it and correct it as I go.
Have you tried unit tests? They give exactly this benefit you
describe, sustainably.
What he is describing can be used for developing unit tests as well.

Michael
Justin Heyes-Jones
2005-05-20 01:06:59 UTC
Permalink
Post by Michael Walter
What he is describing can be used for developing unit tests as well.
Michael
I don't go the whole way and do unit tests; I'm not sure how well it
would work for a lot of the gameplay and AI stuff I do. What I'm more
into, and what I find producers and publishers want, is to be able to
change and tune features quickly right in front of them, and that's
where anything that speeds up or bypasses the traditional build, run,
test kind of development is a great thing.
Mat Noguchi (BUNGIE)
2005-05-21 20:26:13 UTC
Permalink
http://www.workspacewhiz.com/OtherAddins.html#FastSolutionBuild

The latest version should improve link times tremendously if you turn on incremental linking, assuming you split your project across multiple .vcproj files. It does introduce some interesting link-time behavior, as it forces the linker to link against the object files generated from a library .vcproj rather than the library itself.

MSN

________________________________

From: sweng-gamedev-midnightryder.com-***@lists.midnightryder.com on behalf of Charles Nicholson
Sent: Sat 5/21/2005 11:23 AM
To: sweng-***@midnightryder.com
Subject: Re: [Sweng-gamedev] Effective use of C?++ exceptions?



We have a 3-minute link time on the xbox right now (no kidding).
"Rapid iteration" is something of a joke for those of us working on
Live. :) It often takes longer to build the game than it does to
make the change and test it.
Post by Justin Heyes-Jones
IME the link time is often way longer than the compile time, so
limiting your code changes really does nothing to improve your edit,
run, test cycle. Obviously being careful with header dependencies
helps out with that.
Not using edit and continue because sometimes it doesn't work seems a
shame. Sure something subtle could get messed up that you don't know
about, resulting in code that you think works but really doesn't. But
once you run again after a 'real' build you will find out for certain.
I have had very few problems with edit and continue.
_______________________________________________
Sweng-gamedev mailing list
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Chuck Walbourn
2005-05-22 00:02:36 UTC
Permalink
Post by Justin Heyes-Jones
IME the link time is often way longer than the compile time, so
limiting your code changes really does
Post by Justin Heyes-Jones
nothing to improve your edit, run, test cycle. Obviously being careful
with header dependencies helps out
Post by Justin Heyes-Jones
with that.
The increasing bottleneck of link-times comes from a number of factors.
For one, PC developers have gotten used to the idea that compilation is
expensive but that link-time generation is just a file copy with a
little fix-up. While this was true of older-generation compilers, the
modern Visual C++ compiler does a lot of stuff at link-time which
results in higher performing code. The very time-intensive stuff is
optional (Whole Program Optimization, Profile Guided Optimization), but
some things are always on because they result in better code.
Developers need to stop thinking of link-time as a fix-up. In some
cases, code isn't actually generated until link-time and your compiling
machine needs more "muscle" to do it quickly.

The habits of game programmers also contribute to this. The 'monolithic
executable' model means we are seeing 10 Megabyte + release mode
executables. Since the linker requires working memory proportional to
the amount of code in a single execution unit, this requires a whole lot
of memory. In some cases, these large monolithic exe's require much
more than the 2 GBs of RAM supported by the 32-bit OS or even 3 GBs with
a /3gb boot, so your performance drops off a cliff due to virtual memory
paging. If your code base is split into DLLs rather than static libs,
your link-times will go down. I recognize that there are some concerns
about using DLLs, but you could use them in your 'prototype' phase to
get faster iteration time.

In short, developers needs much better machines to compile & link these
days because the tools are more sophisticated. You should have a
dedicated build machine that can support WPO/PGO builds on a regular
basis. The VC team is getting a lot of feedback to try to optimize the
linker's performance, which is certainly something they are doing, but
many developers seriously hinder the modern linker by habit and using
low-spec development machines.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
Chuck Walbourn
2005-05-22 21:14:32 UTC
Permalink
Post by Brad Might
Try Common Lisp. If you really want a higher level language, its got
more power than any other general
Post by Brad Might
purpose language, as well as the flexibility of scripting languages.
We're using it for an MMO engine and
Post by Brad Might
clients.
While certainly a powerful and well-established language, writing and
more importantly reading LISP code requires high-proficiency
programmers and strong formatting discipline. It certainly can be a
useful language for scripting--AutoCAD has used it for years--but it
does not qualify as a 'silver bullet' solution.

-Chuck Walbourn
SDE, Windows Gaming & Graphics
Tom Plunket
2005-05-22 21:49:50 UTC
Permalink
Post by Chuck Walbourn
Try Common Lisp. If you really want a higher level language...
While certainly a powerful and well-established language, writing
and more importantly reading LISP code requires high-proficiency
programmers and strong formatting discipline.
One might argue that we (as an industry) could stand a bit more
discipline from our programmers. Plus it's not like many of us
put these sorts of ads into Gamasutra:

: Seeking basically-qualified individual to join our team of people
: who sort of like playing games. You should be alive, you should
: be able to write code that will compile, and you must possess a
: slight desire to be of average ability.

Sure- there may be teams for whom such an ad would be perfect,
but then again these aren't the teams looking to make their lives
easier by embracing technology that already exists.

...of course, I do understand fully that the industry mantra is,
"we've always done it this way and it's worked just fine, so why
would we want to change it", but I still keep hoping we'll grow
up one day.

-tom!
Loading...