C++ standards compliance
-
"Actually, it's not 'safe', but you can cast myvector[0] to a double *, vector is pretty much always an array internally." In fact, it IS safe to pass the address of the first element of a std::vector to a function that takes an T* - the standard explicitly states that the internal implementation of vector MUST make it backwardly compatible with c arrays. This clause was added specifically to address the problems of using std::vector with 'legacy' code that wants T* parameters. Of course, it is safe to do this only if the function simply reads or writes to the T* - if it attempts to realloc or free the memory then you have a problem!! As a general rule, I no longer use arrays at all - except for working with older libraries.
Thanks for that info. I'd not seen anything in my references on it and a friend said it was discussed in Uni as possible but not recommended, so I'd never done it myself.... Christian Secrets of a happy marriage #27: Never go to bed if you are mad at each other. It's more fun to stay up and fight.
-
That isn't exactly a compiler problem. Maybe some compilers would issue a warning and then start guessing which include file you wanted. But in general, any compiler will only do what you tell it to do. Tim Smith Descartes Systems Sciences, Inc.
I didn't say it was a compiler problem, just that I wasn't expecting my first line of my first program to produce errors :mad: I expected that '#include {iostream}' [imagine you can see <>] was a reasonable thing to enter into a VC IDE, preprocessor or not. C++/C# Student. Wither Thee VB.Net.
-
hmmm.... Someone who calls STL "Simple Template code" should be clever enough to come up with his own compiler (or should stop believing in TLA's I believe most people would have read his post to mean that the template code he was using with STL was not so convoluted as to give the people who wrote the compiler an excuse for it not to work. Shouldn't we blame the STLport guys not to get their code run on *standard* compilers? Where standard spells: what is in use today. A Standard Paper is a good thing to decide how it *should* work. But I distrust standards when they become a religion. I distrust the idea that compiler writers are free to deviate from the standards. The STLport guys should write to the standard, because it's not their fault the M$ compiler is crap and won't work properly after 5 service packs. No, I'm not satisfied with CArray and CList - but STL isn't the one stop solution either. What use is a vector if I can't pass it to a function expecting (double*, int) ? And rewriting all code to use STL instead of native arrays? (that's what pointers are, even in C++!) STL is hard to learn, tedious to type, a pain to read, almost impossible to understand for the average C++ programmer, and kan give you a false sense of absolute safety. Actually, it's not 'safe', but you can cast myvector[0] to a double *, vector is pretty much always an array internally. STL is in fact easy to learn, easy to type ( you can do a typedef if you can't be bothered with vector::iterator ), easy to read ( why not ? ) and easy to understand for the person of average intelligence willing to take the time to learn it. It is also extensible, so you can write your own container if you need to, or even write iterators for an existing container and you get all the algorithms for that iterator type for free. What do you mean by 'false sense of absolute safety' ? Don't get me wrong. I would like to have a "standard pick" when it comes too "well then I must remember all the values". I do believe in a world where each API and each and every code snippet is wrapped up nicely in "good behaving" objects. I do think that abstraction is a good thing most of the day. But when it boils down, I need to know something about the internals of my containers. Why there *are* different one dimensional container implementations anyway, if not for their implementationla differences? If you read any good STL documentation then you can understand how each container is going to be implimented,
Mike Burston's info was new to me, too - but I remember I was once show an string implementation which did actually use a linked list of string sections. Complexity: Well, I assumed, too, that *his* templates were a level belowSTL's complexity - but he fed them to STL, which adds up. "Blame the STLPort writers" The points I was trying to make: a) When MS writes an STL implem that doesn't work with other compilers, who's the bad guy? b) Was his problem really a standard issue MS tried to evade - or was ist just they couldn't handle the template code? Thats a pity, and the more so since templates bring VC++ to it's knees very often. But it's a question of compiler quality and a standard nailed mile high to the wall. Btw. gcc didn't do the job either, did it? When I announce "cross platform", It's my job to make sure it *is*. I can't tell my customer "Oh, yes, you can't print, since IE doesn't do what's written in MSDN" - I have to find a workaround - not my user. This is no fun, and it makes me scream (sometimes literally), but it's *my* damn responsibility. I understand a free STL implementation is not the same - but not too far either. Saying "This is a great STL implementation - if only compilers were better" is (for me)kind of "communism is best - if only people were better". Reality is as important as standards. Easy to read etc. I accept your milage may vary. I for myself are kind of template nerd, and I know my standard STL, but no more. Debugging through STL (which is my way to "look at code") is terrible. I have problems reading stranger's STL code (unless it's typedefed the way I like). I helped quite some people with learning C++, and templates proved a hurdle to almost all of them; even more the "templating level" of STL. To be fair, understanding pointers correctly (grasping their "nature") always seemed a similar problem, but IMO you get along without STL (though it hurts), but not without pointers. one of them did learn C++ for the sole enjoyment of the language - but they had or wanted to *do* something with it. false sense of safety: STL is a masterpiece - if the classes you feed as template args are well formed. If they don't follow "the rules", you can get into trouble - ST can't help you there. Another thing (I couldn't dig out any of the articles - so you're free to ignore this) are some "obscure" issues where templates *do* have problems together w/ exceptions, and just can't be implemented correctly. Looking at the source of a particular implementation parti
-
"Actually, it's not 'safe', but you can cast myvector[0] to a double *, vector is pretty much always an array internally." In fact, it IS safe to pass the address of the first element of a std::vector to a function that takes an T* - the standard explicitly states that the internal implementation of vector MUST make it backwardly compatible with c arrays. This clause was added specifically to address the problems of using std::vector with 'legacy' code that wants T* parameters. Of course, it is safe to do this only if the function simply reads or writes to the T* - if it attempts to realloc or free the memory then you have a problem!! As a general rule, I no longer use arrays at all - except for working with older libraries.