Printable View
Back to the original question:
A referece cannot be reassigned to another variable.
Anyway, if you need to reassign references, then a pointer makes more sense.Code:double x=1.0, y=2.5;
double &z = x;
z = y; // assigns the value 2.5 to x, not the reference of y to z
- Kevin
Paul McKenzie, i don't have those codes anymore, it was years ago, only one i can possibly get is the gcc and semaphore one.
Hmm.. I have yet to see an actual case where arrays are more optimized than properly used vectors (of course, don't push_back everything when the size is statically known -- as they must be for arrays). I have had to do a whole lot of strange and intensive manipulations on data structures, many of which have a backbone that could be represented as a statically sized array or vector, and I have done at several times the profiling to see what would be quicker. Almost always I got the same speed (there was a problem once with the Visual C++ compiler not removing one added layer of indirection on a very very tight loop -- two machine instructions -- but CodeWarrior is always my optimizer of choice and I think I heard -- but haven't checked the disassembly -- that the newer .NET c++ compiler does static indirection elimination optimization properly).Quote:
Originally posted by KevinHall
However, if your application is very CPU intensive, there are sometimes arrays are better. For example:
(1) A matrix class. Using a pointer with new to define a (protected) array is usually more efficient than defining a vector of vectors.
(2) In an FFT system analysis program I have been dealing with. I have to aquire and analyze real-time about 1MB/sec of data with even slow P1 and P2 systems. Using arrays instead of vectors here helps optimize the performance.
But the best and fastest matrix and FFT codes I have seen used heavy template metaprogramming to build the static data structures in a way that could be used to optimize element-wise the transformation (by forcing inline code through templates, forcing RVO, unrolling loops with templates, etc.). A good example of a matrix class that is available freely online is the one with Blitz++, but it doesn't implement all the features I have seen as regards speed. The FFT examples I have seen benefitted immensely from the translationtime evaluation of the transform coefficient multiplication. But in all these cases, it is the use of static translationtime data structures and not runtime structures like arrays or vectors that form the seat of the speed increases, and a simple seating of the results inside a vector or an array (where the runtime calculations may occur) doesn't seem to in any way be a cause of speed problems.
I use token pasting all the time since I do a lot of API interception and have simple rules for naming my interception functions. I use them to build up the vectors of function pointers used in the interception. I did use to use arrays here, however, but thought they were too unsafe. :)Quote:
Also posted by KevinHall
I know that token pasting is part of the preprocessor, however I have seen it used much, much more in C to accomplish things like writing "template"-macros. I have rarely seen token pasting in C++ b/c of the ability of C++ to handle templates, namespaces, etc.... Of coarse there are situations where token pasting is useful for C++.
Well, neither can a pointer passed by value to a function, at least not visibly outside the function (we are talking memory location here, right?). And if one wanted it only inside the function, it would require setting up an automatic variable to get the new address or using pointer math (for arrays? -- this is the particular unsafe operation which is why one wants to use vectors or smart-pointers with array semantics and bounds checking).Quote:
Also posted by KevinHall
A referece cannot be reassigned to another variable.
I'm not trying to pick on you Kevin, since I understand what you are trying to say, that one shouldn't unlearn anything about arrays since they may come in handy in one's toolkit when the circumstances dictate. However, I must admit that I started programming (well after the interpreted languages of Logo and BASIC) in c and even moved into c++ with the "help" of Schildt. So I had a lot of c style to my early programming in c++. But as I've continued to study and test my projects, I have found that the only time I use arrays anymore is when I am tossing together a translationtime assert (with array size -1 on false evaluation). And naked pointers (keeping topicality to the thread :)) are only found in my code as private class members. From what I can tell from the c++ community and the recent publications, this seems to be the natural progression, and I think I agree with it.
Actually the BC and gcc "bugs" sound like common programming errors from the description. The BC error sounds like the common problem of mistaken scope and passing stack values, and is common in ctors. The gcc error sounds like scoping and variable lifetime problems. Both of these compilers are quite commonly used by professionals, and although they do have known problems which they list on their respective sites, none of them are as basic to the language as what is suggested. If you however feel you have found some bugs, post them in a new thread and have them publicly evaluated. They are not, however, by any means reasons to not use the language properly except as workarounds are needed, but I understand that was not your point.Quote:
Originally posted by Luis G
btw, i have found some bugs in compilres, a while ago the old BC 3.1 throwed me some bugs into my program, basically, a variable would change its value right after the constructor, even thou it was specified in the constructor to set it to 0, i debug it step by step with a watch, and just after the constructor ended it would change the value back to -1. i didn't like the solution i had to use, which was declaring the variable as "unsigned int", weird huh?
[...]
gcc doesn't like function calls in an if statement (specifically semaphore creation), i had to call semget before the if statement and save its returned value into a variable to get the program working fine, unbelievable, but it took me almost 4 hours of madness to discover that it wasn't my code the one that was introducing unexpected behaviour.