[Semi OT] Language for Game Development talk
Paulo Pinto via Digitalmars-d
digitalmars-d at puremagic.com
Sat Sep 20 04:25:32 PDT 2014
Am 20.09.2014 04:25, schrieb po:
> He actually talks about Andre around 40' ;0
>
> As a fellow game dev:
>
> I don't agree with him about RAII, I find it useful
He seems to miss the point that it is possible to write general purpose
RAII templated classes, since he keeps on talking about specific
implementations for each type of resources.
>
> He kind of has a point about exceptions, I'm not big on them
>
Exceptions in most programming languages that have them are a good idea.
Exceptions in C++ are a broken concept.
Having to cope with C semantics, ability to disable them and mixing code
bases is what leads to the pain of writing exception safe code in C++.
>
> I get the impression his C++ knowledge is about the level of C++ with
> classes, ie very low.
>
At the end he states having only read K&R C, with everything else being
learning on the job, it seems.
> He claims using std:: inherently causes slow compilation, my experience
> says otherwise.
Back when I was stil working with C++ at day job, doing a "make world"
in a code base with Tools.h++ would cost a few hours.
And we were using ClearMake optimized build infrastructure.
You can have fast builds, but it requires knowledge of the whole
architecture and coding for the build system, e.g. separating modules
into real libraries.
>
> He goes on about "freeing free'd memory", this is never something that
> would happen in modern C++, so he is basically proposing an inferior
> language design.
>
>
> At one point he says you can't see the contents of std::vector in a
> debugger. What? This is trivial and has worked in every version of
> Visual Studio for the last 5+ years.
It also surprised me. Visual Studio has the best developer experience in
terms of visualizing C++ data structures.
>
> I do agree the build systems used with C++ are idiotic
>
> IMO, C++'s complexity is largely because of the stupid headers and all
> the mind numbing crap associated with it. That and the lack of any
> reflection.
>
I wonder if modules in C++17 will already be too late.
By then, when looking at C++ project, it might be pre-C++98, C++11,
C++14, C++17 with the accumulated set of semantics, differences and
styles each standard revision brings to the table.
--
Paulo
More information about the Digitalmars-d
mailing list