quote:Original post by fizban75 Like I said, this doesn''t say what''s wrong with C++ templates or that they don''t do what they were meant to do.
The article describes some things which people commonly do with C++ templates, and goes on to explain how various other systems cope better with the demands that are often put on C++ templates.
quote: It just says that they are similar to something that has been done in another language.
It doesn''t *just* say that. The author makes it fairly clear that he considers them inferior. Have you used any of the alternative systems he mentions?
quote: I didn''t seen anything in that article that shows that C++ templates are "wrong" but just that they do things in a different way than what''s been done in other languages.
The implication is supposed to be that they are `wrong'' because they solve a problem for which solutions were already available in a manner inferior to those solutions.
quote: Wow, what an enlightened discussion we''re having. Such an adversarial tone, tsk, tsk.
It was a suitable response to your suggestion `if you want to complain about C++ templates, then I guess you can go write your games in Lisp...''.
quote: How old are you? Ten?
What would it matter if I am? Are you interested in discussing the contents of the article or not?
Yes, I''d love to discuss the content of the article, but since I have my head in the sand, that may be difficult.
So, the article says C++ templates are inferior to Lisp. Fine. So what should we do? I see two options.
1) Make C++ have better generic programming support. (Any ideas? Because of the strong typing in C++, it doesn''t seem to me that there''s a way other than templates without removing the type constraints.) or 2) Write our programs in Lisp. Which is what I said originally and caused you to tell me to act like an ostrich.
Well the obviously interesting option to explore is 1., since with 2. all discussion basically ends there! (or rather, moves on to the drawbacks of using Lisp for game programming)
Is there another compiler model for C++ that would allow it to retain it''s trademark typing, while relaxing some of the code emission constraints? Comeau''s troubles trying to implement the template "export" keyword seems to suggest it''s not possible.
Then, is there a way to somewhat relax the typing of C++ without making a half-assed Lisp out of it?
It's only funny 'till someone gets hurt.And then it's just hilarious.Unless it's you.
Here''s the thing. I hear people saying that something is wrong with C++ templates. I however, don''t see that, nor do I see how that article can say that because it''s comparing two highly different things: A strongly-typed language (C++) vs dynamically-typed languages (ML and Lisp).
So, to say that C++ templates are wrong is to say that strong-typing is wrong.
In order to "fix" C++ templates, you have to remove the strong-typing. I don''t want to do that, because that''s something I like about C++. If I want complete dynamic typing, I''ll write in Python, Perl, Lisp and whole suite of languages that do things that way.
C++ was not meant to be dynamically typed the way those other languages are, nor should it, IMO. If you want dynamic typing, you should choose those other languages. In fact, you can write games in Python and get the dynamic typing. I, however, will continue to write in C++, because I personally prefer that language.
So again, I''ll say, if you don''t like the way C++ does generic programming, you are free to choose another language that does it differently. Remember, it''s different, not right or wrong.
quote:I hear people saying that something is wrong with C++ templates. I however, don''t see that, nor do I see how that article can say that because it''s comparing two highly different things: A strongly-typed language (C++) vs dynamically-typed languages (ML and Lisp).
Lisp is strongly typed. Judging from your post, you may be confusing strong typing with static typing. Static typing and dynamic typing are opposites. Strong typing and weak typing are opposites.
quote:1) Make C++ have better generic programming support. (Any ideas? Because of the strong typing in C++, it doesn''t seem to me that there''s a way other than templates without removing the type constraints.)
The conclusion of the article says:
quote:For one thing, templates hurt the C++ compiler''s ability to generate efficient code. It might surprise you to hear that, considering that C++ is "efficient" while functional languages like ML and Scheme are "inefficient," but it''s true. C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn''t know, so it has to just blindly apply the copy-and-paste strategy and then see what happens. In ML or Scheme, though, aside from the individual benefits described above, the simple fact that you''re telling the compiler what you want to achieve lets it optimize for you much more effectively.
quote:Original post by fizban75 Here''s the thing. I hear people saying that something is wrong with C++ templates. I however, don''t see that, nor do I see how that article can say that because it''s comparing two highly different things: A strongly-typed language (C++) vs dynamically-typed languages (ML and Lisp).
ML is statically-typed.
quote: So, to say that C++ templates are wrong is to say that strong-typing is wrong.
Please try and be consistent in your terminology. Strong (or strict) typing is not the same thing as static typing. Keeping with strict typing, it might be a legitimate question to ask whether it is `wrong'', particularly in the context of metaprogramming. It might also be legitimate to say something like a hybrid approach to metaprogramming is a good idea, where perhaps a Lisp system is used as a kind of preprocessor for generating generic C++ code. Or maybe use Lisp for the bulk of development, whilst interfacing to C++ components via FFI where desirable performance cannot be gained with Lisp. Your attitude precludes such lines of discussion.
quote: So again, I''ll say, if you don''t like the way C++ does generic programming, you are free to choose another language that does it differently. Remember, it''s different, not right or wrong.
I already write much of my s/w using dynamically-typed languages. That doesn''t mean I''m uninterested in discussing how C++ templates might be improved, or alternative approaches to generative s/w development.
I would agree that metaprogramming with templates is a "kludge" and I wouldn''t be adverse to see it replaced with something like you suggest. However, I don''t think that this wrongness is something that can be attributed to templates themselves, but more to those that use them for this purpose, since that wasn''t their original intention.
BTW, my "attitude" was a result of you telling me to stick my head in the sand, which I found inappropriate.
quote:For one thing, templates hurt the C++ compiler''s ability to generate efficient code. It might surprise you to hear that, considering that C++ is "efficient" while functional languages like ML and Scheme are "inefficient," but it''s true. C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn''t know, so it has to just blindly apply the copy-and-paste strategy and then see what happens. In ML or Scheme, though, aside from the individual benefits described above, the simple fact that you''re telling the compiler what you want to achieve lets it optimize for you much more effectively.
This statement (from the article) is incorrect. Copy-paste isn''t the last step of template code generation. The compiler still has the opportunity to optimize said code as it sees fit. Template expression objects tend to produce code as optimal as you''re going to get with a particular set of operations.
Articles like this one tend to not present underlying assumptions upfront. In this case, the assumption is "Execution speed is less important than code expressivity/maintenance/beauty." While the upward trend of CPU speeds and memory size tends toward this assumption, it is not always valid in every domain. I wish these articles would acknowledge that when decrying certain features of C++.
