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?
>Uh, have you seen the stuff that Andrei Alexandrescu does with templates? Nothing anymore because he moved on to D ?
But yes, Andrei Alexandrescu knows his shit and he's clearly good. Too bad D has a more or less forced GC (without it you're pretty much freestanding, no library will work without).
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
Getting mails why the thing still not works in odd corner cases. Asking for source code to confirm it and get some MVC++ sources (sigh) and some for Borland 2001s C++ compiler and an old Aztec or Symantec...
Are you telling us about something that happened almost 15 years ago?
Are you seriously implying that template's support is shaky, and justify that claim by using compilers that were two or three years old after C++98 went out?
The irony of defending the alleged complexity of one aspect of a computer language by being able to name all the people in the world who have actually got a decent grasp of it is quite telling...
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.
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.
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
The C macro preprocessor is a great way to generate incorrect code; textual substitution is not a viable way to produce type-generic code.
The biggest problem with C++ templates is the insistence on compile-time resolution of template expressions. This means that, in order to actually use templates as a type-generic mechanism, we have to place them in header files, which increases compilation times. More importantly, the practice of instantiating large numbers of heavily-specialized compiled templates means
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:0)
>Uh, have you seen the stuff that Andrei Alexandrescu does with templates?
Nothing anymore because he moved on to D ?
But yes, Andrei Alexandrescu knows his shit and he's clearly good. Too bad D has a more or less forced GC (without it you're pretty much freestanding, no library will work without).
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:0)
Getting mails why the thing still not works in odd corner cases. Asking for source code to confirm it and get some MVC++ sources (sigh) and some for Borland 2001s C++ compiler and an old Aztec or Symantec ...
Are you telling us about something that happened almost 15 years ago?
Are you seriously implying that template's support is shaky, and justify that claim by using compilers that were two or three years old after C++98 went out?
Re: (Score:0)
The irony of defending the alleged complexity of one aspect of a computer language by being able to name all the people in the world who have actually got a decent grasp of it is quite telling ...
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:0)
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.
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.
The solution is simple: (Score:0)
Pass by const reference.
(Btw, std::strings may have their warts, but at least they TRACK THE FUCKING LENGTH OF THE STRING correctly. Not so for C "strings".)
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:0)
The C macro preprocessor is a great way to generate incorrect code; textual substitution is not a viable way to produce type-generic code.
The biggest problem with C++ templates is the insistence on compile-time resolution of template expressions. This means that, in order to actually use templates as a type-generic mechanism, we have to place them in header files, which increases compilation times. More importantly, the practice of instantiating large numbers of heavily-specialized compiled templates means
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.