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?
Same as everyone else does. Waking up in the morning with a bright idea. Having it hacked in till lunch. Does not work for all corner cases for about 4 months. Losing interest as I wake up in the morning with a new bright idea. Working on it for another 6 months. Falling back to idea 1 and 'finishing' it... getting excited about reviews in the 'C++ journal' and 'Dr. Jobbs' and Andrew Koenigs review in some odd other magazine. Getting mails why the thing still not works in odd corner cases. Asking for source cod
Sigh... Idiocy all around... How can a template end up,in slow bloated code if it only is a template, hence the word, for something you would have to write EXACTLY the same way by hand? So magically your hand written code would be less bloated, how so?, and less slow, how so? Sorry, such claims are nonsense... they absolutely make no sense.
If you believe templates are slow and big in relation to fast and small you are mistaken. Std::string is certainly in the same par as the C library equivalents.
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.
Hm, don't get what you mean right now. I thought you talked about the std::string implementation itself. Which should be very performant. If one of your coworkers passes a std::string by value, he likely does/did something wrong, and in that case you ofc. have to step through copy constructors and what ever they call... if you really want to:)
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 fun
Well, point is: all that has not much to do with the fact that std::string is a template:). The same would happen with any 'ordinary' class where assignment operators or constructors lead to type conversions.
Well, my only hint to make stuff less ugly is to use _always_ a typedef. So even a list of simple std::strings can be a tEmailList or a worst case tLines (lines of a file).
If your classes and functions are not cluttered with nested template types but the argument types are simple typedefs it is much ea
First, there's a considerable skill difference between being able to use somebody else's templates and being able to write good templates. Second, the compilers and libraries I'm familiar with do a good job now. Third, your complaint with std::string isn't templates, it's with std::string. The most praise I've seen for it is that it's better than having to write and maintain your own string class.
Sorry but this is nonsense. Templates aren't any slower than hand-written code. Compilers may have had problems with templates a decade ago, but template support among the major compilers nowadays are very solid and consistent.
You say "many programmers minimize their use of templates, both in their own code and in their use of templated library code" -- are you saying "many" programmers writing C++ don't use boost or the standard library? Because that too is nonsense. Many bad programmers perhaps?
Not as many as possible. Use the right tool for the right job, as always. But don't rule out libraries because they use templates -- that's downright silly. Templates are made for writing generic code, which maps very well to libraries. Lastly, I don't claim to be a *good* programmer, but I do at least make an effort to understand the language that I'm using.
...but I do at least make an effort to understand the language that I'm using.
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...
Don't you think that implies at least some sort of effort to understand them?
Well apparently not, because you stated multiple points that are, as of today, patently false. Perhaps it was different in C++98, but (in case you didn't know), it's not 1998 anymore.
According to all the latest reports, there was no truth in any of the
earlier reports.
Templates all over again (Score:3, Interesting)
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?
Re: (Score:2)
Re: (Score:2)
Same as everyone else does. ... getting excited about reviews in the 'C++ journal' and 'Dr. Jobbs' and Andrew Koenigs review in some odd other magazine. Getting mails why the thing still not works in odd corner cases. Asking for source cod
Waking up in the morning with a bright idea.
Having it hacked in till lunch.
Does not work for all corner cases for about 4 months.
Losing interest as I wake up in the morning with a new bright idea. Working on it for another 6 months.
Falling back to idea 1 and 'finishing' it
Re: (Score:3)
Sigh ... ... ... they absolutely make no sense.
Idiocy all around
How can a template end up,in slow bloated code if it only is a template, hence the word, for something you would have to write EXACTLY the same way by hand?
So magically your hand written code would be less bloated, how so?, and less slow, how so?
Sorry, such claims are nonsense
Re: (Score:2)
If you believe templates are slow and big in relation to fast and small you are mistaken.
Std::string is certainly in the same par as the C library equivalents.
Re: (Score:1)
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.
Re: (Score:2)
Hm, don't get what you mean right now. ... if you really want to :)
I thought you talked about the std::string implementation itself. Which should be very performant.
If one of your coworkers passes a std::string by value, he likely does/did something wrong, and in that case you ofc. have to step through copy constructors and what ever they call
Re: (Score:1)
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 fun
Re: (Score:2)
Well, point is: all that has not much to do with the fact that std::string is a template :). The same would happen with any 'ordinary' class where assignment operators or constructors lead to type conversions.
Well, my only hint to make stuff less ugly is to use _always_ a typedef. So even a list of simple std::strings can be a tEmailList or a worst case tLines (lines of a file).
If your classes and functions are not cluttered with nested template types but the argument types are simple typedefs it is much ea
Re: (Score:2)
First, there's a considerable skill difference between being able to use somebody else's templates and being able to write good templates. Second, the compilers and libraries I'm familiar with do a good job now. Third, your complaint with std::string isn't templates, it's with std::string. The most praise I've seen for it is that it's better than having to write and maintain your own string class.
Re: (Score:1)
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. ;-)
Re: (Score:2)
Sorry but this is nonsense. Templates aren't any slower than hand-written code. Compilers may have had problems with templates a decade ago, but template support among the major compilers nowadays are very solid and consistent.
You say "many programmers minimize their use of templates, both in their own code and in their use of templated library code" -- are you saying "many" programmers writing C++ don't use boost or the standard library? Because that too is nonsense. Many bad programmers perhaps?
Lastl
Re: (Score:1)
"I'm not bad. I'm just drawn that way." --Jessica Rabbit [imdb.com]
Gee, Wally [imdb.com], if I use as many templates and template libraries as possible, do ya figure I can become a *good* programmer like you? ;-)
Re: (Score:2)
Re: (Score:1)
...but I do at least make an effort to understand the language that I'm using.
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...
Re: (Score:2)
Don't you think that implies at least some sort of effort to understand them?
Well apparently not, because you stated multiple points that are, as of today, patently false. Perhaps it was different in C++98, but (in case you didn't know), it's not 1998 anymore.