To STL or not to STL, that is the question...

Quote:

---

Originally posted by cvogt61457
Suggestions were given to use a wrapper to enclose basic_string.
However, you have rejected this method.

---

I have not rejected this method. I would, however, like to ensure that the way I did it is completely and totally wrong before I re-write thousands of lines of code.

Two people, both of which seem to know a great deal more than I, are currently presenting arguments one of which says the way I did it is ok, the other says I'm not. Regardless of who is correct, I have not rejected anything out of hand.



And my vector<string> class is not using a basic_string. It's using my own base serial_string class which is a wrapper around a simple char array but has a lot of the basic_string functions. As well as serializing functions.

Quote:

---

Originally posted by cvogt61457
The functionality that you are wanting to add must go
somewhere. If you could derive from basic_string, you would
have the functionality there.

---

It does. All my string_vector class does is loop through each element it holds and and calls the save (or load) method of each individual serial_string object.

Yeah - I know - this is easily done from an external method.

Quote:

---

Originally posted by cvogt61457
Or you could write the wrapper class and the functionality would
be there.

---

Again, I want to ensure that I really screwed up before I engage in such a re-coding project.

Quote:

---

Originally posted by cvogt61457
By your definition, these classes are not OO.

---

Not by my definition. I learned that OO consisted of "Encapsulation", "Inheritance" and "Polymorphism". These three fundamentals were driven into my brain by every book, document and person that I consulted about OO programming.

And now the standard says, "To **** with it!" Design or no -it makes no sense to me to have the standard contradict the paradigm - indeed, to deliberately undermine the paradigm.

But this is useless whining. I'm not here to argue about what it should be.

Quote:

---

Originally posted by cvogt61457
You are determined to use the STL functionality in a way that it
were not meant to be used. In fact, in a way that it has been
designed to not be used.

---

Unclench, Sparky.

I'm not determined to do anything but ensure the survival of my application.

If that means rewriting 2000 lines of code, then so be it - but certainly you can see my interest in trying to avoid rewriting 2000 lines of code.


People are waiting for me to finish here.

This will cause a delay I don't want.

Quote:

---

Originally posted by gyohng
Please, read the standard more carefully.

The class1...class5 code is written per standard, I have checked this.

For now, I stop arguing, as you insist on your point not reading my posts carefully.

The problem is that you misunderstand the "static type" definition in the clause you have quoted.

Not to offend you, I really beg you to re-read my posts carefully. I did few editions, so that the text will be easier to understand.

---

Gyohng,

I've read and understand your code - and your point, but I am still not confident that you are correct (but you may be). The crux of the problem is interpreting the standard.

Your claim is that since the compiler will do the destruction of Class5 as a pointer-to a Class3 and the compiler knows the Class3's destructor is virtual - that it in fact will perform a virtual method call invoking Class5's destructor instead of Class3's.

You claim that in your interpretation of the standard this will always be safe - since the object is always destroyed via a base with as virtual destructor.

Paul's claim is that by the mere fact that a non-virtual destructor exists in an ancestor of Class5 (Class1) that the standard deems the behavior as undefined regardless of the fact that Class5 is destroyed via an intermediary base with a virtual destructor.

The correct answer will lie in the standard where it describes the call ordering and rules of destuctor invocation. I leave the dissecting of the standard to you two.

Quote:

---

Originally posted by mclark
I understand your frustration but Objects are not panacea and neither is OO.

---

No you don't, or you would not have written this:

Quote:

---

Originally posted by mclark
But for C++, struggling to use only this approach and not understanding why it is not possible reflects a niave grasp of how OO concepts relate to language constructs.

---

As I've said before - I'm not struggling to use this approach. I flat out used it. If it's wrong, it's wrong - I'll rewrite the code. But my frustration lies within the fact that I have to rewrite a butt-load of code - not because STL doesn't conform to what I believe OOP should be.

And I, by God, wanna be sure that the code is irrevocably, inexorably broken before I break down and rewrite a good portion of my application.

Quote:

---

Originally posted by mclark
You may not like it but it is the excepted best-practice for OO within the language of C++.

---

I didn't come here to argue about what I like - although it may be starting to sound that way. I came here to find out what it is - and ensure that I don't do it again.


All the complaining I'm doing is just gravy :)

mclark,

I have just checked the code under GNU C++ 2.95, 3.0, VC6, VC7, Intel C++ v7 compiler, Borland C++Builder6 - every compiler seems to handle the case properly (as per my interpretation).

Moreover, I have altered std::vector sources to include printf in the destructor and tested on Paul's example - seems to work fine either.

As for paul's reference for copying std::string with memcpy - it is completely invalid and was pure luck to work, because std::string does not contain string data inside. It contains pointer to string data. And I guess the code succeeded once only due the fact that some std::string implementations are reference-counting.

Thanks,
George.

Quote:

---

Originally posted by mclark
Gyohng,

I've read and understand your code - and your point, but I am still not confident that you are correct (but you may be). The crux of the problem is interpreting the standard.

Your claim is that since the compiler will do the destruction of Class5 as a pointer-to a Class3 and the compiler knows the Class3's destructor is virtual - that it in fact will perform a virtual method call invoking Class5's destructor instead of Class3's.

You claim that in your interpretation of the standard this will always be safe - since the object is always destroyed via a base with as virtual destructor.

Paul's claim is that by the mere fact that a non-virtual destructor exists in an ancestor of Class5 (Class1) that the standard deems the behavior as undefined regardless of the fact that Class5 is destroyed via an intermediary base with a virtual destructor.

The correct answer will lie in the standard where it describes the call ordering and rules of destuctor invocation. I leave the dissecting of the standard to you two.

---

Quote:

---

Originally posted by gyohng
I have just checked the code under GNU C++ 2.95, 3.0, VC6, VC7, Intel C++ v7 compiler, Borland C++Builder6 - every compiler seems to handle the case properly (as per my interpretation).

Moreover, I have altered std::vector sources to include printf in the destructor and tested on Paul's example - seems to work fine either.

---

That does not mean that it agrees with the C++ standard. On every one of the platforms you mentioned above, sizeof(short) equals 2. But that is not spelled out in the standard. In fact the standard says sizeof(short) must be greater than or equal to sizeof(char). That means sizeof(short) can be 1 according to the standard. I'm not saying that your code disagrees with the standard. I'm just saying that your argument for standard compliance is invalid. Like mclark said, I'll let you and Paul hash out what is really in the standard (since I don't have a copy).

- Kevin

Well, I don't know what standard says about such situation when you have the first part of hierarchy with non-virtual dtor and the other part with virtual dtor, and trying to delete via some class pointer which has virtual dtor. The point is that it is dangerious to derive a class from some class which has non-virtual dtor.
Imagine a situation where others can use that class:

Code:

---

typedef vector<POINT> Shape;
vector<Shape*> all_shapes;

struct Shape1 : Shape
{
 virtual ~Shape1() {}
};
struct Shape2 : Shape
{
 virtual ~Shape2() {}
};

void erase_all_shapes()
{
 //assume several instances are created  by new and are inserted into all_shapes.

 for(Shape::iterator it = all_shapes.begin()....)
  delete *it; //fault at least in MSVC.
}

---

Of course it's a very common case though.

Well now that I think about it:

I know that it is safe to directly delete an object that is derived from a class that does not have a virtual destructor. Therefore, make me amend what I've been saying:

Since my example derived from string_vector, and if string_vector has a virtual destructor, and you delete directly a "string_vector" object or pointer, you are fine. This is not disputed, but I wasn't thinking this at the time. Sorry for the wrong information.

Now, the rub is how far up the coder will declare their pointer in the hierarchy: if the coder were to go up one more above the hierarchy and declared a pointer to vector<string> and used it polymorphically, then they would be in trouble.

Code:

---

int main()
{
  std::vector<std::string> *pMyVect;
  if ( do_some_customizations )
      pMyVect = new MyCustomizedStringVector;
  else
    pMyVect = new AnotherCustomizedStringVector;
//...
  delete pMyVect;  // trouble
}

---

So you still need to post a warning as to how far up the hierarchy someone can use your class polymorphically -- right now, they can stop at string_vector, but go no further up the branch when a pointer is declared.

AvDav's most recent post shows the dangers of deriving from a class that does not have a virtual destructor, and how easily it can be erroneously used in a program without any great programming effort.

Regards,

Paul McKenzie

As I've mentioned earlier in this thread, a simple and robust way for extending the functionality of a standard library container is to write your own algorithms. I mean, that's what is being desired if I'm correct. You don't want to access any internals into the container, like whatever implementation-defined types contained or private methods, right? So there's absolutely no need to derive in these cases. I know its fun to derive, but that's not an end in and of itself. And not everything in c++ has to be put inside a class...

lol, you guys are all adorable...

For Paul:
For those of you who like to keep quoting standards I should point this out:
There is no such thing as an ANSI compliant compiler
Before you even start to whine at me, and you know who you are, write a compiler, then talk to me about it, otherwise keep it shut.
The statement "conforms to the standard" means "is compatible with the ideas of the standard" or "Is similar to the standard". Don't believe me, buy a dictionary.

1. STL was an extension of a compiler written by a small group of people who thought it would be a cool idea, and it was WAY off the standard at the time.

2. MFC came out long before STL, however, STL is almost as old from conception. Not like that has any bearing on anything, but I thought I'd throw it in there.

3. Most degreed people wrote a compiler in college. The point of ANSI is to say, "please try to include these things in your compiler". I does not say, "You MUST have a compiler just like this". So just because the "standard" says to do something, doesn't mean its right or actual or even implemented. And even if you write code right down to the very specifics of the ANSI standard, it still wont work on every compiler that claims to be ANSI compliant...again, write a compiler, then talk to me about how you think I'm wrong. I've written 2 compilers(ASM and C\C++) and 1 de-compiler (C++) and extended countless others, so yes, I do indeed know what I'm talking about before anybody decides to tell me I'm "BS"ing again.

4. Just because your STL class in junior college was called "Advanced C++" does not mean that STL is advanced C++. Just in junior college, they want you to feel special. I've taught this class and believe me, there's nothing advanced about it.

5. It's been decided by people way smarter then you, that base classes work as so:
BASE* ptr = &derived;
delete ptr;
If a destructor in base class is virtual when destroyed, any derived class' destructors are called first then the base, otherwise ONLY the base destructor is called and not the derived. This has to do with virtual tables that are created at compile time. No virtual entry, no call to the derived class. easy.
This is the way it works, because it was decided by the people writing the compiler that this is the best way to implement it. Don't like it, give them a call. Don't like what ANSi says about it, call them.

These, gentlemen, are facts in programming. There are millions of ways to code things, "standards" are just ways to help control the mayhem. But as you can see from this thread, its not doing a very good job...

Oh, I forgot, STL is a SDK, Paul. Just because a compiler can compile template code, does not mean the libraries that use it are not SDKs. If you have trouble with that, please look up what the definition of a SDK is, and get back to me and I'll explain it to you.

My final note:
If you like STL then use STL. When you are ready to step out here with the big boys and write real programs, you will find that STL does not have what it takes and you will have to write you own code. Since as pointed out, STL classes are not reliably derived, you will have no other choice to either write your own or to write a bunch of functions to do the job for you which would defeat the purpose of OO programming. Template code is indeed a great idea, I supported it a decade a go and I still support it now, I've written lots of classes and functions with it. STL on the other hand, is badly written, buggy as ****, is almost impossible to extend or pass around with any reliability.
But whatever floats your boat. You will learn with experience.

Oktronic, do you really have such a bad self-image that you have to demean others to make yourself feel better? All this "big-boys" talk make you sound like an insecure 13 year-old trying to hang with punks on the corner.

But ok, can you point to one bug you've found? Just one would be helpful for context of your comments (to illustrate you are a big boy and not someone who just doen't know how to use things)...

galathaea,
Please when making an accusation, quote what you feel was wrong so I can understand.
I wasn't my intent to demean, but to educate, while I am indeed annoyed by the arrogance I have seen in this thread, it's not my intent to hurt your feelings.
So please tell me what you felt hurt by and I will correct it.

Its tough being obsolete

Quote:

---

First I didn't know people were still using STL in production code.

...

Which makes STL great for the one time slap a 'int' container together program. Otherwise known as a homework assignment....

...

Most of us senior programmers are, Paul. This might comes as a shock, but C came before C++. There were a whole bunch of languages before C++ surprisingly....

...

c) you mean thousands of buggy college programs?

...

Quote:

---

The STL classes are written by some of the best C++ programmers in the world

---

I'd love to tell you all about this, but instead I'm just going to laugh real hard...

Quote:

---

They are not fly-by-night programmers who made up these classes

---

Guess you never opened one of the header files....

...

Just because your STL class in junior college was called "Advanced C++" does not mean that STL is advanced C++. Just in junior college, they want you to feel special. I've taught this class and believe me, there's nothing advanced about it.

...

If you like STL then use STL. When you are ready to step out here with the big boys and write real programs, you will find that STL does not have what it takes and you will have to write you own code.

---

You seem to want to alpha-male your position to the forefront instead of actually giving arguments about the topic. This thread could be very beneficial to many reading it, but I see instead in places this desire to bad mouth absent argument, like subverted superiority issues coming to the surface or something. If you actually know of a true bug somewhere, or can show a concrete example of bad design, that would be great. It gives an objective focus without diversionary name-calling and "nanny nanny" type schoolground tactics. I notice that you didn't respond with an example to my query. Should I take that as conceding something, or is there substance behind these claims, because it is very very important to all professional coders to have accurate information on the stability of the code they use.

Quote:

---

Originally posted by oktronic
There is no such thing as an ANSI compliant compiler
Before you even start to whine at me, and you know who you are, write a compiler, then talk to me about it, otherwise keep it shut.

---

It is not possible to detect all constructs whose behavior at run-time is undefined by the standard. Both C and C++ and undecidable languages. It is possible accept all WFF required by the language and reject all invalid required by the language and implement the semantics as described by the language. This is what makes a compiler compliant- the language it accepts not necessary what it does with it. Of the fully specified languages I've seen all were based on an interpretive model for a matematical machine.

Quote:

---

4. Just because your STL class in junior college was called "Advanced C++" does not mean that STL is advanced C++. Just in junior college, they want you to feel special. I've taught this class and believe me, there's nothing advanced about it.

---

I freely admit that I've never been a junior college professor.

Quote:

---

5. It's been decided by people way smarter then you, that base classes work as so:
BASE* ptr = &derived;
delete ptr;
If a destructor in base class is virtual when destroyed, any derived class' destructors are called first then the base, otherwise ONLY the base destructor is called and not the derived. This has to do with virtual tables that are created at compile time. No virtual entry, no call to the derived class. easy.
This is the way it works, because it was decided by the people writing the compiler that this is the best way to implement it. Don't like it, give them a call. Don't like what ANSi says about it, call them.

---

The standard says nothing at all about virtual tables. Virtual tables are simply one approach for implementing the functionallity required by the standard. While its the most common, not all compilers generate or use _vtbls.

Quote:

---

These, gentlemen, are facts in programming. There are millions of ways to code things, "standards" are just ways to help control the mayhem. But as you can see from this thread, its not doing a very good job...

---

The C++ Standard is not about how you code things - its about what do the things you code mean.

Quote:

---

Oh, I forgot, STL is a SDK, Paul. Just because a compiler can compile template code, does not mean the libraries that use it are not SDKs. If you have trouble with that, please look up what the definition of a SDK is, and get back to me and I'll explain it to you.

---

By this definition - everything not derived by the developer from the first-principle language constructs including the entire standard library is an SDK (ie. malloc). Intresting, an SDK that your required to be provided.

Quote:

---

My final note:
If you like STL then use STL. When you are ready to step out here with the big boys and write real programs, you will find that STL does not have what it takes and you will have to write you own code.

---

(quietly avoiding the pissing contest)

Quote:

---

Since as pointed out, STL classes are not reliably derived, you will have no other choice to either write your own or to write a bunch of functions to do the job for you which would defeat the purpose of OO programming.

---

I don't know if Stroustrup would agree that the purpose of C++ is simply OO programming. Nor agree that simple functions and data variables violate the principles of OO after all these are members of the namespace object which is itself an object (just not a class).

Quote:

---

Template code is indeed a great idea, I supported it a decade a go and I still support it now, I've written lots of classes and functions with it. STL on the other hand, is badly written, buggy as ****, is almost impossible to extend or pass around with any reliability.

---

It would seem that these limitations are with the implementations you've used and are not iherent to STL as a definition.

Yes, leaving so much of the behavior of STL objects as implementation-specific has made interacting with STL difficult - leaving many to seak portability through rolling-their-own.

And there you have it. Once again engineering digresses into religion.

Quote:

---

Originally posted by galathaea
But ok, can you point to one bug you've found? Just one would be helpful for context of your comments (to illustrate you are a big boy and not someone who just doen't know how to use things)...

---

I can provide an anecdotal STL bug just to lighten the mood.

In the early HP versions of STL you could not create containers of built-in types because built-ins didn't have destructors (which were directly called by STL at the time).

Sorry that this bug hasn't been relevant in ~10 years.

Quote:

---

Originally posted by Toxick
And now, I'm trying to figure out what's the point of using an OO library or language if you can't (or shouldn't) use OO techniques. (like inheritance).

Which, I suppose, puts me in the position of the original poster, and I don't think we need to hash that out again.

---

IMHO, this quote reflects quite well the basic misunderstanding floating all about this thread, probably the same which led to its initial creation by darwen. In one of the earlier post to this thread, Zeeshan already made some valid statement to this subject, I'll try to put them in simpler words:

Yes, C++ started up as an "object-oriented" superset of the "procedural" C language, introducing elements like classes, inheritance, polymorphism via virtual member functions, etc... Hence, C++ is very commonly perceived as an "OO language". So when templates were added to the language, many didn't notice at first that this wasn't yet another addition to make the language even "more OO", but the introduction of a new concept: that of generic programming. But generic programming is not part of the OO paradigm, nor does the reverse apply. To some extent, those two concepts are even orthogonal to each other, and C++ allows you to use of both of them.

I remember that when I first heard about the idea to bring templates into C++, I saw them as an ugly and superfluous addition to the language, some kind of sophisticated macro preprocessor which just spoiled the nice OO concepts. It took some time to understand that a container library like the STC part of STL is not an OO library, but a completely different animal: Instead of implementing containers as classes which polymorphically keep pointers to instances of a base class from which you derive your own concrete classes (like the original MFC containers do), they use template metaprogramming to achieve a similar goal, which is by no means OOP, but generic programming.

Each time the "STL vs. MFC" or the "STL vs. not STL" discussion arises, I see statements from people how seem to be stuck with the idea that the STL is an OO class library implemented with templates. However, the STL is not OO. Likewise, C++ is not an OO language. C++ is a real allrounder, having all of a low-level language which can be used for systems programming tasks at nearly machine level, yet being procedural and block-structured (the idea C started with), and it features strong OO elements as well as generic programming.

So while I understand the point of view of darwen and Toxick, I also suspect that they just failed to notice until now that templates (in general) and the STL (more specifically) have nothing to do with the OO concepts of C++ - they just move along another dimension of the C++ space.

Quote:

---

Originally posted by gstercken
But generic programming is not part of the OO paradigm, nor does the reverse apply. To some extent, those two concepts are even orthogonal to each other, and C++ allows you to use of both of them.

---

I beg to differ. Templates are very much part of the OO methodology. Both templates and inheritance enable polymorphism (the hallmark of OO). They simply enable two different types (i)subtype polymorhism; (ii)parameter polymorphism. It is important to see both as forms of polymorhism to understand OO within C++. One of the challenges of OO design in C++ is to determine when and where to use each so that overall costs are minimized (static/dynamic memory footprint, run-performance, compilation performance, sloc).

Quote:

---

Originally posted by mclark
They simply enable two different types (i)subtype polymorhism; (ii)parameter polymorphism. It is important to see both as forms of polymorhism to understand OO within C++.

---

Yes, both are ways to implement polymorphism. But as to my point of view, subtype polymorphism is the OO way of doing it, and parameter polymorphism is the GP way. The fact that polymorphism is an important element of OO doesn't allow for the reverse implication that any approach supporting polymorphism is automatically OO.

Quote:

---

Originally posted by oktronic
lol, you guys are all adorable...

<snipping a lot of junk>

Oh, I forgot, STL is a SDK, Paul. Just because a compiler can compile template code, does not mean the libraries that use it are not SDKs. If you have trouble with that, please look up what the definition of a SDK is, and get back to me and I'll explain it to you.

---

SDK short for Software Development Kit. Is this the answer you're looking for? You never answered the question -- is the C-library an SDK? If not, why not? Are fopen(), fclose(), malloc(), free(), etc. SDK functions?

Quote:

---

My final note:
If you like STL then use STL. When you are ready to step out here with the big boys and write real programs, you will find that STL does not have what it takes and you will have to write you own code.

---

And you have knowledge that I and others don't write "real programs"?

Quote:

---

STL on the other hand, is badly written, buggy as ****

---

As galathea pointed out to you, tell us where the bugs are instead of demeaning others by saying "we don't write real programs" and "when you step out with the big boys". If you make a claim, make your claims like an adult instead of sounding like someone from the World Wrestling Federation.

There is no need to come on board here (I see you're new) and act condescending to the others that have spent much more time here helping others. You will only wear out your welcome that much sooner.

Regards,

Paul McKenzie

Quote:

---

Originally posted by gstercken
Yes, both are ways to implement polymorphism. But as to my point of view, subtype polymorphism is the OO way of doing it, and parameter polymorphism is the GP way. The fact that polymorphism is an important element of OO doesn't allow for the reverse implication that any approach supporting polymorphism is automatically OO.

---

OO (at least as preached by OMG and UML) contains both harmoniously. Parameter Polymorhism and Subtype polymorphism are both equal sibling refinments of the relationship between classes. OO embraces both. In C++ different language mechanics, styles and support communities have made these two less related than they should be. But from a design perspective they are unified.

for galathaea:
The only thing that warrants an apology was the "big-boy" comment. While that expresses my opinion of this as childish, it doesn't belong in adult conversation. The rest were responses to what Paul had said. And I feel he has been far more demeaning to every response against STL in this thread, long before I responded. That's why I use the quotes surprisingly.

for mclark:
Brief response, I agree with 90% of what your saying.

Quote:

---

The standard says nothing at all about virtual tables

---

Yes and no. Check the limitations in the standard.

Quote:

---

The C++ Standard is not about how you code things

---

Again, Yes and no. ANSI is simply a request to make life easier for other programmers. While it doesn't tell you how to code, it does ask you to code your compiler to be nice to others.

Quote:

---

I don't know if Stroustrup would agree that the purpose of C++ is simply OO programming

---

I'm sure he would say, the C++ is an OO approach to C. I suppose I can only guess at that, but the main construct of a C++ compiler is to turn C in to an encapsulated system. But honestly, it's about turnning programming back into a profession.

Quote:

---

I freely admit that I've never been a junior college professor

---

Nothing wrong with that. Its a great place to do part time teaching while you work on other projects. Most students are adults looking for a trade which made it better then teaching kids.
But I've done C and C++ and AC++ for fun while taking a project break.

Quote:

---

It would seem that these limitations are with the implementations you've used and are not inherent to STL as a definition

---

This I disagree with. I have actually expanded template parsing to weed out some of the limitations. STL on the other hand, is nothing but limitation. I think the fact that an object requires external functions to operate on itself is a horrible concept and very poor design.

Quote:

---

And there you have it. Once again engineering digresses into religion.

---

sad, but I think its getting that way.

As for STL. Use it if you want. Again, you will find with experience that its use will open a door for very poor design. We see poor design every day in a multitude of programs hitting shelves. Programs that only run on developer machines and no where else, to name one. These things will only be learned through experience in language and programming industries.
And since I can't argue your future experience, I'm not going to try.

Quote:

---

Originally posted by mclark
OO (at least as preached by OMG and UML) contains both harmoniously. Parameter Polymorhism and Subtype polymorphism are both equal sibling refinments of the relationship between classes. OO embraces both. In C++ different language mechanics, styles and support communities have made these two less related than they should be. But from a design perspective they are unified.

---

Now you are dragging the discussion to a more philosophical level, on the which you are right, of course. But the initial discussion suffered from the lack of understanding that there are two (or more) somewhat linearily independent concepts for implementing polymorphism in the actual C++ standard, and that's a reality we have to live with. I just wanted to point out that this was a source of common misunderstandings.

Since this seems to be the most active thread for STL issues (though my question has nothing to do with MFC) I'll post this here.

Also, it is very similar in challenge to Toxick's string class that led us down the current thread path.

So...

I need a vector with that can never violate the property that it contains only N <= x <= M (0 <= N, M <= INF) elements and vectors with differing N and M's are still of the same type.

1. I thought about using Allocators, but...
* Allocators can't/shoudn't have non-static members (N & M)
* Vector controls the number of elements requested, all the allocator could do is throw() - it's impossible to make N=x=M for some arbitrary x because vector is going to ask for whatever its growth strategy determines
* Avoiding the first bullet with static data makes vectors with different N&M's need to be of differing types (because they'll have to use different allocators)

2. We've been down the inherit from vector road already

3. So, its encapsulation. We wrapper up vector and provide an identical public interface of typedefs and forwarding functions accept for the ones that mutate vector. With these we have to check the constraints and throw or forward as necessary.

Note that the new class will not be STL compilant because now swap() can throw and the standard does not allow this.

My question now is about the iterators. If the wrapper simply provides the member vector's iterator - can a client mutate the vector?

It would seem to be no - because often vector's iterator type is T* but it doesn't have to be. And nowhere in the standard does it say that a mutating iterator has to use a class's public interface.

I'm a bit rusty on iterators so if I'm wrong on this please correct me (that's why I'm posting).

My fear is that it is possible that I make the member vector's iterators accessable - these are converted to a mutating iterator (insert_iterator, etc) which directly mutate the member vector (via private reference in the iterator) thus bypassing my wrapper.

So, is any of this possible? Can fix it by providing my own iterator that embeds an member vector iterator?

Last option of course is to roll-my-own (which I'd like to avoid).

Quote:

---

SDK short for Software Development Kit. Is this the answer you're looking for? You never answered the question -- is the C-library an SDK? If not, why not? Are fopen(), fclose(), malloc(), free(), etc. SDK functions?

---

Yes Paul, anything that doesn't exist inside the construct of a compiler is a external SDK. Again, pick up a book on compiler design then come and argue the semantics about it.

Quote:

---

And you have knowledge that I and others don't write "real programs"?

---

not others, no, just you. Most of the posts in this thread have be quite intelligent.
But I've worked with, taught, have working for me, people who act and talk, just like you. They're don't write real programs either. They do what task I give them.
And while I'm sure you're offended, everything you have thrown in this thread is nothing more advanced or knowledgeable then a fresh college undergrad. You have an opinion on everything, yet have clearly shown me that you lack the experience necessary to form the opinion, so what do you do? You quote others work.
You quote books people have written and standards. Why? Because you can't formulate the opinion on your own, because you don't have the experience. Plain and simple.
You tell other people that they are wrong because they aren't following the rules in your books and standards. This proves to me that you are not a professional programmer. Solutions to complex problems require you bend the rules. C++ itself was required to bend the rules of C. STL was designed to bend the rules of C++. Yet you don't understand that. So I hold my statement to be true.
This is my reason for my attitude with you…unlike the new programmers here, I have the experience to see through it, so yes, I will correct your clearly inexperienced comments, and if you come back and tell me or others they are wrong with conviction, when you clearly don't have the faintest clue, then expect a response from me or from another experienced programmer who will see you are wrong, which is probably why you are in these debates often.
The object of these forums is to teach those who do not know. Consider yourself taught.

PS.

Quote:

---

"we don't write real programs" and "when you step out with the big boys".

---

That we, should be an 'I', I said at the top of the post that it was for you.

And I've already apologized for the "big-boy" comment. That was incorrect of me.

I've actually been a member here for a long time, longer then the year and a half, but I was gone a while and forgot my original name and password, not like a year and a half makes anybody a newbie to the forum as you suggest though.

And again, nothing in this post is meant to be "mean", just explanatory. Please don't take any heart felt offense to anything I say or am implying as its not intended....sad...

Quote:

---

Originally posted by oktronic
not others, no, just you. Most of the posts in this thread have be quite intelligent.

---

I guess you didn't see souldog's post to your first post. But let him defend himself.

Quote:

---

But I've worked with, taught, have working for me, people who act and talk, just like you. They're don't write real programs either. They do what task I give them.

---

Hmmm. Again assuming. Please refrain from assuming, because you know what assume does...

Quote:

---

And while I'm sure you're offended, everything you have thrown in this thread is nothing more advanced or knowledgeable then a fresh college undergrad. You have an opinion on everything, yet have clearly shown me that you lack the experience necessary to form the opinion, so what do you do? You quote others work.

---

I only quoted the standard. That's it. Do you have a problem with that? That's the way I work.

Quote:

---

You quote books people have written and standards. Why? Because you can't formulate the opinion on your own,

---

No, because the standard is where the rules are.

Quote:

---

because you don't have the experience. Plain and simple.

---

Someone was banned here a few months ago -- most people that have been on this board some time know who I'm talking about. He was banned because he demeaned others on this board. If you want to take this attack to this level, calling me (and no doubt, will call others) "inexperienced" or "not real programmers", then this thread should be reported by the moderator.

Quote:

---

You tell other people that they are wrong because they aren't following the rules in your books and standards.

---

Yes, I do, so what? Many others in the non-Visual C++ forum do the same thing. I dare you to go over there and say "they are not professional programmers".

Quote:

---

Solutions to complex problems require you bend the rules. C++ itself was required to bend the rules of C. STL was designed to bend the rules of C++. Yet you don't understand that. So I hold my statement to be true.

---

I don't agree. You can solve complex problems, but stay completely within the rules. Template metaprogramming is complex, but it stays within the rules.

Quote:

---

This is my reason for my attitude with you…unlike the new programmers here, I have the experience to see through it, so yes, I will correct your clearly inexperienced comments, and if you come back and tell me or others they are wrong with conviction, when you clearly don't have the faintest clue

---

Just reading the ANSI standard to someone, and you go postal. It looks like you didn't like that I disagreed with your comments on STL and MFC, so you took it as a personal attack. Why, I don't know. Is it because I took my time to answer you, and you didn't expect it?

Quote:

---

then expect a response from me or from another experienced programmer who will see you are wrong, which is probably why you are in these debates often.

---

Projecting that others will give the same response as you have. Why do you keep doing this, this "projection" thing?
99% of my posts here answer questions, not debate. Out of over 6,000 posts here, how many are "debates"?

Quote:

---

The object of these forums is to teach those who do not know. Consider yourself taught.

---

You haven't taught anything, only preached.

I will continue, if asked if "doing X is safe" or "is this valid" by either not saying anything if the subject is something I'm not familiar with, or respond by, yes, quoting standards, papers, giving small example programs, and possibly mentioning anecdotal experiences that I have had with the problem.

Regards,

Paul McKenzie

(being polite)
No one is an expert on everything. Everyone here is on their own path. Some are farther ahead than others and should help those who want to catch up. The only people who are lost are the ones who think they know where they're going.

(being blunt)
I'm not Paul's buddy, I'm not your dad, and I'm certainly not the moderator. I'm a newbe to this forum - and right now I'm trying to figure out if I wasted two days participating here.

You don't like Paul - fine. Ya wanna bash his experience? - fine. Just don't do it here. Stop wasting my time.

Paul's posts were well thought out and presented professionally. He did not denigrate anyone. His only mistake was being wrong (who isn't every now and again). I didn't have a problem with any of his posts. Everyone here is entitled to have and express their own opinion.

If you really have people like Paul working for you, I hope you have more courtesy and professionalism with them than to chastise them in a public forurm. If not, then I certainly would not want to work for you. My people are my most valuable resource. I treat each one with care and respect.

If you're really bent on making it a pissing contest then don't hold back. Whip it out there! Me? My code has toured the inner solar system. My code has driven across the surface of Mars (and come January I'll be there again).

Think I'm experieced? Guess what? I don't. The more I do the more I discover that there are so many things I don't know. Whether standard, book, article or forum - everyone can teach - everyone needs to learn. I expect to learn something new from each person here in every thread I read. If I don't, I'm just wasting my time.

I'm not trying to impress you and I don't need your friendship. Those things don't put gas in my car or code in my repository.

Now, I've posted a serious STL-related design challenge. If you or Paul want to *demonstrate* your technical skills instead of debate them - then post a reply. Otherwise, I'd rather not waste my time being here.

Quote:

---

Originally posted by mclark

---

Going back to your question. It is interesting, and I've been thinking about it. Haven't concluded what to do with it yet. I'll get to you what I come up with when I get some rest, work on my "non real-world" projects, and answer a few e-mails sent by customers of products that I have created (yes, customers -- who could have thunk it, knowing that I use STL ;).

When I'm wrong, I admit it (thanks to Mr. "'Tox" for setting me straight). Actually, it was an oversight on my part, knowing full well that deleting using the derived class as the base is perfectly legal. I must have had a brain-freeze or something.

But getting back to some points you made:

I don't know everything, no one does. There are some topics in C++ where I do not have that much experience in using. Topics such as template meta-programming (which galathaea seems to be an expert on), I don't comment on too much, because I've never used it to any great extent. (Is it just a rumor that the template meta-programming was first discovered by some daring C++ programmers who said "what the heck -- let's see what happens when we do this trick with the templates.....Whoa!!").

This is the same with many aspects of Windows (with the exception being the base Windows API). Active-X? Never had to create an Active-X control, so I can't (or shouldn't comment) on what I think of Active-X.

If you and others have read my posts, you know that the topics that I stick to are not broad -- C and C++ language issues, some Windows issues, the odd Linux/Unix question, and that's it. Again, mostly answering questions, not "debating". I don't like to do the "debating" stuff unless there is something clearly wrong or not stated correctly.

But don't worry -- if others don't answer your question here, maybe you should repost in the non-Visual C++ forum. Others, such as Graham, and the crew here will come up with some suggestions.

Regards,

Paul McKenzie

[QUOTE]Re: To STL or not to STL, that is the question...

quote:
--------------------------------------------------------------------------------
Originally posted by darwen

Quote:

---

I hate the fact you can't use DEBUG_NEW with it to track down memory leaks.

--------------------------------------------------------------------------------

There's a whole lot of code that is not STL where DEBUG_NEW cannot be used. So that's strike one.

quote:
--------------------------------------------------------------------------------

I hate all the std::blah blah stuff when there's classes in MFC which do virtually the same job but much, much nicer.

--------------------------------------------------------------------------------

OK. Go sort a CList. Also, std:: is called a namespace. Again, nothing to do with STL, but just basic C++. Strike 2.

quote:
--------------------------------------------------------------------------------

I don't even like CArray.
--------------------------------------------------------------------------------

Why? It's MFC, isn't it?

quote:
--------------------------------------------------------------------------------

However CPtrArray, CObArray and CStringArray are very, very, very useful.
--------------------------------------------------------------------------------

If you want all that overhead of CObject added to your classes, go right ahead. Most C++ programmers do not want their classes hamstrung being derived from CObject.

quote:
--------------------------------------------------------------------------------
You can't inherit from any of the STL classes because they don't have virtual destructors so you can't for instance do nice things that you can in MFC like :


code:--------------------------------------------------------------------------------
class CServerNames : public CStringArray
{
public:
CServerNames();
virtual ~CServerNames();
} ;
--------------------------------------------------------------------------------

where this class would load in all server names from wherever.

In one line.

Wherever you wanted to put it in the code.

--------------------------------------------------------------------------------

Let's see the code that loads everything in "one line". Just posting a class without any code is not very convincing.

code:--------------------------------------------------------------------------------
class CServerNames
{
public:
CServerNames() { LoadNames(); }
std::vector<std::string> AllMyNames;
void LoadNames()
{
// Code to load server names into AllMyNames
}
};

void foo()
{
CServerNames S; // I've just loaded all the names
}
--------------------------------------------------------------------------------

I guess that's strike 3, but I'll keep going...

quote:
--------------------------------------------------------------------------------

In an MFC environment I don't see any reason to use it. Ever !

--------------------------------------------------------------------------------

Go sort a CPtrArray, or CStringArray, or CList. You can't unless you write your own code. I can do it in one line of STL code using std::sort. Oh, you must have forgot, STL isn't just about containers, there are a whole lot of algorithm functions (such as std::sort) that work on MFC Array classes. Maybe when you need to sort your CStringArray or call a function that acts on each element of your CPtrArray, you will see for_each() and not know what it does.

quote:
--------------------------------------------------------------------------------

I know my comments are very forward, but I'm invoking discussion.
--------------------------------------------------------------------------------

Looks like your trolling.

Regards,

Paul McKenzie

---

This is his first post in this thread. Long before I got envolved. This is no less demeaning then anything I've said.
Please feel free to read his post here and elsewhere. He constantly preaches and demeans people who ask for help.
His usual response to a question is, "why aren't you using STL?. Most programmers use STL"

This and others for expressing an opinion about STL?
When you report my post to a moderator, make sure to include his, atleast I include examples of his ignorance so nothing I've said wasn't backed up.

And feel free to read my first post here. It was just my opinion, then look at how he responded with stupid comments like

Quote:

---

I guess you are a 'C' programmer who learned C++ later, right?

---

So yes, I'm going to correct his attitude. He doesn't have the right, or the experience, to overrule anybody's opinion, nor attempt to insult them. Or try to claim he has 20 years experience so people should listen to him, when comments like above clearly prove the contrary.
So please, before you jump on me, read his post to other people and you can see why this thread ended up this way.

Since we're all to busy flaming each other to actually talk about C++, I've off and answered by own challenge
cross-checked it against the standard
optimized the lower and upper vector bounds as a template
wrapped them in a base class
called it a day.


If anyone was ever intrested I'm willing to post the code.

For those who just want the executive summary: There was nothing to fear. You cannot get a container-mutating iterator (inserting iterator) without explicitly referencing the container. Since the true vector was encapsulated as a private member (with public forwarding functions) the user will be forced to reference the wrapper class. This in turn ensures that insertion calls will go to the wrapper class (whose whole purpose is to intercept calls that can change the number of elements in the vector). And so, we can freely export the vector's iterators as if they were the wrapper class's without fear that the user will somehow be able to modify the number of elements within the container bypassing the constraint checking of the wrapper.

As for making the upper and lower bounds non-type template members:
+I know the ranges at compile-time
+Increases the speed checking the bounds during insertion & deletion

As for declaring a base class:
-Adds virtual function call overhead to size changing functions
+(0 <= x <= INF) can be represented as a different derived class that is a pure wrapper around the private vector and so the compiler will optimize well.
+I have to anyways cuz of details unrelated to the vector stuff

Quote:

---

Originally posted by oktronic
So please, before you jump on me, read his post to other people and you can see why this thread ended up this way.

---

Oktronic,

Look, I'm not passing judgment on anyone. Paul's posts weren't always very nice - but at least they were still in the gray area. Your's crossed the line. You know it, I know it. But so what, feathers get ruffled. Lets just move on. I've already got plenty of enemies and tons of people to fight with without leaving my office. I don't want to do that here.

Please, please can we just get back on topic - any topic.

I think you and Paul should kiss and make up. If you don't - then stay away from each other. If you're going to fight it out - take it to some AOL teenie-bopper chat room. Just don't fight it out here. It's hard enough finding real content and thought out discussions on the morass that is the WWW.

as an aside: I my experience years-of-experience means exactly crap. I know developers with +10, +15, +20 who suck (that's why their still developers). I know guys with +3 who rock all day long (and who will only be developers until someone gives them the chance to design their own show). Years of experience is much better measure of how long you've been breathing than it is of how good you are at your job. But that's just been my experience I'm sure others' have differed.

Quote:

---

Originally posted by mclark
For those who just want the executive summary: There was nothing to fear. You cannot get a container-mutating iterator (inserting iterator) without explicitly referencing the container. Since the true vector was encapsulated as a private member (with public forwarding functions) the user will be forced to reference the wrapper class. This in turn ensures that insertion calls will go to the wrapper class (whose whole purpose is to intercept calls that can change the number of elements in the vector). And so, we can freely export the vector's iterators as if they were the wrapper class's without fear that the user will somehow be able to modify the number of elements within the container bypassing the constraint checking of the wrapper.

As for making the upper and lower bounds non-type template members:
+I know the ranges at compile-time
+Increases the speed checking the bounds during insertion & deletion

---

Nothing wrong with the design that I see here. There are no mutating algorithms that I can think of that can be used to remove or delete elements, so you're safe if you expose the iterators and the not the vector object itself.

Quote:

---

I need a vector with that can never violate the property that it contains only N <= x <= M (0 <= N, M <= INF) elements and vectors with differing N and M's are still of the same type

---

I'm assuming you mean different internal types, for example a MyVector<int, 1, 10> and MyVector<int, 1, 20>, where "int" is the internal type, and not different class types.

When you create a template, you are creating a different type if the size is a template argument, so a MyVector<int, 1, 10> is a different class type than MyVector<int, 1, 20>.

Regards,

Paul McKenzie

Quote:

---

Originally posted by Paul McKenzie
When you create a template, you are creating a different type if the size is a template argument, so a MyVector<int, 1, 10> is a different class type than MyVector<int, 1, 20>.

---

template <typename T, int N, int M>
class BoundVector : public MyVector<T> {...}

Yeah, yeah. And the base class generalizes the consts away and is only templated for the type (actually I'm only going to use it with one type and the base is there to generalize away a payload that is also contained in the wrapper container but not the member vector - ah, I've digressed into unneeded detail).

the base MyVector is the pure wrapper...

now user functions can manipulate MyVector * without having to be templated for bound and unbound vectors. This could have been accomplished using constructor args for N & M instead of template parameters (with 0 and vector::max_size as defaults) thus eliminating the need for an ABC. But, for the application I need an ABC anyways. The virtual call overhead is only associated with length modifiying members which again for the application are not part of the critical path.

My inital fear came from the container mutating iterators. They inherently embed a pointer to the container object (so they can call insertion and deletion fuctions). If the user could have somehow gotten one of these as the return of a vector::fun call then I'd be dead.

See, then the mutating iterator would call the member vector insert and not the wrapper. Even more hiddious, nothing keeps the mutating iterator from being a friend of the vector and bypassing the front-door public interface all together in loo of some wonderous private method or internals dittling.

I know that sounds unlikely but just imagine a clever STL implementer who thought that beyond the normal generic insertion iterator adaptor, that they'd do a specialization for vector that used wonderous back-doors (since after all they wrote vector also and want the combination to work efficently).

One of the real devils of STL was just how much is implementation specific. Containers are required to have certain interfaces, and adaptors must work with generic types. But nothing stops vendors from specialzing the adaptors to tuned vendor-specific interfaces and nothing forces them to implement in terms of public interfaces.

If anyone can still think up a hole in the design - I'd love to hear it (so I can close it)

Well this is not going to violate your size contraints, but
you can call Remove(...) with just the iterators. So a
user could "remove" enough elements to violate the lower limit on your object, but if he/she then tried to erase them, they would have to go through your wrapper and the problem would be caught. If they did not call erase then it would leave the
vector in a kind of funny state. Just thought I would through it
out there.

Quote:

---

Originally posted by souldog
Well this is not going to violate your size contraints, but
you can call Remove(...) with just the iterators. So a
user could "remove" enough elements to violate the lower limit on your object, but if he/she then tried to erase them, they would have to go through your wrapper and the problem would be caught. If they did not call erase then it would leave the
vector in a kind of funny state. Just thought I would through it
out there.

---

Good catch. I was assuming that remove was a member but of course its just a normal function. Since you caught it - how do you suggest fixing the hole (and yes, remove would violate the lower bounds constraint because I really care about bounding the number of valid elements - not total capacity except that total cap. should never be greater than bounded max of course).

Off the top of my head, it would seem that we'd have to do a full specialization. Does this work? Will this clash with Remove for the underlying vector if unbounded (I think it will since part of this whole exercise was bound and unbound have same type for iterators)?

My second approach would be to try and control the value remove sets the "unused" element to so that it is still a valid (albeit default) value. If possible, this solution works well within the target design. The bounded vectors contain references to nodes in a graph and there is a graph-termination node that works well for a default for remove.

Are we left with just the code comment that says DO NOT DO?

If we fix remove, are all other similar cases (remove_if) automatically fixed (ie implemented in terms of remove)?

I don't know - It takes time to look stuff up and find out, that's why I'm here.

Again, souldog - very good catch.

Ok, I spent my 5 minute walk to the coffee vending machine thinking about the remove hole (yes, where I work for 35 cents you can get a large shot glass of coffee at any hour of the day or night).

My function template full specialization solution will work - if its legal!

(for the language-standard monkies)
Can I fully specialize a function template that's in the std namespace. I know I can't overload it because injecting names into namespace std is illegal (and almost all compilers enforce this).


If it is, then I can fully specialize remove for my iterator of a vector of myT. Note that since my design makes iterators to bound vectors of myT the same type as normal vectors of myT, the full specialization (will my personally chosen default value for remove to use) will apply to both. This is not a problem, since remove makes no claim as to what the value will be. So even if a user has a normal vector of myT that's unrelated to the container I'm building - the semantics of remove are still valid. Now if there were two such concepts as what I'm building that each used myT but needed different defaults for remove then we're hosed. But since the valid default value is of type myT and directly related to myT (think 0 or NULL smart-pointer if you need the example) then hopefully the default value is the only one that ever makes sense for myT.

Now, besides the remove family of functions - are there any others like this lurking out there to frustrate me?

Quote:

---

Originally posted by mclark
Now, besides the remove family of functions - are there any others like this lurking out there to frustrate me?

---

After a quick scan of the standard, the only other occurence of this hole is with 'unique'. Since the standard does not say that unique has to be implemented in terms of the remove family of functions, I'll assume that it has to be specialized seperatly.

Quote:

---

Originally posted by souldog
Well this is not going to violate your size contraints, but
you can call Remove(...) with just the iterators.

---

Yes. I misssed that one also. Thanks, souldog.

Regards,

Paul McKenzie

First of all, my moderator comment: Thank you all for having toned things down ;)

Now for mclark's problem with the bounded vector. IMHO it doesn't make sense to force things when there is no need to do so. In this case, what I mean is whether or not you really need iterator access, standard algorithms etc. for this vector. If you do, then you have to go all the way and implement things correctly, which may prove to be a pain.

In this context, you may find it interesting that algorithm's remove(FI, FI, T) doesn't actually remove elements from the container, it just shuffles them around. See the note on SGI's STL pages:

Quote:

---

The meaning of "removal" is somewhat subtle. Remove does not destroy any iterators, and does not change the distance between first and last. (There's no way that it could do anything of the sort.) So, for example, if V is a vector, remove(V.begin(), V.end(), 0) does not change V.size(): V will contain just as many elements as it did before. Remove returns an iterator that points to the end of the resulting range after elements have been removed from it; it follows that the elements after that iterator are of no interest, and may be discarded. If you are removing elements from a Sequence, you may simply erase them. That is, a reasonable way of removing elements from a Sequence is S.erase(remove(S.begin(), S.end(), x), S.end()).

---

If you do not need to have all this functionality, then by all means, don't bother. In my code I use STL a lot, but I also implement my own non-STL compatible containers for special purposes. For example a cache that holds only N elements and silently deletes one (or more) if a new element is added and the cache is full. Or a customized stack for Undo operations.

Both of these still use some STL internally (the Undo stack is based on vector and deque while the cache uses a std::map for some purposes), but the external interface doesn't have to be STL-compatible and doesn't even fit the model of STL containers.

For some other of my own containers I implemented a fully-fledged STL-compatible interface along with my own iterators. These containers fit the STL model more closely and are more generic in their uses.

In essence, my view is that STL is a great tool to have and use. When you are designing algorithms and methods (my favourite part of my job), then STL comes in really handy. If I need to have a balanced tree that is already optimized, I can just use std::map or std::set, whichever fits best. If I need fast lookup, I can use the hash_map extension, if I need a pretty good string class for general puposes, I'll go anytime with std::string. Vector, list and deque are not among my favourites, but I still use them from time to time. vector has the pitfall of not freeing unused memory, so you are either very careful when to check if size and capacity are too much apart, or you go for a different solution. deque and list have a limited usage scenario in the types of algorithms I write.

I really don't see a point of using MFC containers, unless you are forced to. MFC as a GUI tool is very good. The containers are in my opinon unflexible and slow in comparison to STL ones.

As far as the discussion about OO and GP goes, I don't see a problem of using both, so when I'm writing the overall design it could very well be heavily OO oriented while some of the functionality comes from GP-based parts. Anyways, the dividing line between OO and GP is not clear-cut, as some others have pointed out.

Yves

Quote:

---

(for the language-standard monkies)
Can I fully specialize a function template that's in the std namespace. I know I can't overload it because injecting names into namespace std is illegal (and almost all compilers enforce this).

---

I think that you can (caveat: I'm not a language standard
expert). I base this on the following section in the ISO standard:

Quote:

---

17.4.3.1 Reserved names

1 It is undefined for a C++ program to add declarations or definitions to namespace std
or namespaces within namespace std unless otherwise specified. A program may add
template specializations for any standard library template to namespace std. Such a
specialization (complete or partial) of a standard library template results in undefined
behavior unless the declaration depends on a user-defined name of external linkage and
unless the specialization meets the standard library requirements for the original
template.

---

Although the the phrase, "unless the specialization meets the standard library requirements for the original
template." is a little worrisome - depends on how your
remove would work.

Quote:

---

[lib.alg.remove] 25.2.7 Remove

template<class ForwardIterator, class T>
ForwardIterator remove(ForwardIterator first, ForwardIterator last, const T& value);

template<class ForwardIterator, class Predicate>
ForwardIterator remove_if(ForwardIterator first, ForwardIterator last, Predicate pred);

1 Requires: Type T is EqualityComparable (20.1.1).

2 Effects: Eliminates all the elements referred to by iterator i in the
range [ first, last) for which the following corresponding conditions
hold: *i == value, pred(*i) != false.

3 Returns: The end of the resulting range.

4 Notes: Stable: the relative order of the elements that are not removed
is the same as their relative order in the original range.

5 Complexity: Exactly last - firstapplications of the corresponding predicate.

---

First a little background. Although I have been programming for about 23 years, that is considering 1st grade and logo and all the other systems at schools and home since then. Professionally, I've only coded for around 2 years (give or take if you want to include simulations work for CERN which was undergrad stuff and maybe not taken that seriously). I've coded in lots of different languages along the way. And I'm the type who has opinions on just about everything, from politics to religion to music (yeah, one of "those types"). So I definitely have an opinion on the design of the standard containers.

But I'm also the type that does not enjoy being wrong, and I am very hard on myself when I fail to see something and make errors (yeah, one of "those types"). But I find it is common for people with such a strong dislike of being wrong to build up avoidance reactions so they do not have to admit to themselves an error has been made, and consequently beat themselves up about it. Fortunately, I am not one of those types and indeed am quite the masochist.

But I hate wading through an emotional rollercoaster to get to the facts, needing to pick apart colored phrases for the intent. I want the facts spelled out to me, up front. Its not that I don't enjoy watching a good fight, its just I want the reason spelled out clearly beforehand.

This thread is about the standard library's containers. There have been several points mentioned against them, two prominent categories being bugs and design. Everyone who has mentioned bugs has completely avoided spelling them out when confronted. I will take this to mean: a professional developer need not worry about the stability of their standard library in professional considerations of use. Various vendors have encountered bugs off and on, and worked hard to correct them quickly, but nowadays any bugs very likely lie in the much lesser used parts of the library that have not been as stress tested in strange usage patterns (such as deep in the locales and formatting facets of the stream libraries, or something similar). I stress this because I don't think it is fair to even casually make a suggestion otherwise without evidence, as most of us here are professional programmers who need accurate information to make decisions that could potentially have a lot of money riding on them.

About the design: let my opinion begin!:

A large group of highly influential programmers call c++ a multi-paradigm language, including Stroustrup and Coplien among many others, and this group fairly unanimously agree that a multiparadigm design is superior to single paradigm. And they are highly influential because it is fairly easy to tell from their work that they are very intelligent, that their code is tight, and that they can accomplish very advanced tasks. But instead of focusing on them, let us focus on the arguments given by them and others that have sprungin' forth from my mind...

First a note on OO, polymorphism, and templates. It is true that templates allow for static polymorphism, and that generics are a great way to attend to manipulations of an object without reference to the type's identity. This was the first genius of generics, and various containers and algorithms were its first major use in Ada. However, its important to realise that one of the biggest powers of templates lies not in generic use of a type but in the ability to manipulate types. Metaprogramming techniques are so powerful because one can write metafunctions which take types and a limited set of nontypes as arguments and output a completely different type or nontype. Simple uses are things like transforming a type to a pointer or reference to that type, but the capabilities extend way beyond to major code movement and transformations, detailed function type parsing, etc. So while some simple uses of templates can be seen merely as static polymorphism of a manipulated object's type, it includes capabailities that are not really OOP and much more instances of paradigms like Aspect Oriented Programming. And, being young and easily excitable by trends, I have investigated the possibilities presented by other paradigms.

Which leads me quite naturally into the alleged design flaws of functions not associated to objects. Object Oriented programming has had its share of debates on this topic inside its paradigm, but I won't go over Sutter's or Meyer's positions on how such a design promotes reuse, protects encapsulation, etc.(which are easy enough to google for). Although I agree with them almost entirely, my approach to such considerations is much more pragmatic and less tied to a particular paradigm. I am a professional coder who gets paid to build working applications over and over again. Things that are important to my design are reuse, easy extensibility, clarity of purpose, basically all of the things that help me get my job done with the least frustration. The things that accomplish that are what I consider good design.

Object oriented programming was probably the first paradigm I found which was able to break apart the code freeze that tends to creep into procedural code, and reuse was natural. However I have found that there are obstacles to building a framework in object oriented programming that maintains the ideals of the paradigm, particularly if one of the ideals is that all manipulators reside within classes. To extensibly interface with future objects, there is often a strong desire to continuously refactor common functionalities until the hierarchy becomes monolithic. This tends to allow extensibility at the cost of freezing in a framework's core. Although this is a manageable alternative if you happen to get all the functionality you desire into the core before it gets frozen by extensions, often what I see happening is that eventually interface bloat and violations of Liskov substitutability start arising as one reverts to "add this functionality anywhere that will work" type design. I see MFC as one of the sufferers of this affliction.

But I also have experimented heavily with functional languages, as one of the many things I call myself is a mathematician, and the lambda calculus is a very natural language for me to express programs in. I particularly enjoy playing with the object-oriented functional languages, because they express things a bit closer to the ideal of category theory than basic use of c++. I have found, however, in my limited time as a professional software architect, that advanced c++ usage patterns and idioms can accomodate my preferred method of design. I have found that, much like the Sutter / Meyers arguments, coding independent, reusable morphisms (algorithms) is just as beneficial to the criteria I gave for good design as coding powerful, reusable objects. I make my object's interfaces "state complete" (ie. all valid states may be reached through the mutator interface) and attempt to make the interface names generic enough so that similar objects that may or may not be related through an IS-A relationship can still be manipulated robustly by the reusable morphisms. I use traits to extend my classes orthogonally to any hierarchies they may participate in, and I don't view traits as objects but as additional type-associated morphism decorators. And finally, I try to use as much metaprogramming as possible to automate the construction of my architecture. I find that such a design has allowed me to achieve all of my design ideals, and I have recently needed to focus only on refining the automation.

All of this leads to my evaluation of the standard library's container design. Which I find to be very similar to the style of programming I have found works so well. It is extended orthogonally, preventing monolithic hierarchy lock-down. The algorithms manipulate generic containers polymorphically, through iterator interfaces. This is Aspect-Oriented Programming iin one of its first, less developed, incarnations. I like the basic separations and the powers developed. If I were to complain about the design of the standard library's containers, I would only push to having the aspects better separated, so that the data structures were more composable (giving some access to the internal construction process so that more complex types like trees and graphs were possible along the lines of boost's graph library), and I might desire a couple of extra composites (like a circular buffer in the vein of Metrowerks cdeque). But I wouldn't point to having free functions as bad design unless there were actual practical reasons why such would compromise my conditions of good design. I have yet to see such an argument in this thread.

And finally (really, is galathaea really almost done??) I am just curious. Pre and post condition verifications have always meant wrapping to me. The inheritance method would still require wrapping, if I am not mistaken. I fail to see how inheritance would obviate the need for writing wrapping methods for verification of pre and post conditions, but my reading of that particular leaf of this thread, seemed to have this undercurrent like "well If I don't use inheritance, does that mean I have to wrap everything". I'm not trying to put words in anybody's mouth, I just wanted to express my opinion that that is pretty much the type of activity that requires wrapping, independent of the class model used, at least as far as my limited time in this field has shown.

Galathaea,

This thread has kinda run the gamut of topics (and the odd flame). Any chance you can revisit your last post and insert some quotes so I can better understand what and whose statements you are refering to?


I've done a fair amount of defending STL in this thread, so in the interest of balance - I'll throw in a personal bash agaist it.

STL represented the first major foray into generic programming (as a paradigm) for C++, with a large part of it transplanted from the Ada community. Since generic and policy styled designs were not yet well known or excepted in the C/C++ community (hey, even templates were a pretty tough sell at the time) the STL does have some problems with inflexibilty. Refractoring STL using a more policy-based approach would help it a lot in my opinion.

Now let me defend this with a example...

The standard does not specify the growth strategy for a vector - yet it is often required to understand the growth strategy when you're explicitly managing the underlying memory (shared memory, memory mapped vector, etc). Some of this can be done with Allocators which are very similar in style to a policy class. But Allocators had a very different puprose when they began life than to represent the "allocation policy". And, allocation is not growth. Imagine I need a vector of 7 elements and I have just enough memory for all 7 elements, but the vector only requests (during resizes) vectors of multiples of 5 (0, 5, 10, etc). Now, I cannot actually build my vector of 7 elements. I'm limited to a vector of 5 because that is the largest vector to fit within my memory requirements based on the vector growth pattern. Now, if it's got to be portable - your hosed because every vendor may use a different growth pattern.

The growth pattern of a vector needs to be user specifiable. There are valid reasons for having a growable-array with O(N) growth efficency instead of O(1). There is a tradeoff between efficency and memory use.

Yes, I know about the reserve and swap trick but this doesn't help. (I can provide an example if you really want) but the main point is it is impossible (as far as I can tell) in STL to use std::vector<T> is such a way that memory use is linear to the number of elements (capacity is never greater than high watermark size).

Valid uses for this are when insertions are rare or when memory is constrained.

STL while focusing mainly on algo efficency ignored an important fact in practical designs; memory is a finite, constrained, managed resource. The coupling between a vector's size and it's capacity are to fundamental to the application (the programming) to be left implementation specific. The only control the standard allows is through the Allocators. But allocators can only chose to grant the memory request or reject it. This is to inflexible for practical application designers and developers. We need the control necessary to ensure that the growth strategy of the vector is compatible with the overall memory managment, allocation, and distribution policies of the application architecture.

Ok, my problem with STL is readability and this is from MSDN :

Code:

---

using namespace std;

  // Using the constructor to declare and initialize a pair
  pair <int, double> p1 ( 10, 1.1e-2 );

  // Compare using the helper function to declare and initialize a pair
  pair <int, double> p2;
  p2 = make_pair ( 10, 2.22e-1 );

  // Making a copy of a pair
  pair <int, double> p3 ( p1 );

  cout.precision ( 3 );
  cout << "The pair p1 is: ( " << p1.first << ", "
        << p1.second << " )." << endl;
  cout << "The pair p2 is: ( " << p2.first << ", "
        << p2.second << " )." << endl;
  cout << "The pair p3 is: ( " << p3.first << ", "
        << p3.second << " )." << endl;

  // Using a pair for a map element
  map <int, int> m1;
  map <int, int>::iterator m1_Iter;

  typedef pair <int, int> Map_Int_Pair;

  m1.insert ( Map_Int_Pair ( 1, 10 ) );
  m1.insert ( Map_Int_Pair ( 2, 20 ) );
  m1.insert ( Map_Int_Pair ( 3, 30 ) );

  cout << "The element pairs of the map m1 are:";
  for ( m1_Iter = m1.begin( ); m1_Iter != m1.end( ); m1_Iter++ )
      cout << " ( " << m1_Iter -> first << ", "
          << m1_Iter -> second << " )";
  cout  << "." << endl;

  // Using pair as a return type for a function
  pair< map<int,int>::iterator, bool > pr1, pr2;
  pr1 = m1.insert ( Map_Int_Pair ( 4, 40 ) );
  pr2 = m1.insert ( Map_Int_Pair (1, 10 ) );

  if( pr1.second == true )
  {
      cout << "The element (4,40) was inserted successfully in m1."
          << endl;
  }
  else 
  {
      cout << "The element with a key value of\n"
          << " ( (pr1.first) -> first ) = " << ( pr1.first ) -> first
          << " is already in m1,\n so the insertion failed." << endl;
  }

  if( pr2.second == true )
  {
      cout << "The element (1,10) was inserted successfully in m1."
          << endl;
  }
  else 
  {
      cout << "The element with a key value of\n"
          << " ( (pr2.first) -> first ) = " << ( pr2.first ) -> first
          << " is already in m1,\n so the insertion failed." << endl;
  }

---

Yeach !

Darwen.

Oh there are so much nicer ways of doing this !!

Darwen.

Quote:

---

Originally posted by darwen
Oh there are so much nicer ways of doing this !!

Darwen.

---

It isn't really that difficult to understand. If you remove the cout's here is what's left to understand:

1) a pair:

a template class that contains two values: first and second. Each member are of the type specified by their template arguments. It is a very minimal template class when you think about it. Also, there is nothing STL-ish about it. No iterators, nothing.

2) The make_pair function just sets the pair's first and second members. Again, no big deal to understand.

3) The pair has a copy constructor, so you can construct one pair with another pair. So far, so good (if you consider "good" to mean understandable).

4) A map. Similar to the CMap class in MFC (stores key --> element) , but whose interface is different. The std::map stores pair types. The "first" of each pair is the key, and the "second" of the pair is the element. To initialize a map, you can either insert() a pair, or use operator [] to set the key.

5) A typedef -- hopefully all competent C++ programmers understands what that does.

6) Iterator -- analogous to a pointer (not exactly a pointer, but for this explanation, it will suffice). The for() loop uses iterators to traverse the map. In MFC, they don't have iterators, but they use a POSITION type. You initialize the POSITION member to the beginning of the CMap before traversing, for the iterator, you do the same thing. You increment the POSITION type by calling GetNextwhatever(). An iterator does the same thing, but instead of GetNextwhatever, you increment the iterator with ++ (sorry don't remember right now what the "incrementor" function is with MFC)

So, if you know MFC and use the CMap class, the code you posted isn't that difficult to understand. As a matter of fact, it should be straight-forward once you understand the similarities between an iterator and the POSITION type in MFC.

If you had to write the same thing in MFC, it would look very similar to what you posted, with the exception being the functions to initialize and traverse the map. This is not to say that the MFC version is inferior, just pointing out that the code to do this in MFC would not have been easier or more difficult to understand -- it would be a "push" (using gambling lingo).

I don't count the "cout's" that you posted, since that is <iostream>, not STL (and cout is one of the first things you learn to use in a C++ course).

Now C++ *can* get complex -- Andrei Alexandrescu's "Modern C++ Design" is an example of complex code. But complex code can be achieved without any STL whatsoever.

You mentioned that you do not like templates, and by extension, not like STL. However, the thread (to me at least) was a comparison of MFC to STL. However MFC uses templates also (CMap, CArray, CList, etc.) So there seems to be a disconnect. Maybe you should clarify what it is that you do not like: template vs. non-template code or MFC vs. STL.

Regards,

Paul McKenzie

Quote:

---

Originally posted by mclark
The growth pattern of a vector needs to be user specifiable. There are valid reasons for having a growable-array with O(N) growth efficency instead of O(1). There is a tradeoff between efficency and memory use.

---

I agree entirely on this. The solution IMHO is just to write a my_vector class which does this and add the STL interfaces to it (i.e. iterators etc.). Which means that you can still use all the other parts in STL and if the need should arise, you can probably even change the use of my_vector back to std::vector.

The standard containers are not perfect for all uses (which is IMHO an impossible goal anyways), but understanding them well makes you aware of potential pitfalls and then you know what you can do to fix this, i.e. change the allocator resp. rewrite your own. The advantage STL has with this is that for most types of operations, if you change the container, all the rest of the code doesn't have to be changed a single bit.

Darwen's code:

Code:

---

m1.insert ( Map_Int_Pair ( 1, 10 ) );
m1.insert ( Map_Int_Pair ( 2, 20 ) );
m1.insert ( Map_Int_Pair ( 3, 30 ) );
// is the same as (nicer):
m1[1] = 10;
m1[2] = 20;
m1[3] = 30;

---

The fact that map::insert returns a pair<iterator, bool> may seem complicated, but it's a major efficiency gain if you want to change/have access to the element later. It may seem complicated when you are not used to STL, but it looks pretty natural to someone who uses these things often.

Quote:

---

Originally posted by mclark
This thread has kinda run the gamut of topics (and the odd flame). Any chance you can revisit your last post and insert some quotes so I can better understand what and whose statements you are refering to?

---

Well, instead of doing that, which would violate some of the aesthetic considerations I had about the composition of that post, let me instead kind-of "executive summary" the thing.

The first section was meant to be confrontational, not to a poster in specific (several could fit), but to an "idea". I was laying my cards out; this is where I come from, the experience I have, etc. The kinds of things being cloaked inside some of the package deals presented by the "idea". It was meant as one of those "the emperor has no clothes!" ejaculations, detailing exactly how I felt that despite smoke screens of competence and understanding, the "idea" had yet to present concrete arguments for any of the points kinda muttered in passing, which I felt was avoiding confronting the issue at hand. Which is: what about the standard containers would be a reason for not using them, and: do any of these issues hold favor for other solutions (MFC's containers, hand-rolling, etc.).

Next, I wanted to point to the discussion earlier about the various paradigms of programming, since I felt this was a nice backgrounder to subsequent points. My main goal was to underscore that some of the design decisions in STL did not need to be analysed inside the domain of objects-orientedness. Even though I subsequently point to the opinions of the dynamic duo of ::XXX c++:: <<More XXX c++>> on how interpreting things inside the OO domain still shows the decisions made by the standard library containers and the separation of algorithms to be a Good Thing (c).

Since design was being questioned, I wanted to point to the fact that the modern standard library was being constructed around the same time that the various ideas of Aspect-Oriented programming were first being struggled with, and even if the connection was not explicit to those in the design, the zeitgeist is definitely apparent.

I then wanted to point out exactly some of the design flaws that I felt were avoided by the particular separation of concerns. When building an application, it is always possible to build things tabula rasa. In fact, I have found that an original project without reuse of past project structure benefits immensely from object-oriented design. The hierarchy can be kept very flat, interfaces can be kept minimal, etc. But to benefit from the reuse available by componentisation, we often need to refactor the bits, and I have personally watched while a refactoring process which excluded any templates or generic programming / metaprogramming slowly refactored hierarchies into file system roots / gui system roots / etc. which then later started weaving themselves together in ways where eventually a CObject / QObject / UberObject was desired to add that final layer of indirection to keep the system fluid. Except that the fluidity was maintained at the leaves of the now-monolithic hierarchy, the core had pretty much settled in, and interface bloat abounded. The framework now dictated large design issues that should have been application specific. I have also personally witnessed how the use of generic and preprocessor techniques have been used in refactoring subsystems out of such core-freeze, application architecture once again became fluid, and reuse suddenly grew thousands of times more powerful (subjective sense of freedom metric used here). I witnessed this myself when I was tossed into an architectural position I was originally completely unprepared for, and I feel I understand on a very intuitive level now exactly why decisions like those made in designing the standard library were made. Frameworks need orthogonal flexibility to maximise reuse, and I have this empathetic sixth-sense when looking over the design of the standard library that these guys were struggling with the same issues I know so intimately.

There was a book I read quite a while back (which I can't for the life of me remember which one it was) which gave the suggestion that learning a new programming language every year would show benefits in design decisions. I've found this to be exceptionally true and wanted to share some of the more theoretical epiphanies I've had. I've found c++ to be very much the English of the programming languages, which because of its large, expressive vocabulary is able to formulate nearly any type dynamic I've seen in any other language. C++ sleeps around; it doesn't stay loyal to some fundamental ideal or programming paradigm; it's more pragmatic than that.

And finally (except for a P.S. comment) I wanted to add my own two cents about where the design could be better. I think one of the first problems when approaching a problem domain is that one does not originally think "big enough". Its a natural tendency, because often the problem domain is already so huge that it takes significant amount of work to accomplish. So I wanted to point out that in my opinion, now, after having the standard library's containers available to work with, my opinion is that the idea of containment was not explored more fully. Decisions were made to get a useful utility set of linear containers. However many of the concepts of the container tools implemented by the standard could usefully undergo an additional refactoring into policies, and these components could be useful in facilitating non-linear containers such as circular buffers, deques, linked lists and trees and graphs as well. Additionally, as was subsequently suggested, decisions not specified by the standard could be factored out into alternative composable policy units as well. One further possibility that comes to mind as an example is the size policy on lists (ie, does list store size or calculate it when requested, which affects complexity orders for various members). Because I feel that the extended notion of container with more access to composability of aspects is useflu throughout programming and is the perfect thing to be standardised (parse trees in lexical analysis, visibility object graphs in games, circular buffers in streaming audio playback, just to mention a few examples).

Now, addressing in specific darwen, let me just say that although I realise you started this thread, and mine and some other's responses very likely have sounded harsh, I don't think anyone here has a negative opinion of where you are coming from. It sounds, with your comments on template blah-blah and namespace yadda-yadda, that you have reached a comfortable position in your programming and are avoiding delving deeper into the language. I understand that, as I have reached comfort zones along the way as well (as I think most have). Each false summit in learning allows one to get certain types of tasks done easily at the expense of not addressing the needs for other tasks. But there is a reason that books like Accelerated c++ are suggested in the forums for beginners (which, among other things, avoids alot of those false summits that other teaching methods tend to promote). There is a reason why people read magazines like the c/c++ user's journal to eek out the latest metaprogramming wizardry or exception handling behind-the-back razzamatazz. In computer science, among other knowledge-based careers, there is never a time to stop learning. Yes that's a tiring thought (and even more tiring in practice), but its the reality of the field. Until or unless you find that cushy legacy maintenance job with a stable corporation, you will need to understand how others are programming, which means tackling the fears and learning the language. All of the language.

Actually my point was that this code is mildly unreadable. Yes you can find your way around it but it does take thought and consideration : it's not immediately obvious what its doing.

However, I have seen far far worse than this in MSDN - I just couldn't track it down at the time.

I think at times STL verges on the absolutely unreadable there's not really any need for it.

I try to make my code read as much like English as possible (surely that's the job of any language otherwise why have operator overloading ?). Then when I go back to it in a year or mores time it's obvious what it's trying to do.

STL is about as far from english as you can get in my opinion.

The way I do this is to inherit classes as name them appropriately e.g. CApplicationNameString, CComputerNameString, CParentDirectoryString, CFilesInDirectoryArray etc etc.

Apart from the fact that in doing this you can reduce the amount of code you write considerably it actually makes for a pretty nice thing to look it.

Yes, you can do all of these by using a member std::string but then you lose all the functionality of the string class if you don't implement explicit functions. And implementing a 'std::string &Get()' function inside such a class is messy and detracts from encapsulation.

I can however see some large advantages to having a library which is obviously very useful and feature rich. I just don't like the way that its naming conventions work. And I certainly don't like the lack of virtual constructors (yep, I said it again).

Darwen.

Thanks galathaea for that jem of wisdom. Can we have it in english now please for us plebs who haven't swallowed a dictionary ?

In actual fact I am constantly learning new things, and if forced to I'd learn STL too. I already know much of it, I just don't like it ! Yes, it has some extremely powerful attributes and I must admit I do like the seperation of algorithm from data structure which is inherently very powerful. I just find it cumbersome to use and hard to maintain thats all.

I also have a sixth sense when it comes to good design (if I can be as arrogant as to say so) and yes having a flat object base (i.e. no inheritance) is very nice with no complex hierarchies to clog up the system.

But I still don't like STL.

It seems highly programmer unfriendly to me. Nothing is obvious, and we have lovely member functions which tell us so much about what they do like c_str().

Do you call all your variables useful names like pLNMT or NAV ? Probably not because it would make your code completely incomprehensible (Microsoft is good at doing this especially with its DirectShow example code which I recently had the misfortune to try to make head or tail of).

As I have said before, and will say again I have nothing against the STL if people want to use it. I just don't like it BECAUSE IT IS UNREADABLE !

So many, many things have been added to C++ to enable people to write code resembling English, or to do things in one line which in C would take many like operator overloading etc. All of this in the name of readability.

Sometimes I think the people who came up with STL started off saying to themselves 'right, how can we scare new programmers half to death ? Ah ! I know !'.

All the source code I write I try to make as simple to understand as I possibly can. I can show it to my 13 year old son who doesn't even know Visual Basic and he can understand what is going on, what every function is for and how it all fits together. Show him some STL code and he just goes 'What ??'.

So in short, yes there are advantages to using STL and in principle it's a great idea with loads of nice things. But I won't use it because I'd like to be able to maintain my code without having a nervous breakdown in the process.

Darwen.

Sorry, just read another reply. Gee I'm having to fight my corner hard.

Basically, templates are very powerful and useful things but not particularly reader friendly especially when in .h files.

I do use templates, but prefer to use multiple inheritance and virtual functions wherever I can instead.

True, the code I posted isn't particularly hard to understand but there are ways of making it much much nicer.

I hate the idea of having to typedef things to make them more readable. They should be readable in the first place if you ask me.

Again, C++ can get really messy but messy code is bad code in my opinion. If you start out with a library which isn't easy to read in the first place you're going to have problems later on.

I don't use CArray, CList etc either since CPtrArray, CObArray, CDWordArray and CUIntArray fulfil the vast majority of my needs. I don't like CStringArray too much since it returns CStrings which is inefficient but there you go.

However, you CAN INHERIT from these to make them more readable whereas with STL you can't.

I seem to be running around in circles here. I honestly think that no-one is going to change my mind about STL. The fact you have to typedef things is really nasty since one programmer's bound to call a std::vector<int> something in one place in the code, and another is going to call it something different somewhere else. Yes you can hold the typedefs in a shared .h file but it's not very object-oriented is it ?

Oh well, I'm bound to get half a million flames again. Good job I'm a masochist. Probably why I'm married (laugh).

Isn't there anyone out there who thinks that stl is nasty to read ? Come on, be honest !

Darwen.

Well, STL is indeed difficult to read if you are not used to templates. If you don't know much of STL it's not making things better either. This is one of the reasons, I guess, students are not really taught to use STL at college. Then again there can be a host of other reasons.

But, STL is part of C++ as much as templates are, so if you use STL you can be pretty sure that the next guy on the job will be able to understand your code if he is proficient in C++. Knowledge of STL is part of being a proficient C++ programmer, regardless of what your personal opinion about it is. Knowledge of templates gets the same treatment.

Addionally, some STL constructs can be a bit more complicated than you first thought, but many times, it makes things much clearer. There are numerous examples on the Non-VC++ forum where people come up with STL-one liners for problems. When I started out with STL, I did have some problems with readability. The code just looked strange and very unnatural. But I guess I just got used to it, just in the same way as I got used to templates or involved class hierarchies.