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
C/C++ future... (not .net)
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).
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).
Author
this is prolly not that nice but
You get an A+ lol
coder requires 0xf00d before continue().
Killer Eagle Software
You get an A+ lol
coder requires 0xf00d before continue().
Killer Eagle Software
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.
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.
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.
How would a language-supported version of multi-dimensional array allocation help anything, anyway? It''s still got to actually allocate it, you know.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
