Thread: C Instead of C++

Originally Posted by Zach L.

This is a silly argument!
Besides, we all know COBOL is the superior language.

Bring back Logo and my turtle! :P Wait,someone did!!!

ed: Hmmm, I think I'll tackle an advanced 3d fps engine with logo now that I found an emulator... Quake 14 anyone?

Originally Posted by Prelude

>I imagine it would be more difficult to write a C++ compiler than a C one.
No, not really. A C++ compiler requires more work than a C compiler because C++ is a larger language, but the hard stuff is present in both.

Actually, C++ is an incredibly complex language, evidenced by the fact that to this day, there's perhaps one fully compliant compiler. (Comeau C++ is, I think, fully compliant.)

Mostly due to templates, of course.

You, sir, have absolutely no idea.

They can be really powerful if used well (not many people do use them really well, though). Besides, the idea of template meta-programming is really cool.

Originally Posted by Krak

Templates suck, though.

A simple function to prove the opposite :

Code:

template <typename Type>
void foo(Type num1, Type num2)
{
	Type num3 = num1 + num2;

	cout << "Result : " << num3 << endl;
}

can sum doubles and ints correctly

>>A simple function to prove the opposite :
Looks to me like you could do the same thing with a macro...

Why on earth would you use a macro for that?
- You can't specialize macros like you can templates.
- If you end up with a bug in your macro, it could be very hard to figure out.
- You lose type-safety (which will result in those cryptic errors).
- You can't specify default parameters for macros.
To name a few.

Macros have there place, but should be used judiciously, especially if you want your code to be robist.

It's hard to imagine a difficult-to-find bug that would stem from a simple macro like this one. And there are no specializations in this case. And there are no default parameters here. And type-safety is a small issue here, unless you're worried that someone will try adding two different types (gee, who cares.. unless you're worried about roundoff problems, which shouldn't happen unless you're an idiot). Anyway, it'll also prevent you from summing doubles and floats, ints and shorts, etc.

What I mean is, although the templated function here will offer benefits, it has its drawbacks too (most notably unwanted type-safety and extra typing) and therefore it doesn't really 'prove' the usefulness of templates. Most people will take one look at it and write it off. And, if you give it two template arguments to avoid compatible-but-different type clashes, then you'll eliminate any type-safety you had.

IMO, templates are primarily useful for abstracting constructs that you wouldn't want to have to retype, i.e. complex classes that you want made generic.

>> And there are no specializations in this case. <<
Concatenating two C-strings? That seems like it might be a reasonable specialization. You are also excluding user (or library) defined data types that one might want to work with (and might require specializations).

The issuing of double/float and int/short, etc could be readily taken care of by casting the smaller to the larger... which is what you probably want to be doing anyway. At any rate, consider this small example as why it might be a bad idea:

Code:

#include <iostream>

#define ADD(num1, num2) \
   std::cout << "Result : " << num1 + num2 << std::endl;

int main( )
{
   int x = 4;
   int y = 2;
   ADD(x, y << 1);
   return 0;
}

Certainly, the fix in this case is trivial, but it is an example of how very small errors can creep in, even in the simplest constructs. And it still won't work with C-strings.

>> Most people will take one look at it and write it off. <<
I'm not sure where you are drawing this conclusion from. Most of the programmers I've worked with tend to avoid macros of this type, and strongly favor other solutions.

>> And, if you give it two template arguments to avoid compatible-but-different type clashes, then you'll eliminate any type-safety you had. <<
Not entirely. Type information is kept, and can be used appropriately.

>>Concatenating two C-strings? That seems like it might be a reasonable specialization.
Perhaps, but it would hardly be a safe operation given the arguments passed to the function (no size parameter) unless the programmer knew for certain in advance that the second string would fit entirely inside the first - which is unlikely, given the widely generic nature of the function. If C++ strings were used, both would succeed anyway.

>>The issuing of double/float and int/short, etc could be readily taken care of by casting the smaller to the larger...
Touché.

Most of the programmers I've worked with tend to avoid macros of this type, and strongly favor other solutions.

Yes, as would I; but IMO it would be nearly as easy to just eliminate the function completely and code in the cout statement and addition manually. Perhaps even save a CPU cycle or two.

>>Type information is kept, and can be used appropriately.

Code:

template <typename T1, typename T2>
void sum(T1 a, T2 b)
{  std::cout << (a + b);  }

#define SUM(a,b) {std::cout << ((a) + (b));}

struct Foobar {} foob;
...

sum("abcd", 1234);
SUM("abcd", 1234);
...

sum(4.5, foob);
SUM(4.5, foob);

In the first example, both give the same (wrong) output; in the second, they both give:

error C2677: binary '+' : no global operator found which takes type 'Foobar' (or there is no acceptable conversion)

The template function's error adds:

see reference to function template instantiation 'void sum<double,Foobar>(T1,T2)' being compiled

I suppose that argues in favour of the templated function, since the error gives more info, but the same information (or the important information) could readily have been deduced from the first error message anyway, especially since double-clicking the error (in MSVC) points you to the exact line causing the problem.

Well, in this example, obviously, the solution is not to use a function or a macro, but simply type (a + b) where you need it. But, in the concatenation example I was talking about, notice that the original example function posted by Brain Cell creates a new object of the correct type; obviously, you'd make a new C-string of the appropriate size. Or, in my simpler example, since your just printing, the appearance of concatenation is easy to mimick, so the operator is not inherently unsafe (which is why the templated solution is good).

And, in your example, there will always be ways to break code if you try hard enough, but using macros generally makes it easier. But yes, I see your point, there is a way to get around some of the built in safety of the template method.

Cheers