STL thoughts
-
Great! Mike, you just hit on my biggest woe with using STL (which I love). Thanks. On the topic, does anyone know of a good *online* STL reference? I've seen a few wonderful paper versions, but it would be handy to keep something searchable on my machine- and I don't trust any of the documentation in MSDN.... Often, I come across something wonderful in STL (like the string tokenising noted above) and feel like singing and dancing... :) everyone here is a bit sus on the STL and I have to keep quiet :( The solution... an STL forum!!! I know we have a VC++ forum, but it's kind of in a different vein to what I mean... Chris? cheers NB
Here is the SGI one http://www.sgi.com/tech/stl/stl\_index\_cat.html Tim Smith Descartes Systems Sciences, Inc.
-
I wonder how many people are like me and just end up using vector, set, map, and a few other assorted classes. I hardly if ever use the algorithms directly. Tim Smith Descartes Systems Sciences, Inc.
I was the same way until I started reading "Effective STL" by Scott Meyers. It's a great book. I definitely recommend it.
-
Great! Mike, you just hit on my biggest woe with using STL (which I love). Thanks. On the topic, does anyone know of a good *online* STL reference? I've seen a few wonderful paper versions, but it would be handy to keep something searchable on my machine- and I don't trust any of the documentation in MSDN.... Often, I come across something wonderful in STL (like the string tokenising noted above) and feel like singing and dancing... :) everyone here is a bit sus on the STL and I have to keep quiet :( The solution... an STL forum!!! I know we have a VC++ forum, but it's kind of in a different vein to what I mean... Chris? cheers NB
>>> [snip]...does anyone know of a good *online* STL reference? <<< I've found the following ones to be very good; Dinkum C++ Library (http://www.dinkumware.com/htm\_cpl/index.html) SGI's STL (http://www.sgi.com/tech/stl/) Ben Burnett --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)
-
STL containers are great. The only problem I have with STL is mixing it with MFC GUI code. Many of the functions require a CString as inputs/outputs (e.g. GetWindowText() is a common function that comes up), and I have to pass in a temp CString to GetWindowText() and then convert that into a std::string. Sometimes that scratches me the wrong way, and annoys me like fingernails scratching on a blackboard.
> The only problem I have with STL is mixing it with MFC GUI code. > Many of the functions require a CString as inputs/outputs (e.g. > GetWindowText() is a common function that comes up), and I have > to pass in a temp CString to GetWindowText() and then convert > that into a std::string GetWindowText(...) also allows you to take a TCHAR buffer, so you do not have to do an extra wasteful dynamic memory allocation (and free) for the CString. Yes, std::basic_string does not directly expose the internal buffer, but IIRC, that is one of the "features" of proper encapsulation. The STL containers can also manage your own string type, or even MFC's CString, if you so desire (always store pointers to objects). Peace! -=- James.
-
i love the STL. :rolleyes: as soon as i got the hang of it, i abandoned MFC's collections totally. i use the std algorithms a lot: sort, reverse, unique, etc. i use string and wstring in many apps (especially where MFC isn't an option). i've used functors in a couple of places to do some strange stuff that would've been a hideous mess otherwise. and, i've lately found myself using small things like std::swap or std::min. i used to think STL was worthless - MFC can do a lot of the basic stuff (CStringArray, for example). but, once i really got into STL, i realized how powerful it really is. yummy. i imagine i'd get the same feeling if i ever got into the functional programming languages; but i don't have the time to learn a new language these days. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
> [...]i've used functors in a couple of places to do some strange stuff > that would've been a hideous mess otherwise. Man, once I first learned about (and figured out) functors, I thought that they were the coolest idea! :) "algorithm" contains lots of cool stuff, I, too, use STL, even the allocators stuff (for preventing heap contention with multithreaded apps), quite often. Peace! -=- James.
-
Great! Mike, you just hit on my biggest woe with using STL (which I love). Thanks. On the topic, does anyone know of a good *online* STL reference? I've seen a few wonderful paper versions, but it would be handy to keep something searchable on my machine- and I don't trust any of the documentation in MSDN.... Often, I come across something wonderful in STL (like the string tokenising noted above) and feel like singing and dancing... :) everyone here is a bit sus on the STL and I have to keep quiet :( The solution... an STL forum!!! I know we have a VC++ forum, but it's kind of in a different vein to what I mean... Chris? cheers NB
We don't need an STL forum, just the courage to speak freely about STL in the face of public persecution. ;) 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.
-
I wonder how many people are like me and just end up using vector, set, map, and a few other assorted classes. I hardly if ever use the algorithms directly. Tim Smith Descartes Systems Sciences, Inc.
Yes, I am like that. But I hope to improve as I learn the STL more and more. The way I see it, it is better if STL is hard to learn. I will learn it for sure, but others won't, which will make me better than the rest ;) :cool: (2b || !2b)
-
We don't need an STL forum, just the courage to speak freely about STL in the face of public persecution. ;) 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.
-
We don't need an STL forum, just the courage to speak freely about STL in the face of public persecution. ;) 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.
-
I wonder how many people are like me and just end up using vector, set, map, and a few other assorted classes. I hardly if ever use the algorithms directly. Tim Smith Descartes Systems Sciences, Inc.
I use a number of the algorithms directly. The problem is that the way Microsoft/Dinkumware implemented STL for VC++, you can't use predicate versions of many of the algorithms (e.g., sorting can only be done using
operator >()for a comparison operator), which makes them less than useful. Fortunately, the C++ compiler itself (if you're using SP3 or above) is capable of generating predicates, so you can rewrite the STL to comply more closely with what's documented in Saini and Musser. The real beauty will come when Microsoft finally implements partial-template-specialization, at which point the algorithms will really come into their own. 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 -
I've been looking at some discussions recently on the forums regarding the C++ STL. Seems like most everyone prefers using classes because the data and methods are bound together. When the data/container is separate from most of the algorithms (as is the case with libraries like STL), then most users don't have a good idea of the capabilities of the library or forget about the algorithms. What do you think of the STL concept?
When the data/container is separate from most of the algorithms (as is the case with libraries like STL), then most users don't have a good idea of the capabilities of the library or forget about the algorithms. There are two principal arguments I consider in comparing separate algorithms to algorithms as class methods:
-
Separate algorithms avoid multiple inheritance problems. Oswald extends
std::listto add a new algorithm,oswalds_list::quicker_sort(object, predicate)and Rhiannon extends std::list to add her algorithm,rhiannons_list::select_most_compact_subset(object, element_ct). If you want to use both algorithms on a list, you must either multiply inherit (yuck!) or rewrite a new class that implements both algorithms.However, if these algorithms are just global functions or classes inherited from an abstract algorithm class, then they can coexist with no special work.
-
Separate algorithms can accept generic containers as arguments. If you want to write an algorithm that works on different containers, you can often write a generic version that will accept any container as an argument (if you have PTS, you can also write specializations optimized for specific container types or predicates). If algorithms are members of classes, then you have to do lots of cutting and pasting to add an algorithm to
std::list,std::vector,std::map, etc.
For these reasons, I like the approach taken by STL better than trying to replace generic algorithms with specialized class methods. 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
-
-
When the data/container is separate from most of the algorithms (as is the case with libraries like STL), then most users don't have a good idea of the capabilities of the library or forget about the algorithms. There are two principal arguments I consider in comparing separate algorithms to algorithms as class methods:
-
Separate algorithms avoid multiple inheritance problems. Oswald extends
std::listto add a new algorithm,oswalds_list::quicker_sort(object, predicate)and Rhiannon extends std::list to add her algorithm,rhiannons_list::select_most_compact_subset(object, element_ct). If you want to use both algorithms on a list, you must either multiply inherit (yuck!) or rewrite a new class that implements both algorithms.However, if these algorithms are just global functions or classes inherited from an abstract algorithm class, then they can coexist with no special work.
-
Separate algorithms can accept generic containers as arguments. If you want to write an algorithm that works on different containers, you can often write a generic version that will accept any container as an argument (if you have PTS, you can also write specializations optimized for specific container types or predicates). If algorithms are members of classes, then you have to do lots of cutting and pasting to add an algorithm to
std::list,std::vector,std::map, etc.
For these reasons, I like the approach taken by STL better than trying to replace generic algorithms with specialized class methods. 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
I know using the STL has made me look twice at my own algorithms that I have attempted to do as class methods. I agree -- there are many instances where a generic function/algorithm works better and is more reusable than a class method. But it can be hard to break away from the strict OO approach unless you've been exposed to something different like the STL.
-
-
I've been looking at some discussions recently on the forums regarding the C++ STL. Seems like most everyone prefers using classes because the data and methods are bound together. When the data/container is separate from most of the algorithms (as is the case with libraries like STL), then most users don't have a good idea of the capabilities of the library or forget about the algorithms. What do you think of the STL concept?
Since we're talking about STL, is there anyone here that would like to look over a class I wrote? It's an STL version of my CQStringParser class (http://www.codetools.com/useritems/cstringparser.asp) for people that need to parse strings but don't want to use MFC to do it. It's my first attempt at working with STL, and I'd appreciate some opinions/pointers. It appears to work okay. I plan on updating the article to including this new class in the next couple of days.
-
I use a number of the algorithms directly. The problem is that the way Microsoft/Dinkumware implemented STL for VC++, you can't use predicate versions of many of the algorithms (e.g., sorting can only be done using
operator >()for a comparison operator), which makes them less than useful. Fortunately, the C++ compiler itself (if you're using SP3 or above) is capable of generating predicates, so you can rewrite the STL to comply more closely with what's documented in Saini and Musser. The real beauty will come when Microsoft finally implements partial-template-specialization, at which point the algorithms will really come into their own. 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 BowlCan you explain breifly what partial-template-specialization is? (2b || !2b)
-
Can you explain breifly what partial-template-specialization is? (2b || !2b)
Quite simply, when you have a template object (class, function, struct):
template <class T_, int N_> class factorial
{
public:
T_ value() const { return static_cast<T_>(N_) * factorial<T_,N-1>.value(); }
};you can define specialized implementations:
class factorial<int, 0>
{
public:
int value() const { return 1;}
};but then you need to explicitly specialize
factorial<T_,0>for every typeT_that you will be using with factorial. With partial template specialization, you can writetemplate <class T_> class factorial<T_, 0>
{
public:
T_ value() const {return 1;}
};. For factorial, this is not terribly interesting, but Todd Veldhuizen has written the Blitz++ library, which uses template metaprogramming techniques to get the compiler to perform very sophisticated optimizations at compile time. According to several papers Veldhuizen has published, this technique offers for the first time to make C++ competitive with Fortran for high-performance numerical computation while maintaining a high degree of abstraction (i.e., you make generic library calls rather than explicitly hand coding optimized loops). The basic idea is that you can implement a Turing machine at compile time using template gymnastics and can thus have the compiler precompute a large part of your problem (and perform extensive optimizations) at compile time. If you will compile once and run many times, you win big with this approach. There is nothing inherent in this approach that would make it incompatible with MSIL/.NET, for most of the optimizations depend on the problem domain, not on the target hardware architecture and configuration, but if you consider combining the problem-domain optimizations with hardware-specific ones (following the example of FFTW and ATLAS), then you could have standard libraries where you specify the target architecture at compile time and the compiler may take a day or two to build your program, but will produce code that runs significantly faster, all without requiring any fancy hand-coded optimizations. Unfortunately, since Blitz++ makes extensive use of advanced template functionality in the ANSI/ISO C++ standard, it will not work with Visual C++ 6.0 or with the pending 7.0 release. As Microsoft spokespeople have stated here on CP, Microsoft found that most of their VC++ customers were more interested in .NET features than in implementing the C++ standard, so they decided not to implement partia
-
Quite simply, when you have a template object (class, function, struct):
template <class T_, int N_> class factorial
{
public:
T_ value() const { return static_cast<T_>(N_) * factorial<T_,N-1>.value(); }
};you can define specialized implementations:
class factorial<int, 0>
{
public:
int value() const { return 1;}
};but then you need to explicitly specialize
factorial<T_,0>for every typeT_that you will be using with factorial. With partial template specialization, you can writetemplate <class T_> class factorial<T_, 0>
{
public:
T_ value() const {return 1;}
};. For factorial, this is not terribly interesting, but Todd Veldhuizen has written the Blitz++ library, which uses template metaprogramming techniques to get the compiler to perform very sophisticated optimizations at compile time. According to several papers Veldhuizen has published, this technique offers for the first time to make C++ competitive with Fortran for high-performance numerical computation while maintaining a high degree of abstraction (i.e., you make generic library calls rather than explicitly hand coding optimized loops). The basic idea is that you can implement a Turing machine at compile time using template gymnastics and can thus have the compiler precompute a large part of your problem (and perform extensive optimizations) at compile time. If you will compile once and run many times, you win big with this approach. There is nothing inherent in this approach that would make it incompatible with MSIL/.NET, for most of the optimizations depend on the problem domain, not on the target hardware architecture and configuration, but if you consider combining the problem-domain optimizations with hardware-specific ones (following the example of FFTW and ATLAS), then you could have standard libraries where you specify the target architecture at compile time and the compiler may take a day or two to build your program, but will produce code that runs significantly faster, all without requiring any fancy hand-coded optimizations. Unfortunately, since Blitz++ makes extensive use of advanced template functionality in the ANSI/ISO C++ standard, it will not work with Visual C++ 6.0 or with the pending 7.0 release. As Microsoft spokespeople have stated here on CP, Microsoft found that most of their VC++ customers were more interested in .NET features than in implementing the C++ standard, so they decided not to implement partia
"As Microsoft spokespeople have stated here on CP, Microsoft found that most of their VC++ customers were more interested in .NET features than in implementing the C++ standard..." Was ANYBODY on this board asked which they preferred (ANSI compliance or .NET features)? I don't rememebr seeing the question posted, and would personally definitely have voted in favor of compliance. Microsoft is shoveling donkey dung in our direction again.
-
"As Microsoft spokespeople have stated here on CP, Microsoft found that most of their VC++ customers were more interested in .NET features than in implementing the C++ standard..." Was ANYBODY on this board asked which they preferred (ANSI compliance or .NET features)? I don't rememebr seeing the question posted, and would personally definitely have voted in favor of compliance. Microsoft is shoveling donkey dung in our direction again.
No, actually it was never phrased that way. Most of MS's customers are more concerned with backwards compatibility than ANSI compliance, and unfortunately, full ANSI compliance would mean breaking existing code (code in libraries and .obj's). I think MS's thinking on the matter is that they'd rather deliver a compatible compiler first and then make a clean break.
-
I couldn't agree more - where I work I am known as the STL zealot, because I absolutely refuse to use the MFC containers now that I know some STL. It's just so flexible and powerful, I feel like I am barely scratching the surface. I have recently read that the MFC containers were only put in as a stopgap as the STL was not part of the standard at the time. I dunno if this is true or not, but I do know that compared to the STL they seem to me like tinkertoys. 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.
Of course it's true. MFC was created in 1989-90 timeframe, before the C++ standard was even begun.
-
Of course it's true. MFC was created in 1989-90 timeframe, before the C++ standard was even begun.
I am well aware of the age of both MFC and the standard, but that does not mean that Microsoft uncharacteristally created something as a stopgap, rather than as a replacement. In other words, I was saying I don't know if it's true that Microsoft intended us to use CArray only until vector was formalised as part of the standard, which is what was implied by the term 'stopgap'. 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.
-
Quite simply, when you have a template object (class, function, struct):
template <class T_, int N_> class factorial
{
public:
T_ value() const { return static_cast<T_>(N_) * factorial<T_,N-1>.value(); }
};you can define specialized implementations:
class factorial<int, 0>
{
public:
int value() const { return 1;}
};but then you need to explicitly specialize
factorial<T_,0>for every typeT_that you will be using with factorial. With partial template specialization, you can writetemplate <class T_> class factorial<T_, 0>
{
public:
T_ value() const {return 1;}
};. For factorial, this is not terribly interesting, but Todd Veldhuizen has written the Blitz++ library, which uses template metaprogramming techniques to get the compiler to perform very sophisticated optimizations at compile time. According to several papers Veldhuizen has published, this technique offers for the first time to make C++ competitive with Fortran for high-performance numerical computation while maintaining a high degree of abstraction (i.e., you make generic library calls rather than explicitly hand coding optimized loops). The basic idea is that you can implement a Turing machine at compile time using template gymnastics and can thus have the compiler precompute a large part of your problem (and perform extensive optimizations) at compile time. If you will compile once and run many times, you win big with this approach. There is nothing inherent in this approach that would make it incompatible with MSIL/.NET, for most of the optimizations depend on the problem domain, not on the target hardware architecture and configuration, but if you consider combining the problem-domain optimizations with hardware-specific ones (following the example of FFTW and ATLAS), then you could have standard libraries where you specify the target architecture at compile time and the compiler may take a day or two to build your program, but will produce code that runs significantly faster, all without requiring any fancy hand-coded optimizations. Unfortunately, since Blitz++ makes extensive use of advanced template functionality in the ANSI/ISO C++ standard, it will not work with Visual C++ 6.0 or with the pending 7.0 release. As Microsoft spokespeople have stated here on CP, Microsoft found that most of their VC++ customers were more interested in .NET features than in implementing the C++ standard, so they decided not to implement partia
.. excuse me a second I have to leave the room, my head appears to be on fire! Any chance you could repost this in a couple of years (read ten) when I start to understand templates. Kind regards. Al. What is it about Fortran that makes it idea for numerical work? C++/C# Student. Wither Thee VB.Net.