On Friday, 26 September 2014 at 09:24:19 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
>>> - RAII makes most sense if you have exceptions.
>>  RAII is orthogonal to exceptions, so his claim is nonsense.
>
> Just a note: this isn't really true. RAII was initially used to deal with exceptions.

This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions.

In the 90's exceptions were still being discussed at ANSI/ISO with very few compiler offering support for them. And those that did, suffered from implementation bugs.

--
Paulo

> Just a note: this isn't really true. RAII was initially used to deal with exceptions. If you want fast backtracking and just reset the stack pointer (rather than unwinding) then stack-allocated RAII objects won't work since they will be overwritten. You need to maintain a list of "destructors" in thread local memory or close to the stack root so that you can close files etc. Whether RAII is the best option really depends on what kind of execution patterns and performance characteristics you are aiming for.

 Why would you reset the stack pointer? Keep in mind, nobody uses exceptions in games. No exceptions are going to be thrown in a game context.

On Friday, 26 September 2014 at 09:42:14 UTC, po wrote:
>  Why would you reset the stack pointer? Keep in mind, nobody uses exceptions in games. No exceptions are going to be thrown in a game context.

To backtrack quickly out of deep recursion, but I am not saying this is a typical use case or what JB referred to (hence it was just a side note). I think both RAII, "finally", and more global manager-objects are reasonable solutions depending on the task.

On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
> This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions.

Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it.

And wikipedia says the same:

«The technique was developed for exception-safe resource management in C++[3] during 1984–89»

http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

«The technique was developed for exception-safe resource
> management in C++[3] during 1984–89»
>
> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

 It may have been developed for exceptions, that doesn't mean you have to use them together.

Alternative error reporting methods I prefer:
-return optional type, is empty if it failed
-accept continuation of what to do once operation secedes
  ie:
     open_file("blah.txt",
               [](file& f){..}}//called when it opened successfully
               //could also have a 2nd lambda for when it fails

On Friday, 26 September 2014 at 10:01:32 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 26 September 2014 at 09:41:09 UTC, Paulo  Pinto wrote:
>> This is completely not true, we were using RAII in C++ before any compiler had real support for exceptions.
>
> Well, I haven't read the 1990 edition of the annotated C++ reference by Stroustrup and Ellis since the mid 90s so my memory may be clouded, but that is how I remember it.
>
> And wikipedia says the same:
>
> «The technique was developed for exception-safe resource management in C++[3] during 1984–89»
>
> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

I don't care what Wikipedia says, I was there in the early C++ days happily using Turbo and Borland C++ in MS-DOS.

--
Paulo

On 26 September 2014 17:24, po via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> std::string tends to be more complicated because of the small string optimization.  Most debuggers I've used don't handle that correctly out of the box, even if sorting it out really isn't difficult.
>
>
>  Almost all game developers use Visual Studio, and VS has supported
> visualization of all STL containers(including string) since VS2005.
>
>
>> This is really missing the point. He knows RAII is useful and he knows RAII solves freeing free'd memory. Maybe it's time to re-watch the video.
>
>
>  I watched it. None of what he said made much sense.
> His claims:
> 1. RAII is bad because exceptions.
>   -Nothing forces to use exceptions, so irrelevant
> 2. RAII is bad because you must write copy constructor,destructor etc each
> time.
>   -No you write a few basic template classes and reuse them.
>
>
>
>> Regarding exceptions, they can be used incorrectly, but I think they tend to provide better error handling than return codes *because no one ever checks return codes*.  And when you do pathologically handle error codes, the amount of code duplication can be tremendous, and the chance for errors involving improper cleanup can be quite high.  Though again, RAII can be of incredible use here.
>
>
>  That is all true, I agree that exceptions are better than error codes.
> But for games, the general design is that errors are impossible.
> The game should never fail so exceptions serve little purpose.
>
> -ran out of memory? Shut game down, this should not happen
> -couldn't open a file? Shut game down, this should never happen
> -out of bounds array access, invalid iterator etc: abort game, found during
> development, fixed, should never happen.
>
> -networking? This is one place where you do need to handle errors, but do you need exceptions just to handle this one case? Probably not

This.
I've never used an exception before. I can't imagine a reason I would
ever want to.
Networking problems won't be solved with an exception, that requires
very comprehensive logic.

On 2014-09-26 09:24, po wrote:

> -couldn't open a file? Shut game down, this should never happen

It depends on what file it's trying to open and what the failure is. If it can't find the settings file, just recreate it and move on. Perhaps report the error to the user.

-- 
/Jacob Carlborg

On 9/26/2014 8:21 AM, Manu via Digitalmars-d wrote:
> I've never used an exception before. I can't imagine a reason I would
> ever want to.

Nothrow is your friend, then!


BTW, you need exceptions if there appears in your code things like:

    if (errorHappened) goto LcleanupCode;

On 9/26/2014 2:11 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 26 September 2014 at 08:59:04 UTC, po wrote:
>>  I've worked with people who think exactly like him. They are generally
>> somewhat older, and started programming games in the 80/90's. I was not
>> impressed by the coding ability of the individuals I met who had this mentality.
>
> I'm not surprised, but if you are going to create a language for current
> practices you have to cater to whatever the practice is. They are probably less
> eager to relearn how to use C/C++.
>
> I also think many just don't want to attempt to deal with C++ std:: libs, due to
> bad experience with them in the past. So they use their own stuff instead.

I can understand the attitude. I tend to do the same thing. Including invent another programming language :-)