How do you know Doom 3 isn't going to OpenGL 2.0? Carmak has repeatedly said that he's under NDA's, and can only talk about what hardware is currently available.
You'll notice that Carmak's name is not listed as an endorser of Cg.
Cg compiler can generate shaders for OpenGL 1.4. Not 2.0. BIG difference.
It would be easier to read the damned article.
OpenGL 1.4 is a completely different beast than OpenGL 2.0. Cg is a direct competitor (and attempt to kill) OpenGL 2.0, and secure NVidia as the dominant provider of 3D APIs.
Tell me, Anonymous Coward, why you think that NVidia made Cg instead of supporting OpenGL 2.0 on their hardware? Try not to use words like "monopoly", "closed standard", and "platform specific."
Maybe a better question is how much money has been spent to protect the smallest amount of information? Nuclear launch codes come to mind.
Or to decrypt the smallest amount of information : Enigma.
Or another question is, if someone were able to misuse some numbers, what would be the most damage they could cause? For me, I think it would be my social security number. 9 Digits. They could run up massive debt in my name. Granted, there's legal protection, but still - losing your government-issued identity is probably the worst thing that could happen to an individual, from the standpoint of protecting a small number of bits.
The most expensive number to ever calculate was of course, 42.
Saying that your data is stored in XML doesn't mean your data has any more intelligent structure than saying that your C program has its data stored with pointers.
Adding a namespace only confuses the issue more.
Intelligent data structures don't happen by accident, and anyone who claims that XML (and by extension, namespaces) makes everything easy is a moron.
Using fuzzy math, I mean. Maybe something there - the production rules are probably more richly capable. Of course, it probably takes a lot longer to run.
Actually, Fuzzy Cellulcar Automata might be the best model of how Quantum Bit computers might work. Interesting.
Think about it - make a honeypot and see how many people stick to it.
Star Wars : Episode II - Attack of the Clones could be the MPAA's poster child, just like Metalica was the RIAA's poster child.
I'm guessing this was all set up by the MPAA, and that they've figured out how to track who downloads it - just like the RIAA figured out how to track who downloaded Metalica.
I would pay money for a channel that had no commercials and showed Eek The Cat, The Maxx, The Simpsons, Futurama, The Family Guy, The Critic, Invader Zim, South Park, Duckman, Space Ghost Coast to Coast, Cowboy Bebop, and The Tick. And I certainly wouldn't mind if the channel also showed King Of The Hill, Beavis and Butthead, Dilbert, PowerPuff Girls, Ren and Stimpy, Sponge Bob Square Pants, classic Looney Tunes, and maybe stuff like Superfriends, The Adventures of Batman And Robin, Animaniacs, Robotech, Voltron, Thundercats, heck even Transformers and He-Man. Organize the shows so that the more adult-only they are, the closer to prime-time they show. Kids shows in the morning, more sarcastic and adult in the evening. Hell, it'd be my favorite channel, and I'd probably watch it every day after work for an hour or two.
I would probably also pay money for a music channel that actually showed videos from music that I mostly like.
And I'd pay for good news coverage.
I have no problem going with a subscription-based model for entertainment that I enjoy.
Well, I guess that explains why the Greeks are still around, then.
Er... Wait... The Greeks aren't still around... Maybe they figured out a way to "drop" something from orbit! Those rascally ancients - you never know what they're going to come up with, next!
Of course typedef's ecapsulate (unless people actively circumvent it)
I liked the rest of your post, and I don't disagree too vehemently with it. =) But this point is sadly mistaken. The only encapsulation is true encapsulation.
The alternative is to essentially name your methods:
please_Dont_Call_This();
Or to say this:
public:// this section is private! don't use it!
If you work for a large enough company for a long enough time, someone is going to use something in the public ("private") section, someone is going to call please_Dont_Call_This, and someone is going to call map::const_iterator foo_it(foo.begin()).
I agree with your assesment that it's good that it will break at compile time. Compile time is the best time to find errors. =) More people should try to write code that will run correctly IFF it compiles correctly. I see far too many tricks that leave everything until runtime, lately.
I don't think "language portability" stand out as a quality in a program, but
The main reason I like "language portability", is because not every coder learned to code in C++. When code is generally readable (meaning, it reads just about the same, no matter what language it's written in), coders are more likely to understand it, and to make fewer mistakes. Perl and some stuff in STL are not generally readable. *shrug* That's another reason why I love STL for an implementation, but I hate it for an interface to my code. (To steal a couple keywords from Pascal.)
And by the way, C++ now has Garbage Collection, thanks to std::auto_ptr - another reason to be distrustful of STL.;)
Anyway, I may not agree with your opinions, but your thoughts are very well said - I commend you on your command of the language and the strength of your convictions. (Even though I hate what you're saying, I'd give you mod points, if I had them.)
Ah, the theory of Proof by Instant Gratification: "If I don't immediately understand it, it must be false."
Some knowledge takes a lot of work to understand. If that were not true, then the Greeks would have killed themselves off with laser-guided nuclear warheads dropped from a solar-powered orbiting platform built from superconducting nano-tubes.
It's not "back on the air", it hasn't left the air, yet. They made enough episodes to keep running, but when they're done, they're not going to make any more.
You're right. What I really meant to say was, "don't let the STL make design decisions for you, especially if you aren't yet really comfortable with the STL."
What if the element 7 is not found? Obviously, it will be, in this simple example, but what if it's not?
Then find returns last, in this case, test.end().
And then, what happens when you say this?
test.erase(test.end());
BOOM. The most obvious way to solve this is to have a local variable, an iterator which stores the temporary result of the find, which you can compare to test.end(). Or you can put it all in one line, and call find twice.
I don't particularly like either option. Especially for something as seemingly simple as removing a specific element from a vector, if it exists.
Now, I'm not concerned about this simple case. I'm talking more about very deep application-specific code. And this is one example where the API of STL isn't too rich. That's the point where you say, "Ah-ha! I know, I'll make my own application-specific class, and provide a rich API for doing exactly that kind of thing." (And for some reason, a lot of people are getting really pissed off at me for suggesting that the STL isn't the Holy Grail.)
Do you even know what a template is? It's a type-parameter, nothing more, nothing less... there's no "protability problems" in templates for the simple uses of templates as type parameters.
std::vector<std::string> myStringVector;
Port that to Pascal, or Java, or Python. Or any other modern language.
It's a gigantic pain in the ass. Once a large portion of the code in an application uses the STL to a large degree, you can not port the application to another language. The syntax is too different, and it will take a huge effort. Not that I think that porting to another language is a common occurance, but it does happen.
That is incorrect. You may use typedefs.
Typedefs don't encapsultate anything! I could take or leave the rest of your arguments, but this point is rediculous.
The typedef keyword defines a synonym for the specified type-declaration.
That's all it is, nothing more, nothing less - and a synonym doesn't encapsulate anything.
but there's no reason not to use the C++ language to obtain best results
Getting rid of the double-negative, you seem to be saying,
always use the C++ language to obtain best results
Maybe in a code-obfuscation contest! =)
OO design is fantastic, and many languages provide a convenient way of using it. But the STL is not the end-all, be-all interface. As I said in another post on this thread, a std::list of space shuttles that are in orbit is a horrible API. Maybe that's the back-end, but that should NOT be the public interface. Because some idiot could accidentally erase one of the shuttles. Instead, those decisions should be tightly encapsulated in one place, and a convenient public API should be exposed.
I think, you would probably find yourself better at home in the JAVA world?
Let's all play nice, kids. There's no place for these kinds of insults in/. It's not like I'm Jon Katz, and I wrote an opinion piece about how the STL caused Columbine. =)
Your argument seems to add up to two things, if I may paraphrase:
1. The STL is the best thing ever. In fact, the C++ standard comitee voted on it. 2. Encapsulate your new "methods" outside class scope, but in a central, controlled location.
Well, I disagree with your first point. I agree that you will have ownership problems if you mix metaphors, and one of the metaphors is a Has-A relationship. If worse comes to worse, I can provide a "data()" method, and later depricate it.
As to your second point, you've got a very strong argument. Except when it comes to application-specific code.
I've seen a lot of code where someone just decides that their class will be in a specific STL container, and that's the API for it. Sometimes, this is a rediculous way of doing things. In many cases, it is far, far better to provide a manager class that has a rich API, that happens to use STL as the back-end.
I understand the value of generic programming. I really think I do. But when it comes right down to it, most applications have a lot more to do with specific programming. One set of tasks, repeated over and over again. Those kinds of things require OO design, and just because you use the STL, that doesn't give you free reign to ignore OO design - which is what I'm seeing. That's the point where I get frustrated that there isn't more code that's still written where a manager class Has-A container of another class. That's a great paradigm, once you get into a large-enough application with specific problems and complexities.
To address a point of yours:
Your own "myString" is not accepted as input by any other code.
What "other code"? I'm involved in a huge application all written by one company - the company I work for. Now, perhaps I'm suffering from a case of Not-Written-Here, but think about it. If you used the str* functions all over the place, instead of making a class that used them, you had a major rewrite to switch to the STL. Why is it so hard to imagine that one day, something better than the STL might come along? Encapsulation is always good. And for God's sakes, think long and hard about using STL for your back-end, for the time being - it's fantastic! That's my point.
I agree, string isn't the greatest example. I'm really talking more about intelligent, meaningful data structures in domain-specific code. Just because there's a list or map waiting for you, that doesn't mean that it's the best possible design for say, keeping track of which space shuttles are in orbit. Sometimes it makes a lot more sense to encapsulate those things, so some idiot programmer doesn't erase one of the shuttles, by mistake. See what I mean?
std::string, just like std::vector. Those seem homogenous to me. When I bought the book "Effective STL" by Scott Meyers, there's documentation in there on std::string. There's also documentation on std::string (okay std::basic_string) in "The C++ Standard Library" by Nicolai M. Josuttis. That all makes it seem like string is part of the STL. What's your argument that it's NOT part of the STL?
std::string already has way too many member functions as it is
string a("%03d %s %0.2f", 1, "hello", 2.75);
Why is it so hard to imagine there are other, perfectly valid things you would want to do with a string? In another post in this thread, I also made the case for having unified, strict control over the implementation of case-insensitive comparisons. I have a hard time imagining a world where a spartan application-specific API is less effective than a rich application-specific API. I agree that trying to redesign the wheel, in adding "new and improved" methods to something as well designed as the STL is nuts - a lot of people try it, and they write crap. I'm talking about an application where there are consistent use patterns in the code, and unfortunately, they're spread all throughout the code. Wouldn't it be better to have a centralized place where those decisions could be controlled, audited, and tested as a cohesive whole? That's why I propose that in a larger application, it often makes sense to code classes to handle application-specific data in a unified way, as opposed to letting each coder make inline decisions while coding.
As a general rule, adding member functions is bad
What? Again, I'm not trying to make a general case for "down with STL" or anything inane like that. STL is fantastic! As a lowest-level in your application. That's my point. Just because the STL is great doesn't mean that it should be involved in all levels of an application's codebase. Specifically, application-specific data should be encapsulated from the application programmer as much as possible, so that changes can be made to the underlying design later. Of course, all of this should be done while providing the best possible API to the application-specific data. Well, what I'm proposing is that the STL is not the best API for all application-specific data. And that people should invent their own rich, application-specific APIs. (And if the underlying code behind their class is written using the STL, that's great - it's a rich toolset that's appropriate in many, many situations.)
In other words, just because your language provides some trick (like STL), that doesn't free you from doing good OO design.
vector::erase doesn't take an integer index, it takes an iterator. Granted you can do math on the iterator, but it makes for long and ugly one-liners to have to refer to your container multiple times on one line. Same thing with vector::insert.
string::insert - if you want to insert one character, or a repeating block of a character, also takes an iterator. string::erase also takes an iterator, to erase one character.
I suppose I should have been more clear and indicated that the methods on the container switched paradigms in a way that I don't like, not the actual containers themselves. Unfortunately, the compiler is not always effective at noticing the difference between an iterator and an integer. My first foray into this was to try to erase the first character in a string. I sent 0 to string::erase, with decidedly unsavory results. Of course, it was my mistake - I should have known the methods better, before attempting to use them - but I tend to find that the most obvious way to use a function should be the way a function actually works, unless there's a good reason it shouldn't. And like I said, unfortunately, compilers (both MSVC++6 and Intel 5.0?) aren't very good at protecting you from making mistakes - because 0 is both a pointer and an integer, for instance. *shrug*
My assertion is that people change their mind. If you have an API that you can live with, you can always change your mind as to how the back-end works, and all you have to change (hopefully!) is the class that you're working on. Encapsulation is your friend.
Also, I hate that people will free-form type functors, in the middle of their code. People end up with multiple functors that all do the same thing. The "method" paradigm is far better, that the algorithm and data are coupled. It makes it far easier to organize your code, far easier to make global changes and manage your code, and reduce bugs!
If you didn't wrap the str* functions in a class, then it cost you a lot of effort to switch your code to std::string. If you DID wrap the str* functions in a class, it was probably pretty painless. (Other than something like sprintf - a major pain in the butt to get working in STL, in my opinion.) I don't think it's responsible to think that you'll ALWAYS code in STL, from now until the end of time. Didn't you think that, at one point, about the str* functions?
Another thing I dislike - many, many languages support OO methodoligy, which makes porting code from one language to another pretty easy. Templates are not easy to port to another language. And they really don't buy you that much, in your end-user code. They're great for quickly developing something, and potentially making it more portable, but if you encapsulate all of the functions (ie METHODS), you can always change your mind, and your client code becomes more portable, too. (As in, porting to another language, if you need to.)
It's always easier to make a change in one place than in a thousand places. Encapsulation makes that possible - but unfortunately the only way to encapsulate something is to wrap it in another API.
I'm not proposing to wrap it because your developers don't like it. Of course they should know it, and they should like the good parts, too. But having everyone re-invent the way to do case-insensitive comparisons is insane. Those kinds of decisions should be encapsulated in one location. If you know a better way than writing an API wrapper, I'd love to hear about it.
And I'm not saying you should make myVector<myString>, I'm talking more about things like myStringVector. Application data should not DEPEND on the STL for its interface. Just because the STL is a useful API, don't think it's the Holy Grail. Too many people just LOVE to code Is-A relationships, when a Has-A relationship is better in every measurable sense.
Slashdot Mirror
OpenGL 2.0 is "the SHADER part."
Cg is attempting to be a replacement for OpenGL 2.0. In that effort, I hope it fails.
It's not vaporware.
How do you know Doom 3 isn't going to OpenGL 2.0? Carmak has repeatedly said that he's under NDA's, and can only talk about what hardware is currently available.
You'll notice that Carmak's name is not listed as an endorser of Cg.
Cg compiler can generate shaders for OpenGL 1.4. Not 2.0. BIG difference.
It would be easier to read the damned article.
OpenGL 1.4 is a completely different beast than OpenGL 2.0. Cg is a direct competitor (and attempt to kill) OpenGL 2.0, and secure NVidia as the dominant provider of 3D APIs.
Tell me, Anonymous Coward, why you think that NVidia made Cg instead of supporting OpenGL 2.0 on their hardware? Try not to use words like "monopoly", "closed standard", and "platform specific."
Cg is to OpenGL 2.0
as DirectX is to OpenGL
It's a closed ("partially open") standard, for a subset of hardware, which is not as forward looking as a proposed competing standard.
Support OpenGL 2.0!
Maybe a better question is how much money has been spent to protect the smallest amount of information? Nuclear launch codes come to mind.
Or to decrypt the smallest amount of information : Enigma.
Or another question is, if someone were able to misuse some numbers, what would be the most damage they could cause? For me, I think it would be my social security number. 9 Digits. They could run up massive debt in my name. Granted, there's legal protection, but still - losing your government-issued identity is probably the worst thing that could happen to an individual, from the standpoint of protecting a small number of bits.
The most expensive number to ever calculate was of course, 42.
Saying that your data is stored in XML doesn't mean your data has any more intelligent structure than saying that your C program has its data stored with pointers.
Adding a namespace only confuses the issue more.
Intelligent data structures don't happen by accident, and anyone who claims that XML (and by extension, namespaces) makes everything easy is a moron.
Fuzzy Cellular Automata?
Using fuzzy math, I mean. Maybe something there - the production rules are probably more richly capable. Of course, it probably takes a lot longer to run.
Actually, Fuzzy Cellulcar Automata might be the best model of how Quantum Bit computers might work. Interesting.
Is this just a trick of the MPAA?
Think about it - make a honeypot and see how many people stick to it.
Star Wars : Episode II - Attack of the Clones could be the MPAA's poster child, just like Metalica was the RIAA's poster child.
I'm guessing this was all set up by the MPAA, and that they've figured out how to track who downloads it - just like the RIAA figured out how to track who downloaded Metalica.
Of course, I could just be paranoid...
We are trying to avoid avoid relying on specific OTC hardware solutions (Emphasis added.)
Looks like this message was dictated with intermitent echo!
Jesse Ventura is an elected official who is not a member of either the Democratic or Republican parties.
Granted, he's governor of the only state that carried Mondale...
I would pay money for a channel that had no commercials and showed Eek The Cat, The Maxx, The Simpsons, Futurama, The Family Guy, The Critic, Invader Zim, South Park, Duckman, Space Ghost Coast to Coast, Cowboy Bebop, and The Tick. And I certainly wouldn't mind if the channel also showed King Of The Hill, Beavis and Butthead, Dilbert, PowerPuff Girls, Ren and Stimpy, Sponge Bob Square Pants, classic Looney Tunes, and maybe stuff like Superfriends, The Adventures of Batman And Robin, Animaniacs, Robotech, Voltron, Thundercats, heck even Transformers and He-Man. Organize the shows so that the more adult-only they are, the closer to prime-time they show. Kids shows in the morning, more sarcastic and adult in the evening. Hell, it'd be my favorite channel, and I'd probably watch it every day after work for an hour or two.
I would probably also pay money for a music channel that actually showed videos from music that I mostly like.
And I'd pay for good news coverage.
I have no problem going with a subscription-based model for entertainment that I enjoy.
Well, I guess that explains why the Greeks are still around, then.
Er... Wait... The Greeks aren't still around... Maybe they figured out a way to "drop" something from orbit! Those rascally ancients - you never know what they're going to come up with, next!
Of course typedef's ecapsulate (unless people actively circumvent it)
:
:
// this section is private! don't use it!
;)
I liked the rest of your post, and I don't disagree too vehemently with it. =) But this point is sadly mistaken. The only encapsulation is true encapsulation.
The alternative is to essentially name your methods
please_Dont_Call_This();
Or to say this
public:
If you work for a large enough company for a long enough time, someone is going to use something in the public ("private") section, someone is going to call please_Dont_Call_This, and someone is going to call map::const_iterator foo_it(foo.begin()).
I agree with your assesment that it's good that it will break at compile time. Compile time is the best time to find errors. =) More people should try to write code that will run correctly IFF it compiles correctly. I see far too many tricks that leave everything until runtime, lately.
I don't think "language portability" stand out as a quality in a program, but
The main reason I like "language portability", is because not every coder learned to code in C++. When code is generally readable (meaning, it reads just about the same, no matter what language it's written in), coders are more likely to understand it, and to make fewer mistakes. Perl and some stuff in STL are not generally readable. *shrug* That's another reason why I love STL for an implementation, but I hate it for an interface to my code. (To steal a couple keywords from Pascal.)
And by the way, C++ now has Garbage Collection, thanks to std::auto_ptr - another reason to be distrustful of STL.
Anyway, I may not agree with your opinions, but your thoughts are very well said - I commend you on your command of the language and the strength of your convictions. (Even though I hate what you're saying, I'd give you mod points, if I had them.)
Quicksort - great example! If I had moderation points, I'd give them to you.
I've got another one - try to explain transistors without math.
Ah, the theory of Proof by Instant Gratification: "If I don't immediately understand it, it must be false."
Some knowledge takes a lot of work to understand. If that were not true, then the Greeks would have killed themselves off with laser-guided nuclear warheads dropped from a solar-powered orbiting platform built from superconducting nano-tubes.
It's not "back on the air", it hasn't left the air, yet. They made enough episodes to keep running, but when they're done, they're not going to make any more.
Just like The Family Guy, just like Futurama.
You're right. What I really meant to say was, "don't let the STL make design decisions for you, especially if you aren't yet really comfortable with the STL."
And yes, I work in the medical field. =)
test.erase(find(test.begin(), test.end(), 7));
What if the element 7 is not found? Obviously, it will be, in this simple example, but what if it's not?
Then find returns last, in this case, test.end().
And then, what happens when you say this?
test.erase(test.end());
BOOM. The most obvious way to solve this is to have a local variable, an iterator which stores the temporary result of the find, which you can compare to test.end(). Or you can put it all in one line, and call find twice.
I don't particularly like either option. Especially for something as seemingly simple as removing a specific element from a vector, if it exists.
Now, I'm not concerned about this simple case. I'm talking more about very deep application-specific code. And this is one example where the API of STL isn't too rich. That's the point where you say, "Ah-ha! I know, I'll make my own application-specific class, and provide a rich API for doing exactly that kind of thing." (And for some reason, a lot of people are getting really pissed off at me for suggesting that the STL isn't the Holy Grail.)
Do you even know what a template is? It's a type-parameter, nothing more, nothing less... there's no "protability problems" in templates for the simple uses of templates as type parameters.
/. It's not like I'm Jon Katz, and I wrote an opinion piece about how the STL caused Columbine. =)
std::vector<std::string> myStringVector;
Port that to Pascal, or Java, or Python. Or any other modern language.
It's a gigantic pain in the ass. Once a large portion of the code in an application uses the STL to a large degree, you can not port the application to another language. The syntax is too different, and it will take a huge effort. Not that I think that porting to another language is a common occurance, but it does happen.
That is incorrect. You may use typedefs.
Typedefs don't encapsultate anything! I could take or leave the rest of your arguments, but this point is rediculous.
The typedef keyword defines a synonym for the specified type-declaration.
That's all it is, nothing more, nothing less - and a synonym doesn't encapsulate anything.
but there's no reason not to use the C++ language to obtain best results
Getting rid of the double-negative, you seem to be saying,
always use the C++ language to obtain best results
Maybe in a code-obfuscation contest! =)
OO design is fantastic, and many languages provide a convenient way of using it. But the STL is not the end-all, be-all interface. As I said in another post on this thread, a std::list of space shuttles that are in orbit is a horrible API. Maybe that's the back-end, but that should NOT be the public interface. Because some idiot could accidentally erase one of the shuttles. Instead, those decisions should be tightly encapsulated in one place, and a convenient public API should be exposed.
I think, you would probably find yourself better at home in the JAVA world?
Let's all play nice, kids. There's no place for these kinds of insults in
Your argument seems to add up to two things, if I may paraphrase :
:
1. The STL is the best thing ever. In fact, the C++ standard comitee voted on it.
2. Encapsulate your new "methods" outside class scope, but in a central, controlled location.
Well, I disagree with your first point. I agree that you will have ownership problems if you mix metaphors, and one of the metaphors is a Has-A relationship. If worse comes to worse, I can provide a "data()" method, and later depricate it.
As to your second point, you've got a very strong argument. Except when it comes to application-specific code.
I've seen a lot of code where someone just decides that their class will be in a specific STL container, and that's the API for it. Sometimes, this is a rediculous way of doing things. In many cases, it is far, far better to provide a manager class that has a rich API, that happens to use STL as the back-end.
I understand the value of generic programming. I really think I do. But when it comes right down to it, most applications have a lot more to do with specific programming. One set of tasks, repeated over and over again. Those kinds of things require OO design, and just because you use the STL, that doesn't give you free reign to ignore OO design - which is what I'm seeing. That's the point where I get frustrated that there isn't more code that's still written where a manager class Has-A container of another class. That's a great paradigm, once you get into a large-enough application with specific problems and complexities.
To address a point of yours
Your own "myString" is not accepted as input by any other code.
What "other code"? I'm involved in a huge application all written by one company - the company I work for. Now, perhaps I'm suffering from a case of Not-Written-Here, but think about it. If you used the str* functions all over the place, instead of making a class that used them, you had a major rewrite to switch to the STL. Why is it so hard to imagine that one day, something better than the STL might come along? Encapsulation is always good. And for God's sakes, think long and hard about using STL for your back-end, for the time being - it's fantastic! That's my point.
I agree, string isn't the greatest example. I'm really talking more about intelligent, meaningful data structures in domain-specific code. Just because there's a list or map waiting for you, that doesn't mean that it's the best possible design for say, keeping track of which space shuttles are in orbit. Sometimes it makes a lot more sense to encapsulate those things, so some idiot programmer doesn't erase one of the shuttles, by mistake. See what I mean?
I agree, but it's not part of STL.
std::string, just like std::vector. Those seem homogenous to me. When I bought the book "Effective STL" by Scott Meyers, there's documentation in there on std::string. There's also documentation on std::string (okay std::basic_string) in "The C++ Standard Library" by Nicolai M. Josuttis. That all makes it seem like string is part of the STL. What's your argument that it's NOT part of the STL?
std::string already has way too many member functions as it is
string a("%03d %s %0.2f", 1, "hello", 2.75);
Why is it so hard to imagine there are other, perfectly valid things you would want to do with a string? In another post in this thread, I also made the case for having unified, strict control over the implementation of case-insensitive comparisons. I have a hard time imagining a world where a spartan application-specific API is less effective than a rich application-specific API. I agree that trying to redesign the wheel, in adding "new and improved" methods to something as well designed as the STL is nuts - a lot of people try it, and they write crap. I'm talking about an application where there are consistent use patterns in the code, and unfortunately, they're spread all throughout the code. Wouldn't it be better to have a centralized place where those decisions could be controlled, audited, and tested as a cohesive whole? That's why I propose that in a larger application, it often makes sense to code classes to handle application-specific data in a unified way, as opposed to letting each coder make inline decisions while coding.
As a general rule, adding member functions is bad
What? Again, I'm not trying to make a general case for "down with STL" or anything inane like that. STL is fantastic! As a lowest-level in your application. That's my point. Just because the STL is great doesn't mean that it should be involved in all levels of an application's codebase. Specifically, application-specific data should be encapsulated from the application programmer as much as possible, so that changes can be made to the underlying design later. Of course, all of this should be done while providing the best possible API to the application-specific data. Well, what I'm proposing is that the STL is not the best API for all application-specific data. And that people should invent their own rich, application-specific APIs. (And if the underlying code behind their class is written using the STL, that's great - it's a rich toolset that's appropriate in many, many situations.)
In other words, just because your language provides some trick (like STL), that doesn't free you from doing good OO design.
vector::erase doesn't take an integer index, it takes an iterator. Granted you can do math on the iterator, but it makes for long and ugly one-liners to have to refer to your container multiple times on one line. Same thing with vector::insert.
string::insert - if you want to insert one character, or a repeating block of a character, also takes an iterator. string::erase also takes an iterator, to erase one character.
I suppose I should have been more clear and indicated that the methods on the container switched paradigms in a way that I don't like, not the actual containers themselves. Unfortunately, the compiler is not always effective at noticing the difference between an iterator and an integer. My first foray into this was to try to erase the first character in a string. I sent 0 to string::erase, with decidedly unsavory results. Of course, it was my mistake - I should have known the methods better, before attempting to use them - but I tend to find that the most obvious way to use a function should be the way a function actually works, unless there's a good reason it shouldn't. And like I said, unfortunately, compilers (both MSVC++6 and Intel 5.0?) aren't very good at protecting you from making mistakes - because 0 is both a pointer and an integer, for instance. *shrug*
I think I saw it in a Mark Lutz book. I shuddered in pain and horror, when I first saw it. =)
You're right, I should have given credit where credit (or blame?) is due.
#define private public
The one macro you'll ever need. Heh.
My assertion is that people change their mind. If you have an API that you can live with, you can always change your mind as to how the back-end works, and all you have to change (hopefully!) is the class that you're working on. Encapsulation is your friend.
Also, I hate that people will free-form type functors, in the middle of their code. People end up with multiple functors that all do the same thing. The "method" paradigm is far better, that the algorithm and data are coupled. It makes it far easier to organize your code, far easier to make global changes and manage your code, and reduce bugs!
If you didn't wrap the str* functions in a class, then it cost you a lot of effort to switch your code to std::string. If you DID wrap the str* functions in a class, it was probably pretty painless. (Other than something like sprintf - a major pain in the butt to get working in STL, in my opinion.) I don't think it's responsible to think that you'll ALWAYS code in STL, from now until the end of time. Didn't you think that, at one point, about the str* functions?
Another thing I dislike - many, many languages support OO methodoligy, which makes porting code from one language to another pretty easy. Templates are not easy to port to another language. And they really don't buy you that much, in your end-user code. They're great for quickly developing something, and potentially making it more portable, but if you encapsulate all of the functions (ie METHODS), you can always change your mind, and your client code becomes more portable, too. (As in, porting to another language, if you need to.)
It's always easier to make a change in one place than in a thousand places. Encapsulation makes that possible - but unfortunately the only way to encapsulate something is to wrap it in another API.
I'm not proposing to wrap it because your developers don't like it. Of course they should know it, and they should like the good parts, too. But having everyone re-invent the way to do case-insensitive comparisons is insane. Those kinds of decisions should be encapsulated in one location. If you know a better way than writing an API wrapper, I'd love to hear about it.
And I'm not saying you should make myVector<myString>, I'm talking more about things like myStringVector. Application data should not DEPEND on the STL for its interface. Just because the STL is a useful API, don't think it's the Holy Grail. Too many people just LOVE to code Is-A relationships, when a Has-A relationship is better in every measurable sense.
That's my argument. I could be wrong. =)