next »

[BlueSweatshirt]

I just took a look at C++0x. This is definitely awesome.

Totally looking forward to it, and it addresses a couple huge issues in C++, and makes things much simpler for the programmer.

I'm hooked, give it to me ASAP please. 

[Matt Thorson]

Yeah I don't think anyone is arguing the popularity or power of C++.  It is understood that it is very flexible and everyone uses it.

I feel like C++ is jack of all trades, master of none.

And yeah, I'll welcome C++ 0x with open arms.  It'll make my life easier that's for sure, but there's still a lot more room for improvement.

[mcc]

Does C++0x have any sort of endianness handling as part of the language standard?

[Martin 2BAM]

I don't think so, but there are a trillion libraries they can do that for you easily. In fact almost all cross-platform libraries that I can think of have an implementation for that: wxWidgets, boost, SFML, SDL...

It has better handling for UTF-8 and such, though.

[Average Software]

Does C++0x have any sort of endianness handling as part of the language standard?

I don't think that's the sort of thing a programming language is usually concerned with.

Most compilers #define some sort of macro to indicate endianness at compile time.  If you need the information at run time, there are many simple tests to determine it.

[bateleur]

I don't think that's the sort of thing a programming language is usually concerned with.

And in fact if you find yourself writing something that cares it's a good idea to encapsulate the endian-dependent code in as simple a way as possible then metaphorically tape that box shut and never open it again. Otherwise you can end up with some impressively nasty data corruption bugs.

[Average Software]

I don't think that's the sort of thing a programming language is usually concerned with.

And in fact if you find yourself writing something that cares it's a good idea to encapsulate the endian-dependent code in as simple a way as possible then metaphorically tape that box shut and never open it again. Otherwise you can end up with some impressively nasty data corruption bugs.

The only place I've personally ever needed to worry about it was when dealing with the Ogg Vorbis API, which needs to know endianness for decoding purposes.  I have a test that involves casting a short to a char and testing which byte I get, or something like that.  Another neat C++ idea for this sort of thing involves a templated union, like so:

Code:

template <typename Type1, typename Type2>
union UniversalConversion
{
    Type1 first;
    Type2 second;
};

UniversalConversion<short, char> endian_test;

endian_test.first = 1;

// Test for endianness.
if (endian_test.second == 1)
{
}
else
{
}

[Martin 2BAM]

Endianness is pretty important if you want the best performance on networking code, because you just send your info in single bytes. It becomes important to determine what endianness are you going to use and fix the packet's info when they arrive.

But I agree, it's not a language thing, it's more of a storage annoyance. Even though character encoding is too, it has bothered me a ton more times than endianness (specially when you want to work with non-english languages)

But most libraries do that for you nowadays. I really like how SFML handles it: Don't remember the names but have functions like Read/Write + 8/16/32/64/String, and if you inherit from sf::Packet or something, there is a virtual funcion you can override to define you your class is to be sent (can sent it's own objects also as packets, in addition to primitives).

[increpare]

Section 6. What is Missing?
C++ was designed under severe constraints of compatibility, internal consistency, and efficiency: no feature was included that
1. would cause a serious incompatibility with C at the source or linker levels.
2. would cause run-time or space overheads for a program that did not use it.
3. would increase run-time or space requirements for a C program.
4. would significantly increase the compile time compared with C.
5. could only be implemented by making requirements of the programming environment (linker, loader, etc.) that could not be simply and efficiently implemented in a traditional C programming environment.

Features that might have been provided but weren't because of these criteria include garbage collection, parameterized classes, exceptions, multiple inheritance, support for concurrency, and integration of the language with a programming environment. Not all of these possible extensions would actually be appropriate for C++, and unless great constraint is exercised when selecting and designing features for a language, a large, unwieldy, and inefficient mess will result. The severe constraints on the design of C++ have probably been beneficial and will continue to guide the evolution of C++.

-SIGPLAN Notices, vol. 21, no. 10, October 1986 "An Overview of C++," by Bjarne Stroustrup

<- amused me a little when I read it today

[Klaim]

Haha yes, now it's more like "you only pay for what you use" and it's much more efficient and makes you more responsible (or should, as a programmer at least).

[nihilocrat]

Do many C++ lovers prefer to write large parts of gameplay logic in Lua/Python ect? If so - why are these better than C++ for that?

I thought scripting languages were only useful to let non-technical designers take on some of the coding tasks - but I am interested in replacing some parts of my next C++ game with lua to make it more extensible.

Wrapping your code in a scripting language is awesome, because the scripting languages are much more fun, flexible, and powerful than the C++ underneath.

Speaking of Python and Lua in particular, Python is slower but more powerful (namely you can import anything from the Python stdlib!) but Lua is faster and a bit simpler to use. If you don't have any interest in using external code (i.e. you are only going to use what you wrap from C++) then Lua is probably the better choice.

I mainly have a background in web programming, which these days almost exclusively uses scripting languages (okay, except Java), so I don't understand the aversion to scripting or the attitude that they are weak toy languages.

[Martin 2BAM]

Scripting languages are really cool for some purposes, like easier debugging, on the fly modifications, run-time interpretation of the language ("eval()"), etc.

But... C++ is sexy. Yes, that's all I can come up with (besides all that has been said)
It can make your life miserable at times, but you just can't quit it. It grows in you   

[Ivan]

As I mentioned before, I think there is two types of code that's required for a game. There is engine code and then there is game-specific "content code". C++ is hands down the best choice for fast, manageable and portable engine code, but there is ABSOLUTELY NOTHING that C++ does that makes it beneficial for content code.

I think it's important to make that distinction. If you compare Flash and C++ for content code creation for example, Flash wins hands down as it provides an incredibly quick and robust way for you to get things up and running. But let's not forget that Flash itself is an engine written in C++, so to bash C++ in that case is kind of pointless.

[mewse]

Scripting languages are really cool for some purposes, like easier debugging

Easier debugging??

Wrapping your code in a scripting language is awesome, because the scripting languages are much more fun, flexible, and powerful than the C++ underneath.

More powerful??


You guys must be using some really weird definitions for those words.   :D

[Kekskiller]

Then give us some more contructive words, wise 3-line-poster.

[increpare]

I'm guessing he means that scripting languages are more powerful in the sense that they can be made behave in many different ways much more easily than C++ (lisp/scheme people, on the other hand, tend not to bother with external external scripting languages because their languages are much more flexible ).

The debugging comment is very fair point, though: scripting languages are hell to debug.  Thankfully, usually scripting code is much simpler structurally than compiled code in games   (that being the point I guess, nobody would use scripting languages if they didn't simplify things).

[Klaim]

From my short (but deep) experience with dynamic languages, debugging can be hell, but one thing makes life easier : it's faster to get to the bug. Compile time is often unoticable.

But having the wohle context information with a good debugger makes C++ really easier to debug. As said, it's only a speed problem I guess, as C++ can take a while to debug in bigger projects than hello world.

[Martin 2BAM]

From my short (but deep) experience with dynamic languages, debugging can be hell, but one thing makes life easier : it's faster to get to the bug. Compile time is often unoticable.

Yup, I meant that.
You don't need to recompile, reproduce the same state you where at, etc.
With the appropiate tools you can even execute code on the fly while debugging (to fix a state and make it less explosive).
Also because of this you can get computed values from the state of an object, instead of just it's primitive guts.
In most C++ compilers, classes must implement their own dumping procedures (in external precompiled libraries) so the debugger IDE knows how to show them.

Also:
MSVC++'s "Edit & Continue" takes about 4 times what it takes normal compiling, and most of the cases ends up saying "sorry, I can't do shit"... even for the simplest change that's not an fricking assignment 

Why do you guys say it's hell to debug a dynamic language?

Thanks!

[increpare]

Why do you guys say it's hell to debug a dynamic language?

I didn't say 'dynamic', I said 'scripting'.   Generally the source of the hell is lack of debugger.  Generally, languages without debugging tools can be annoying to debug.

VS Edit and continue is a big pile of fucking bs that can suck my cock.

[BlueSweatshirt]

VS is a big pile of fucking bs that can suck my cock.

Fixed that for you.