Gabriel Sechan wrote: > The type tells you what class of data you have. The name tells you what > instance of that data it will hold. BAM! Everything you need to know about > the data in one beautiful, elegant line. Give me a series of lines like > that, and I can deduce your algorithms without looking at them. > The issue is that:
auto foo = new LongArduousType(...) or perhaps even (as Cobra does it): foo = new LongArduousType(...) Essentially conveys the same information in a much terser form, and there is a huge value in that; not the least of which is ease of reading/verifying code. Can you catch the syntax error below?: LongArduousType* foo = new LongArdousType(...); Most people miss it, and that's with a relatively short type name. What's worse is that sometimes there is actual importance to the differences in the type names. I think the argument has merit for languages like Java and C#, where this idiom is very common (an unfortunate byproduct of embracing C++ style syntax while simultaneously encouraging, or in Java's case, requiring that instances of user defined types be allocated on the heap). In C++, the idiom is actually pretty rare. Usually you either a) aren't allocating on the heap b) aren't assigning the pointer to a variable of exactly the same type, c) aren't directly invoking "new" or d) you are immediately returning the type, so you don't store it in a local variable. > Note: to get this absolutely right, use of typedefs is a must. One of those reasons why I still shake my head when I look at Java's lack of typedefs (and C#'s pseudo typedef through "using" is only marginally acceptable). > Int should only be used for variables that actually count. Oh, if *only* this were only an issue for types with such short names as "int". ;-) --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
