C++ standards compliance
-
VC7 is better than VC6, but they still don't support the 'export' keyword. Also, they did not fix the bug with wcout << L'A' I vote pro drink X|
-
No, I haven't tried a Dinkumware upgrade. I thought about it, but how would I know that my code would compile or be any more compliant if I purchased the Dinkumware patches? At least I can test STLPort or Borland's stuff because it's free. You are right about Microsoft -- from the direction they are taking with C#, I do not think they are interested at all in pure C++. They are interested in developers writing Windows apps. But if they frustrate their C++ developers with workarounds for their tools, so that no one can learn the language, then people will switch to compilers that do work. Well, at least I will. :-) CodeGuy http://groups.yahoo.com/group/wtl
Give Dinkumware a try. We had STL-based code that was supposed to work on both Win32 and Windows CE, and use of Dinkumware Abridge Library helped us a lot (it's not cheap though, $400 per developer). One weakeness of Dinkumware implementation was that they did not have support for Unicode strings - and this is what you expect to have on WinCE. Apart from that it was great. Vagif Abilov COM+/ATL/MFC Developer Oslo, Norway
-
I must admit VC6/7 is not the easiest thing to learn with. My first c++ program, the usual one, my first line created an error because I 'missed' the ".h" between the "<>" brackets. I almost gave up then and there! C++/C# Student. Wither Thee VB.Net.
-
Give Dinkumware a try. We had STL-based code that was supposed to work on both Win32 and Windows CE, and use of Dinkumware Abridge Library helped us a lot (it's not cheap though, $400 per developer). One weakeness of Dinkumware implementation was that they did not have support for Unicode strings - and this is what you expect to have on WinCE. Apart from that it was great. Vagif Abilov COM+/ATL/MFC Developer Oslo, Norway
-
I've started heavily using STL on a project I'm working on. I started out working with VC++ 6.0 and quickly determined that MS's STL was rather pathetic, so I downloaded STLPort 4.0 from the stlport.org website. I got a version of my code to compile, but I noticed that my map was getting corrupted. I tried another beta version of the STLPort, but it wouldn't compile. At this point, I switched to GCC. However, I couldn't get the to_string of my bitset structure to compile. The to_string method wouldn't compile even after following explicit directions from the SGI docs. Finally, I switched to Borland's BCC55 compiler, the free C++ Builder version off their web site. This (finally) compiled my code with no problems, according to standard. How can C++ continue to grow as a language when we can't even use simple template code?? I'm not talking about writing obscure template code -- this is STL, the C++ standard library, and it doesn't even work as documented on two major compilers. Not to mention that for even simple projects, any STL written for VC++ has so many workarounds that you can't directly port it to another compiler w/o making huge changes. Maybe I'm pissing in the wind here, maybe everyone is satisfied with using CArray, CList or making their own containers. But I know there have been other people that have been vocal about this subject too. I just want to encourage you to keep making your voice heard. This situation will not change unless we demand it. If the lack of compliance hasn't affected you yet, it probably will in the future. CodeGuy http://groups.yahoo.com/group/wtl
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 ;) 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. 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. 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? May there always be some memory at the end of your pointers Peter BTW what happened to the WATCOM compilers? They were great, and their optimizer did *teach* you the standard...
-
Did you guys try STLPort? We use that for both our Win32 and WinCE products. Tim Smith Descartes Systems Sciences, Inc.
Yes, we did. But if I remember it right, at that time (early 2000), STLPort 4.0 was in beta, and we had some problems. It was rather configuration problems, but due to our tight schedule we decided to go with Dinkumware. I agree, today we would have probably used STLPort. Vagif Abilov COM+/ATL/MFC Developer Oslo, Norway
-
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 ;) 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. 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. 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? May there always be some memory at the end of your pointers Peter BTW what happened to the WATCOM compilers? They were great, and their optimizer did *teach* you the standard...
Templates are not hard to learn to _use_. They may be very complex in their implementation, but it's pretty hard to see how using containers like vector and list are complicated. If the Java folks adopt and use containers like vector and list, then I think C++ folks can figure them out too. If a developer wants to explore more of the containers or algorithms, that's fine. Most can get by with the simple containers and a few straightforward member functions. The advantages of STL containers are 1) type safety, 2) throwing out_of_bounds exceptions (when using .at() ) and 3) automatic memory management. Arrays simply can't compete, and for a new developer can be disastrous. For the diehards, a vector is contiguous memory internally, just like an array. If you want, simply pass the address of the first element in the vector to a function like you would with an array. You can then use pointer arithmetic. Making standards is important in 1) portability and 2) sanity. If something important to you (say, virtual functions) changed between compiler implementations, I dare say you would have a fit trying to figure out unpredictable behavior. If you are shrugging it off because you don't use the STL -- so be it. For others, it is important. CodeGuy http://groups.yahoo.com/group/wtl
-
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 ;) 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. 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. 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? May there always be some memory at the end of your pointers Peter BTW what happened to the WATCOM compilers? They were great, and their optimizer did *teach* you the standard...
"STL is hard to learn, tedious to type, a pain to read, almost impossible to understand for the average C++ programmer..." Now, I have to disagree with you in a few simple points: 1. STL is MUCH easier to learn than e.g. pointer handling and memory management 2. You can always use typedefs. 3. STL code is very readable. 4. I consider myself an average C++ programmer :-O and I don't have any problems with understanding STL. I vote pro drink X|
-
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 ;) 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. 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. 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? May there always be some memory at the end of your pointers Peter BTW what happened to the WATCOM compilers? They were great, and their optimizer did *teach* you the standard...
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,
-
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,
"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.
-
"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.