Archived

This topic is now archived and is closed to further replies.

Changes in C++ in the last 12 years

This topic is 5010 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I dusted off a book to learn C++ at the local library. 1992 doesn't seem that long ago, but the book gives examples of RAM as 640k. Its written for Turbo C++ but the code is the same, and it really doesn't mention that old DOS compiler much. Question is, what major changes (if any) happened to C++ since that book was published in 92. I have a modern book on programming games in c++ , but you need to know c++ before starting it, so I'm taking some mountain dew and crashing through the intro to c++ book (300 out of 700 pages the first afternoon not to mention all the chapter excercise). I know that direct3d/x, openGL, and ummm,well, 256 colors didn't exist back then, but anything structural/innovations I'll be missing out on? Floating point notation, variable types, new commands.... theres no mention of STL, but thats hit in my game programming book. Its my first programming language I've learned, but I did computer science two years back, so it all seems rather straight foreward and simple after having a test where we wrote only in machine code, and had to use it to alter L1 and L2 cache arrays Thanks, -Erik [edited by - frogsinmyhair on March 28, 2004 12:59:58 AM]

Share on other sites
The most recent C++ standard was published in 1998. Lots of stuff has changed, as I understand it. You''d be better off getting a newer book.

(MSVC still follows the older standards in at least one area. They just got around to fixing it in 2003... 5 years after the standard was published.. and the correct behavior is OPTIONAL, not the default! Absurd.)

Share on other sites
quote:
and the correct behavior is OPTIONAL, not the default!

False. VS .NET 2003 is standard compliant out-of-the-box. Even the older .h headers of the STL are not included.

Share on other sites
Good! The older VS.net (7.0 I think, you''re talking about 7.1) defaulted to the old behavior as I recall.

Share on other sites
VS.Net? I know about the C*.net''s, but never heard of that.

_Erik

Share on other sites
quote:
Original post by frogsinmyhair
VS.Net? I know about the C*.net''s, but never heard of that.

It''s just an IDE for C++ VB C# and other .NET languages. Nothing special

I don''t know how C++ was back in 1992, but the most bizzare change I have known is this:
int x = 0;cout << x << " " << x++ << endl;output:1 0

Share on other sites
"x++" is evaluated before "x".

Share on other sites
quote:
Original post by alnite
I don''t know how C++ was back in 1992, but the most bizzare change I have known is this:
int x = 0;cout << x << " " << x++ << endl;output:1 0

That''s not a change. Nor is it staying the same. The order of evaluation in a statement like that is explicitly undefined. It''s completely up to the compiler to decide.

"Sneftel is correct, if rather vulgar." --Flarelocke

Share on other sites
quote:
Original post by bobstevens
The most recent C++ standard was published in 1998.
TC1 was released last year.

Share on other sites
I feel really stupid for asking this, but could someone tell me what IDE stands for?

Share on other sites
quote:
Original post by likeafox
I feel really stupid for asking this, but could someone tell me what IDE stands for?
Integrated developer environment. Honestly, I don''t know what that includes, exactly, but that will give you something to go off of if you want to look more into it. I''ve always thought that since MSVC is an IDE, an IDE includes a code editor, compiler, other tools to help you program. Not sure if that is accurate though.

Share on other sites
Standards are only as good as how well the most commonly used compiler will follow them. Same goes for the w3c and their silly standards...

MindEngine Development
http://medev.sourceforge.net

Share on other sites
Thanks. I'm kindof new at this

Edit: Hey. What do you know, I found a "game terms" dictionary on this site. I guess I can turn to that next time.

[edited by - likeafox on March 29, 2004 7:06:45 AM]

Share on other sites
I''ve got some old lamothe books from almost that old.LOL
Seriously if you look at the code from his old books and new one''s it''s like night and day. Everything back then was pure c and no c++ anywhere. I think you are making a big mistake using that book unless you planning on writing games in dos or 16bit programs that don''t even run in xp or nt. I recommend reading thinking in c++ if you can''t afford book. And there are plenty of free c++ compiler that generate 32bit code. And latest gcc is 99% or better ansi c++ compliant as is microsoft visual studio.
The biggest change I can think of off top of my head is that there was no boolean type back then so they would use a macro to define false as zero and true as 1.
And of course everyone uses API''s like directx,opengl,etc to access the videocard whereas in my old lamothe game programming book he spend whole chapter drawing a dot to your video card using assembly and interrupts.
No need for any of that nowadays as I said unless you got a specific reason to make dos/win16 games you are on the wrong path.

If God played dice, He''d win.
—Ian Stewart, Does God Play Dice? The Mathematics of Chaos

Share on other sites
I also think that Herb Shildt''s "The Complete C++ Reference" is a great book. And it usually covers all the latest gory details. STL and all.

Share on other sites
quote:
Original post by moucard
I also think that Herb Shildt's "The Complete C++ Reference" is a great book. And it usually covers all the latest gory details. STL and all.

Herbert Schildt is widely regarded as writing some of the *worst* books out there. Read here (section 16). Also see here.

Edit: Oops, hax00red the tables :S

[edited by - OrangyTang on March 29, 2004 9:04:20 AM]

Share on other sites
quote:
Original post by Sneftel
That''s not a change. Nor is it staying the same. The order of evaluation in a statement like that is explicitly undefined. It''s completely up to the compiler to decide.
Really? My teacher said that the Standard Committee decided that the ++ operator should have been evaluated before the overloaded << operator in 1998. If you use << as binary-shift operator of course ++ gets evaluated first, but when you overload <<, the precedence shouldn''t change right? But in case of cout, << operator actually got evaluated first. That''s why in older compiler, that code outputs "0 0", because << gets evaluated first.
quote:

Good! The older VS.net (7.0 I think, you''re talking about 7.1) defaulted to the old behavior as I recall.
You can set VS.NET 7.0 to more standard-compliant?? Where and how can I do that?

Share on other sites
quote:
Original post by alnite
You can set VS.NET 7.0 to more standard-compliant?? Where and how can I do that?

There's an option somewhere to turn on correct for loop scoping. I don't remember where, it's been a while since I've used vs.net.

[edited by - bobstevens on March 29, 2004 5:54:51 PM]

Share on other sites
quote:
Original post by alnite
quote:
Original post by Sneftel
That''s not a change. Nor is it staying the same. The order of evaluation in a statement like that is explicitly undefined. It''s completely up to the compiler to decide.
Really? My teacher said that the Standard Committee decided that the ++ operator should have been evaluated before the overloaded << operator in 1998. If you use << as binary-shift operator of course ++ gets evaluated first, but when you overload <<, the precedence shouldn''t change right? But in case of cout, << operator actually got evaluated first. That''s why in older compiler, that code outputs "0 0", because << gets evaluated first.

The problem is not to do with the precedence of << and ++; it''s to do with the fact that you ''evaluate'' both ''x'' and ''x++'' without assigning to x in-between.

(ranting follows)

Personally, I think it''s a rather silly situation which is brought about by the original description of the pre/postincrement operators, as opposed to their useful behaviour. I''ll venture to say how I think it *should* behave:

1) Have only one "operator++" operator available to overload (which behaves like preincrement currently does).
2) When parsing the statement, strip out any post-increments, left to right, converting them into simple operator++ calls to be evaluated *after* the main expression (in order of appearance. Or should it be affected by parentheses? o_O )
3) Then, parse the statement normally, treating the pre-increments as ordinary unary operators; they would naturally have very high precedence, probably the same as unary minus.

It''d need a bit of further special-casing probably (return statements come to mind - need to make sure the postincrements actually execute) but I think this matches the *spirit* of pre/post increment fairly well while providing defined behaviour for all uses. Yeah?

• Forum Statistics

• Total Topics
628742
• Total Posts
2984478

• 12
• 25
• 12
• 10
• 17