C++ standards compliance
-
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
-
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
You havent seen anything yet - just wait until that crapy "Managed C++" will come out for good. Try porting THAT! I tend to think that Microsoft is dropping the ball on C++ and they will push hard in VB and C# direction. Borland has a good chance to win a C++ market on windows again, which is not bad actually...
-
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
have you tried the Dunkumware stuff? why would MS be interested in letting you write portable code? -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
-
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
I found the STLport 4.0 STL pretty good and i didn't find a bug yet though i use it quite extensively (especially maps). I found also that the "built-in" workarounds for making it work with VC++ 6.0 are pretty good (i never had to place a #ifdef around a STL-only code part). Maybe you can post the problems you've had while using STLport 4.0 (especially the problem with the maps)?
-
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
I have not tried it yet - but you may wish to try VC7 in the VS.NET beta. The VC developers have made a lot of commitment to making this compiler more compliant with standards, finally. However, it is pretty well known that the Borland compiler is the "most compliant" (with the ANSI/ISO standard) of the commercial C++ compilers available. Dale Thompson
-
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
C/C++ users journal had a roundup on all major compilers, very good article indeed. Search on www.cuj.com. I did not find any problem with STLPort, use this stlport for posting map problems. Another option can be to buy upgrades for Dinkumware site. Igor Proskuriakov
-
I have not tried it yet - but you may wish to try VC7 in the VS.NET beta. The VC developers have made a lot of commitment to making this compiler more compliant with standards, finally. However, it is pretty well known that the Borland compiler is the "most compliant" (with the ANSI/ISO standard) of the commercial C++ compilers available. Dale Thompson
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|
-
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
-
have you tried the Dunkumware stuff? why would MS be interested in letting you write portable code? -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
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
-
I found the STLport 4.0 STL pretty good and i didn't find a bug yet though i use it quite extensively (especially maps). I found also that the "built-in" workarounds for making it work with VC++ 6.0 are pretty good (i never had to place a #ifdef around a STL-only code part). Maybe you can post the problems you've had while using STLport 4.0 (especially the problem with the maps)?
The total code would be fairly tedious, but the problem is that I use equal_range to find the lower bound and upper bound for a key in the multimap. When I iterate over the multimap using the lower and upper bound and try to print the contents of the values for the key, it throws an exception. Somewhere along the line, the multimap contents are getting corrupted. (I can see this happening.) But I'm not doing it. I'm not deleting pointers or leaking memory: I've just read in contents from a file into the multimap and am doing a lookup based on the key. This same exact code works fine under Borland and GCC. If you'd really like to see the code, I'll email it to you rather than clutter the lounge. CodeGuy http://groups.yahoo.com/group/wtl
-
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.