Forums Developers I hate templates

Argh - would someone mind building me a time machine so I can whack whoever put templates into C++ over the head with a large reference manual?

templates with polymorphism are my new enemies!

Failing the time machine option, any suggested resources for C++-a-phobes?

http://www.ocaml.org ?=)

Templates are one of the most powerful and useful features of C++. I don't know what I'd do without them...

If you want to learn all there is to know about templates, http://www.bookpool.com/.x/tgfq3rvis1/sm/0201734842

Hmm, as with everything else, we agree that templates are a really awesome idea. It's just that the C++ template system is so extremly borked that, well, it can be a bit confusing. Especially frustrating when there are plenty of other languages that can both do the stuff C++ templates do in a less ugly way, or have way easier to use and more sensible template systems of their own.

Oh well, those are always the shots.

Yes templates can get ugly, especially when using things like partial template specialization, and template member functions and things like that. However about other languages, I can't off the top of my head, think of other languages that do it any better way. Granted there are dozens if not more languages that I'm not familiar with, but I've played with C++, Java, Perl, and a little C#, to my knowledge, none of those languages have anything like templates. And if you know of a language that does, if it does it differently, then most likely it isn't as robust as a C++ template, there are tons of things you can do with templates that you can't do otherwise. I can't think of any languages that have the features that templates provide to C++.

VB 0WNZ J00!!!1

Ohh, look now, I'm a language nut, so I wouldn't know where to begin... all the languages you know belong squarely in the C family of languages. There are plenty of alternatives.

The classic example of templates are LISP macros, they are just as powerful as C++ templates, and thanks to LISPs extremly regular (some might say foolishly so) syntax they integrate extremly cleanly into LISP. You write LISP macros in, well, LISP. The same goes for the hygenic macros of Scheme, a LISP family member. OCaml is just yet another language that comes with a macro/template system, Camlp4, http://caml.inria.fr/camlp4/. I've heard cool things about Dylan macros. Rebol has a powerful syntax extending mechanism. All of these work within the target language.

Many languages, Ada, Eiffel, Haskell, and the ML family of languages (of which OCaml is one) provide (slightly varying forms of) generics or parametric polymorphism. This provides a very common part of C++ template functionality (based on STL usage), type generic code, in much cleaner ways. In the ML family type genericity is actually the default. Java will have genericity by 1.5, gone will be all the up/down casts to the container classes.

Other languages, such as Prolog, have such an powerful notion of operator overloading and definition that many syntactical tricks can be played with this alone. Haskell has the same kind of power but it also has lazy semantics which alleviate the need for templates as syntactic trickery quite a bit. Smalltalk avoid the need for much macro trickery by being dynamically typed and having anonymous code block that are real closures.



LISP macro intro: http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html
Scheme dito: http://www.cs.utexas.edu/users/wilson/schintro/schintro_128.html#SEC180
Camlp4: http://caml.inria.fr/camlp4/
Dylan: http://www.gwydiondylan.org/drm/drm_76.htm#HEADING76-0
Random research: http://portal.acm.org/citation.cfm?id=155105&jmp=indexterms&dl=portal&dl=ACM

Well of course things like LISP and Prolog have that kind of stuff, but I wasn't considering those languages simply because, most people don't use them for general purpose programming. The only time I've ever encountered LISP and Prolog was when doing AI coding. Along the same lines, FORTRAN has things that could be used in such a way as well, but again FORTRAN is more for scientific programming, not general usage. Ada, well I forgot Ada, you are indeed correct about that.

One thing about C++ templates, from talking to people, the ISO C++ committee is working on fixing some of the ugliness, the super fun std::list<std::pair<int,char> > (space required if using multiple levels of templates) is scheduled to be fixed, and I'm sure other things will evolve as well. C++ is an ever expanding and rapidly evolving language. I'm sure as time goes on the syntax will be a little less cumbersome and easier to understand.

LISP is indeed a 'real language' used for 'real programming'. Comercially successful does not equal 'real'. Not that LISP hasn't ever been comerially successful (http://www.paulgraham.com/).

I must say I have severe doubts about C++ and it's template ever becoming anything approaching 'easy' or 'pretty'. It's just too grotesquely complicated at this point that I have much hope it will recover. Programming languages are a form of communication and C++ makes that communication so much harder than it really should be, programming really is hard enough anyways. A primary design goal of C++ was that you don't pay in performance for features you don't use. It has mostly succeded with this. But you certainly do pay in cognitive load, the ammount of stuff you need to be aware of to correctly utilize operator overloading is astounding.

But I disgress, you might have noticed I'm not much of a C++ fan and that I tend to lash out at it whenever I get the chance. I really don't hate it that much, I just think that it's overused by a few 100% (there are projects using it for good reasons) and it makes me sad that so many people equate C++ (or maybe Java) and 'real programming'.

I sorta agree. I'm glad most universities are switching to Java as the intro language. When doing, for example, binary trees in C++ you spend so much time worrying about making sure your pointers stay ok that you are never really spending time thinking about the tree algorithms. Since Java doesn't have pointers, you don't have to worry about that. But I still say knowing C++ is good. Because C++ can get very ugly and very complex, the way I see it is, if you can do C++, you can do any language, as long as you take the time to learn its syntax.

But, in addition to C++ having the no performance hit for stuff you don't use, C++ also trys to minimize the performance hit for things you do use. There is no doubt that a program written in C++ will out perform the same program written in Java. Things such as garbage collection take CPU time. C++ might be more difficult because you have to manage the memory yourself, but if you are writing a program where speed is important, C++ is probably a better option.

personally, I would prefer to start in the reverse order to what most uni courses do now.

Start with C/C++ ... get the basics down solid in an extremely confusing language using lots of obscure pointers and meaningless varible names/function names

Then, when everyone has dropped outta the course bar the two or three coffee addicts who managed to make it thru, put them on easy sailing with Java.

I hated getting everything right in java, which took a little bit of effort and going 'wheewwwww'... only to find people now want me to write wrapper functions for malloc or something else nasty.... oh sure it'll sound simple and be simple but its daunting atm.

ta for the resources - i'm sitting in my other C course atm avoiding work - 36 hours no sleep + flu & no food doesn't make great coding.

At our university we started with Java, the intro to C++ was removed from the course for our year, and then we had to directly access the video card and parrallel port with C++. Now that was fun (good thing the code from previous years students was still on the HD)

I think we can agree that we sorta agree at this point, but have slightly different outlooks on the problem =) I'll just be annoying and mark a couple of your words:

"There is no doubt that a program written in C++ will out perform the same program written in Java."
Actually, this is not _strictly_ true. Not in a real sense, and not necessarily in a technical sense either. In the real sense it's because real programs has to be made by real people. Real people have real difficulties with the real (:-P) hard work of getting things just so in C++. They might (very realisticly) end up with a less optimal solution in C++ because it was easier to get right. In a technical sense there is some neat technology in a Java VMs that do under some sets of circumstances allow them to be faster than the corresponding C++ code. This has to do with the fact that the real time compilers these VMs use are able to gather and use run-time statistics about the running program and thus specialize the running code. Most often this is more than offset by the added overhead of Java's dynamic behavior, but for certain task this theoretical advantage of run time information actually transforms into faster code. This advantage could get more important as compiler tech get more advanced.


"Things such as garbage collection take CPU time."
But does it always take more time than doing manual garbage collection? In C++ people often resort to reference counting (smart pointers) when doing more compilcated stuff. It's not really hard to show that reference counting has worse amortized behavior than a copying collector. The same can often be shown for any manual (piecemal, techniques like memory arenas offset this) memory management. Now, for (soft and hard) real time applications, such as games, amortized behavior might not be the most important differentiator. Manual memory management has more predictable performace characteristics. The Great Computer Language Shootout (http://www.bagley.org/~doug/shootout/) has plenty of examples where garbage collected languages beat out for example C++. (I'll make no claims that this site is scientifically valid.)

I'm wordy, am I not?=)

Well what I meant with Java's garbage collection is it's "every object is a 'pointer'" idea. Meaning:

String b = "asdf";
b = "1234";

In that instance, what actually happens is, a new String has actually been instantiated ("1234"), and the old string ("asdf") has to be garbage collected. In C++, that isn't what happens. C++ will realize that the string b already has 4 bytes of memory allocated to it, so rather than allocating a new 4 bytes, it simply overwrites "asdf" with "1234" where as, in Java it actually deletes "asdf" (releases it to the OS) and then allocates "1234". Like I said though, both languages have their strengths and weaknesses. Anyone who uses C++ to try and make a 100% portable program would be crazy, where as using Java would be very reasonable.