STL support in VC++.
-
Please provide good support for STL in VC++ so that the STL based (correct)code compiles and builds without warning an errors in VC++ or provide some compiler/linker switch to make the code build correctly with STL. Also, MS should work to make STL implemenation more effecient than that of the SGI implementation (which is freely available) or licence the SGI implementation and include it with VC++. It will be great service to C++ programming community and save us lot of frustration which we have over the current (poor) support for STL and templates in VC++.
-
Please provide good support for STL in VC++ so that the STL based (correct)code compiles and builds without warning an errors in VC++ or provide some compiler/linker switch to make the code build correctly with STL. Also, MS should work to make STL implemenation more effecient than that of the SGI implementation (which is freely available) or licence the SGI implementation and include it with VC++. It will be great service to C++ programming community and save us lot of frustration which we have over the current (poor) support for STL and templates in VC++.
Here here! I have spent a lot of time moving away from MFC C++ (CString etc...) to Standard C++. This way I can write code once, and have it work on Linux, Mac, BeOs - whatever! Moreover Standard C++ is far more powerful, and I would argue, more efficient, than MFC. MFC and the like have their uses - the creation of a platform specific user interfaces. (An 'interface class' that made cross platform GUIs a possibilty would be a great thing wouldn't it....) -- Leon http://www.lost.co.nz
-
Here here! I have spent a lot of time moving away from MFC C++ (CString etc...) to Standard C++. This way I can write code once, and have it work on Linux, Mac, BeOs - whatever! Moreover Standard C++ is far more powerful, and I would argue, more efficient, than MFC. MFC and the like have their uses - the creation of a platform specific user interfaces. (An 'interface class' that made cross platform GUIs a possibilty would be a great thing wouldn't it....) -- Leon http://www.lost.co.nz
Whatever the warts on the MFC container classes, I think that they are more efficient (from an execution perspective). That is, afterall, one of the reasons that MS cites their existance.
-
Whatever the warts on the MFC container classes, I think that they are more efficient (from an execution perspective). That is, afterall, one of the reasons that MS cites their existance.
Have you tried benchmarking them? I tried a few tests a while back and each of tests where either almost the same, or STL was a lot faster. The only exception being a map lookup. The reason the MFC collection classes exist is because when they where first created there was no STL, or indeed templates - hence CObArray, CObList, etc. There are many reasons to use STL in preference to MFC for collections, the only reason I can think of to use MFC over STL is "because we always have".
-
Whatever the warts on the MFC container classes, I think that they are more efficient (from an execution perspective). That is, afterall, one of the reasons that MS cites their existance.
The MFC container classes are up to 10x *LESS* efficient than their STL counterparts. I've profiled them, and the STL is much faster, and if you use the SGI STL, then that's even 10x faster yet. What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL.
-
The MFC container classes are up to 10x *LESS* efficient than their STL counterparts. I've profiled them, and the STL is much faster, and if you use the SGI STL, then that's even 10x faster yet. What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL.
What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL. Not to mention the MFC classes have understandable docs and method names.
GetHeadPosition()makes a lot more sense to me thanbegin(), since "begin" by itself doesn't convey what the method does. On top of that, the alleged "documentation" of the STL classes is horribly-written. IMNSHO. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history? -
Please provide good support for STL in VC++ so that the STL based (correct)code compiles and builds without warning an errors in VC++ or provide some compiler/linker switch to make the code build correctly with STL. Also, MS should work to make STL implemenation more effecient than that of the SGI implementation (which is freely available) or licence the SGI implementation and include it with VC++. It will be great service to C++ programming community and save us lot of frustration which we have over the current (poor) support for STL and templates in VC++.
...ok. i'll see what i can do. :) -c
-
What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL. Not to mention the MFC classes have understandable docs and method names.
GetHeadPosition()makes a lot more sense to me thanbegin(), since "begin" by itself doesn't convey what the method does. On top of that, the alleged "documentation" of the STL classes is horribly-written. IMNSHO. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?begin(), however, makes perfect sense to anyone that knows the STL's basic design. The STL seeks to abstract common operations into common algorithms. Iterators are just one form of that, and they all use the same syntax. GetHeadPosition makes little or no sense when you're dealing with a reverse_iterator ;) Also, the "documentation" on the STL is not intended to be tutorial, but rather reference. Even so, VC's docs break down quite quickly. That's why I keep my Stroustrup and a few other key references handy at all times.
-
The MFC container classes are up to 10x *LESS* efficient than their STL counterparts. I've profiled them, and the STL is much faster, and if you use the SGI STL, then that's even 10x faster yet. What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL.
Apart from std::map vs CMap. MFC maps can be 10x faster than stl since they are hashed. Roll on VC7 with std::hash_map...
-
What the MFC container classes have going for them is that they are more traditionally designed and don't require learning the generic paradign of STL. Not to mention the MFC classes have understandable docs and method names.
GetHeadPosition()makes a lot more sense to me thanbegin(), since "begin" by itself doesn't convey what the method does. On top of that, the alleged "documentation" of the STL classes is horribly-written. IMNSHO. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?On top of that, the alleged "documentation" of the STL classes is horribly-written. The MS online documentation is horrible, but so is their online documentation of the C++ language. I challenge anyone to try to implement a placement new operator based on the MS documentation of the C++ language, but I don't avoid coding in C++ because of that. I just buy appropriate books. Anyone who is serious about STL should buy Musser and Saini's The STL Tutorial and Reference Guide, which really explains the STL very well. I have been using STL heavily for the past three years and this book is always beside my desk. Someday, when MS does support partial template specialization (PTS), Matthew Austern's Generic Programming and The STL: Using and Extending The C++ Standard Template Library will also be indispensible, but it's pretty useless today, since many generic programming idioms rely on PTS. He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
-
begin(), however, makes perfect sense to anyone that knows the STL's basic design. The STL seeks to abstract common operations into common algorithms. Iterators are just one form of that, and they all use the same syntax. GetHeadPosition makes little or no sense when you're dealing with a reverse_iterator ;) Also, the "documentation" on the STL is not intended to be tutorial, but rather reference. Even so, VC's docs break down quite quickly. That's why I keep my Stroustrup and a few other key references handy at all times.
begin(), however, makes perfect sense to anyone that knows the STL's basic design. Therein lies the problem. The name is meaningless to someone who hasn't already learned what it means. "begin" is a verb, and as such implies that begin() performs some action; however, calling begin() doesn't actually do anything to the collection. It just returns an iterator, and you use that to access the items in the collection. "beginning" (a noun) would have been a clearer name. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?
-
begin(), however, makes perfect sense to anyone that knows the STL's basic design. Therein lies the problem. The name is meaningless to someone who hasn't already learned what it means. "begin" is a verb, and as such implies that begin() performs some action; however, calling begin() doesn't actually do anything to the collection. It just returns an iterator, and you use that to access the items in the collection. "beginning" (a noun) would have been a clearer name. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?
You make a valid point about the function name 'begin', but it all seems a little overstated. The first thing to do with any code library is to get familiar with the basic concepts and terminologies, and in all honesty I think it would take most programmers about 3 minutes (max) to figure out what 'begin' and 'end' mean in the STL. Once learned, they apply across the range of STL containers. And that's the biggest appeal of the STL - once you start to get 'inside' the structure and philosophy (and I don't thing that's as hard as some people think - one good STL book and you're on your way), the entire STL just 'expands' into a very consistent, well designed framework that (a) gives you an immediate pool of powerful algorithms and classes and (b) provides a basis for extending the library in ways that suit your needs. MFCs collection classes, on the other hand, feel very much like a gathering of classes that are each designed to fill a particular need, and are then brought together because they 'look similar', even if they have no real underlying similarities. To me, though, the bigger issue is not where we are now, but where we'll be in the future - the STL provides a standard, approved, agreed upon set of containers and algorithms. They are available on any version of C++, on any platform, that wishes to call itself 'standard C++' (yes, I'm choosing to ignore the details here of things like 'partial template specialisation' - obviously VC cannot call itself 'standard C++' until it finally adds such things). As a quick example of what I mean, take 'CList' versus 'std::vector'. If I'm writing an MFC program and I need a container, CList is probably a better choice. If I'm writing a program for other operating systems, or that does not interface into any MFC code, then 'std::vector' is the (only) choice. So as a windows programmer who often writes non-mfc code, I must learn two containers - CList and std::vector - then solve the issues that arise when I try to connect such code. I'd rather spend my programming time solving the client's issues, rather than getting the operating system, GUI framework and programing language to co-operate in deciding how to store ints !!! So, hopefully (but I would doubt this very much!!) the future will bring both (a) a version of MFC where functions that currently take a 'CArray' parameter would also have an overloaded alternative that takes a 'std::vector' (backward compatability is maintained by using overloaded functions), and (b) a new 'windows.h' where api cal
-
begin(), however, makes perfect sense to anyone that knows the STL's basic design. Therein lies the problem. The name is meaningless to someone who hasn't already learned what it means. "begin" is a verb, and as such implies that begin() performs some action; however, calling begin() doesn't actually do anything to the collection. It just returns an iterator, and you use that to access the items in the collection. "beginning" (a noun) would have been a clearer name. --Mike-- http://home.inreach.com/mdunn/ Is history an illusion caused by the passage of time, or is time an illusion caused by the passage of history?
begin() is merely a symptom of the C++ tendancy to use the shortest possible uncapitalized name for things. Reducing typing seems to be a #1 priority ;) end() can be either a noun or verb.