Archived

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

DevLiquidKnight

C/C++ future... (not .net)

Recommended Posts

C-Junkie    1099
C++0x will update a lot of stuff, mostly with the C++ stndard library. (that''s a standards number. the x means we don''t know what year it''ll happen, yet. the latest C standard is C99. I think C++ is at C++98?)

And C++ has not been unchanging lately either. There have been several "clarifications" from the standards commitee that have changed/fixed things.

Share this post


Link to post
Share on other sites
rohde    432
C++ The Language
---------------
See the provided link above. It will be updated. Very much so.

The Visual IDE
----------------
Visual C++ will ALSO be updated by Microsoft. Their next release (2004 or 2005) will ship with an updated MFC library as well.

Visual C++ is (still) alive.



"Yeah, I would''ve killed you, but I''m glad I didn''t - the paperwork is a bitch"

Share this post


Link to post
Share on other sites
civguy    308
From what I''ve seen, C++0x doesn''t have anything interesting that isn''t already in Boost (thus semi-standard already). Well, typedef templates woohoo.. They can''t add anything to C++ since it''s already considered too complex, and they can''t remove anything since they have to stay backwards compatible. So it stays pretty much as it is. Time to move on.

Share this post


Link to post
Share on other sites
DrPizza    160
IMHO the "need" to remain backwards compatible is a complete fiction invented for god alone knows what reason, to the detriment of the language''s development.

If the language has breaking changes made to it then compiler vendors will simply offer two modes -- in the same way that they provide switches to pick between C89 and C99.

Share this post


Link to post
Share on other sites
davepermen    1047
a "version" tag, or similar, would be able to solve that..

just..

version(c++2003) {
// new code, wich is not compatible with old standards
}

and if its not in version(c++2003) {} "namespace", it will not be compiled as that..

i always thought that would help a lot.. something like that..

its not the job of the compiler imho, its job of the language to make itself save for backwards compatibility.

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Wouldn''t a version tag end up being something just as annoying as having #ifdef''s all over the place. It would also cause your testing and debugging time to multiply. Not only that it would be a lot more code to maintain.

You might be better off to avoid features in C++ that aren''t supported by your compiler (or compilers on platforms you want to port to).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
ever heard of depreciation? (er, sometimes spelled deprecation?)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Now, they should make a statements like

int **var=new int[28][71];

and

var=new int[28][71];

legal to speed up allocation and reallocation of pointers to pointers. The current method can slow your game engine down tremendously.

Share this post


Link to post
Share on other sites
foofightr    130
If you''re allocating multi-dimensional arrays so much that it''s causing you performance problems, then you''ve got a bigger problem: inefficient design.

How would a language-supported version of multi-dimensional array allocation help anything, anyway? It''s still got to actually allocate it, you know.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
The performance hit forced me to use 1D arrays in my engines to speed up reallocation. In particular, my graphics engines used 2D arrays to organize image data in the most logical manner.

I believe that statements like the ones in my other post ought to be made legal, should the programmer need a 2D array having all equally-sized rows or whatever.

The reason I''m thinking an update to the language would increase performance is because I know cases where code like:

<source>
char first[55555555],second[55555555];
first=second;
</source>

is faster than code like:

<source>
char first[55555555],second[55555555];
__asm
{
lea edi,first;
lea esi,second;
mov ecx,$55555555;
rep movsb;
}
</source>

(BTW, I know that second set of code won''t compile.) An update to the language may not speed things up, but it would reduce the lines of code needed to allocate and reallocate multi-dimensional arrays for those of us who don''t write <b>for</b> loops on a single line.


Share this post


Link to post
Share on other sites