Thanks for your comment. FWIW, here's what really happened. The function took a std:string as a parameter. The nominal use of it was to put in a char * literal which would get automatically converted to a string, so the parameter couldn't be passed by reference. While trying to step into the function, I stepped through the string constructor, which made several small function calls. When I replaced the parameter declaration with "char *", all that went away, and I was able to step directly into the function.

To be fair, the actual runtime overhead of the std:string constructor might be minimal, and could potentially be avoided by using a reference in many cases - though not this one. So, my concern about bloat when using template classes was anecdotal and might be overblown. As with any tool, you should use the right one for the job, and the string class does have some advantages, notably the ability to magically grow as needed. In this case, though, a char * would have worked just fine, so I contend that the original programmer didn't choose the right tool for this job.

I've used STL classes over the years, primarily vector and string, but I've had many experiences like this where something that C provided was a better fit for what I was trying to do. For example, a file name parameter probably doesn't need to magically grow, so a char * works just fine for that. That sort of experience, combined with having to repeatedly consult the documentation about STL functions because they aren't very intuitively named, has led me to prefer C constructs when I could potentially use either. That's what I meant in my original post when I said "many programmers minimize their use of templates".

Then again, I'm from the "less is more" school of programming. Some folks like to impress themselves and/or their friends by using as many fancy constructs as possible, in order to be judged a "*good* programmer" - as another commenter in this thread evidently does.

Though my original post was perhaps a bit overstated (for your entertainment), I actually do use the STL, but only at a very basic level, and only where it explicitly solves a problem. I think I would be a lot warmer to it if C++ templates and the STL itself were better designed. For example, I much prefer Python's string functions and MFC's "CString" class to std:string.

But even if templates and the STL were better, good-old-fashioned C still can meet most such needs very nicely. And as Tim Peters said, "Beautiful is better than ugly." (BTW, I wonder if Dr. Stroustroup thinks his template baby is beautiful? - maybe he'll tell us. ;-)

Unlike us "bad" programmers...

My basic point in the original point was that C++ templates are so complex as to be nearly impossible for most of us to *fully* understand. Don't you think that implies at least some sort of effort to understand them? In retrospect, though, my failure to fully understand them can only be attributed to my own abilities, not to the design of templates themselves. My bad...

"I'm not bad. I'm just drawn that way." --Jessica Rabbit

Gee, Wally, if I use as many templates and template libraries as possible, do ya figure I can become a *good* programmer like you? ;-)

Thanks. Please forgive my idocy. I think I got fooled the other day when I stepped through several std:string functions that were involved in passing a std:string parameter into a function. Then I replaced the parameter with a char *, and there was nothing to step through anymore. Apparently, though, all that std::string stuff would magically disappear in the release version. I forget whether the string parameter was passed by reference or not - somebody else wrote that part.

To be fair, my complaint about portability was due to a very bad experience I had over 10 years ago. Maybe it's gotten better since then. ;-)

So what if you used a set of powerful templates to create a complex layered system rather than writing a simple one by hand? For an example, compare the STL string class to C's string library. It's not about the use of templates, per se, it's about the design of the systemthat the use of templates may lead you to. In effect, the major benefit of templates - their ability to create large, reusable systems - is a major drawback if you're looking for something fast and small.

Likely true, but the benefit of C that I'm highlighting is that it gives you very little rope to hang yourself with in terms of creating a system composed of layer-upon-layer of classes. In contrast, I once worked with someone who loved to create class-upon-inherited-class for the simplest things in C++. Everyone who looked at his code wondered "where's the beef?", that is, the part that did something useful. The code worked, so the useful part must have been in there somewhere. But it sure wasn't easy to locate. I think he had tiny bits of useful stuff cleverly hidden in most of his classes. As best I could tell, though, some did nothing at all.

Basically, I regard C's inability to create a large complex hierarchy of objects, together with its ability to support objects in a basic way via pointers to structures, as a primary selling point that explains its persistence in a world where a "better" superset has long been available. That's not to say that the C++ approach of layering inherited classes is bad or wrong, just that its lack in C can prevent a certain category of problems.

Back in the old days, when there used to be book stores, I used to marvel at the girth of the C++ books on the shelf. After having programmed C++ for many years, did I really know all the stuff in one of those fat books? Probably not...

Having used both extensively, I can tell you that it is much more difficult to write slow, bloated, overly complex code in C than in C++. It keeps you honest in that way. Also, most of the good things of C++ such as object-oriented programming and templating can be done at a basic level in C. For example, in C++, a class function is just an ordinary function with a hidden pointer to a (class) structure. Why not just pass in a pointer to a class structure in C? And class member privacy can easily be a matter of naming convention rather than something the compiler enforces.

C++ has its value, and may be better suited for building large, complex, systems such as GUI frameworks, but C is a great choice for cases where speed and minimal size are paramount, such as most embedded code as well as the Linux kernel. In principle, it's possible to write fast, small code in C++ by using its features selectively. However, if you do that, you're left with mostly just the features you could have emulated in C anyway.

Oh, and did I mention that in its current form C is the "perfect" programming language? Other languages have their own goals, but judged in terms of its own goals, C does what it's trying to do better than just about any other language - far better than C++ meets its goals. There's a reason that changes to C over its many years have been very minimal, and virtually always for the better.

I'm a fan of C++ overall, but it seems to me that C++ templates are a bit of a disaster. They're so complex that I doubt that anybody but you and P. J. Plauger *fully* understands them. Also, when they're actually used, they often result in bloated, slow code - as I recently experienced when stepping through some STL string functions. Further, they bring on a lot of portability issues, evidently due to the difficulty that even the compiler folks have had in understanding and implementing them. Therefore, many programmers minimize their use of templates, both in their own code and in their use of templated library code.

Compared to the complexity of C++ templates, the C macro preprocessor provides a rudimentary form of templating via its very simple and powerful paradigm of text substitution. I've had some success implementing a limited form of generic (type independent) programming in C using just the C preprocessor. I've had much less success doing generic programming via C++ templates.

If you had templates to do all over again, what would you do differently? Was all the complexity of C++ templates (e.g. "partial specialization") really necessary to achieve its goals? Were the goals maybe too ambitious?

Why ask Dr. Stroustrup and wait for an answer? Siri could tell you now...

"Never ascribe to conspiracy that which can be adequately explained by incompetence." (Or something like that.)

That's nice. Now, I no longer need to remember "12345" for Slashdot - I can go back to just using "pass".

Right! Digital imaging is just technology, but the way a chemical image suddenly "pops" out of nothing is truly magic. It was a thrill for me every time.

That said, each time I spent an evening slaving away in the darkroom, I ended up with just a small stack of not-so-great prints to show for it. Very discouraging.

I learned what little I know about the darkroom from a short community ed course many years ago, but if I had a teacher available who could have taught me how to make a really good print, it might have been a different story. Now, though, it's hard to beat the speed and convenience of digital printing - even if the magic - and artistry - is lost.

The folks who designed my desktop computer were really thinking ahead on this one: it was built without a speaker. Besides enhancing security, an auxiliary benefit of their clever "no-speaker defense" is that saved the manufacturer cost and space.