OSNews

C++ does NOT have nice syntax and it's semantics are even worse. Java is nice, C# is a little nicer, but neither compiles very well to native code
While I agree C++'s syntax could be a lot better, I very much disagree with your assertion that C++'s semantics are bad. When used properly they are extremely powerful. For example, neither of them have an alternative for RAII (Resource Acquisition Is Initialization). Efficient & correct managing of resources is greatly eased by this pattern. Nor do they have a decent look-up mechanism for functions (there are plenty of things better left a function than a method). Or an alternative for templates (the STL containers are a blessing to work with). Saying its semantics are bad is nonsense: they are different. Different is not bad, as long as you use the right tool for the job.

Not necessarily. Macros provide for a way to transform text into other text, what's bad is the usage of macros that some people do.

With macros you could do this, in C++:

synchronized(object)
{
// Atomic operations here
}

Just like in java, and it would be totally legal C++, provided the macro synchronized expanded to something like this:

#define synchronized(o) for((o).Lock(); (o).isLocked(); (o).unLock())

Where o would be an object of a class exposing the Lock/isLocked/unLock methods. If a class inherited from a, say, synchronizable class implementing those methods, you would be able to do

someclass::somemethod()
{
synchronized(*this)
{
// bla bla bla
}
}


Which would be the equivalent of a synchronized method in the Java language.



You can have range checking in C++, you just need to either implement it in a class of your own or use some of the already existing classes.



You can have managed memory handling in C++ as well.

Well, I admit, you can't decapitate a for loop with an inline function. But you also can't do this:

#define BAD_MACRO(x) if(x) cout << "Are macros bad?" << endl;

if(true) BAD_MACRO(might_be_zero);
else cout << "Macros are bad!" << endl;

Macros can change the way we think about truth.

Use inline functions in place of macros. If you need to inline something that isn't a function, you're doing something wrong. What's so bad about this?:

o.Lock();
// stuff
o.unLock();

That's the way C++ works, plus you avoid the unnecessary isLocked() call. Should C++ have multithreading primitives? Probably, but that's another issue.

Yes, I know you can extend C++ in all sorts of ways. But a lot of these hacks are workarounds for missing language features. You shouldn't need a special class to have a bounds-checked array. This should be an opt-out feature.

Edited 2007-08-13 22:08

... and where would the .Lock() method come from? c++.lang.Object? (sorry, couldn't resist :-)

Macros mean that language is not full-featured and many things can not be done with language itself. Using macros is stupid.

synchronized(object)
{
// Atomic operations here
}

Just like in java, and it would be totally legal C++, provided the macro synchronized expanded to something like this:

#define synchronized(o) for((o).Lock(); (o).isLocked(); (o).unLock())


That "synchronized" macro will only work if you have non-throwing code synchronized. Otherwise you'll end up with a lock that will stay locked forever.

In C++ you will probably want to use something like scoped locking.

You'll find an example of how that is done here:
http://en.wikipedia.org/wiki/Singleton_pattern

The MutexLocker class replaces your macro and does a better job.
In it's simplest version it looks something like this:

class MutexLocker
{
public:
MutexLocker(Mutex& pm): m(pm) { m.lock(); }
~MutexLocker() { m.unlock(); }
private:
Mutex& m;
};

In C++ there are actually very few times I feel the need to use macros. Macros create more problems than they fix in my opinion.

It is amazing you a synchronize keyword, which is a REALLY simply concept in say Java, or C# and created a discussion.

Now imagine writing application code. The C# and Java person can focus on actually getting the problem done. Whereas the C++ developer will be arguing with another C++ on how to write a bleeden lock statement.

Yeah I am SOOOOO glad I ran from C++...

Edited 2007-08-14 09:37

You can have range checking in C++, you just need to either implement it in a class of your own or use some of the already existing classes.

Range-checking (memory safety in general) is useless as an added feature. It's something that really needs to be in the guts of the system, used by not just your code, but everything under your code.

The cost of validity-checking is zero compared to good (defensively programmed) C++ code, which does it manually anyway. It's small even compared to bad code that blindly assumes it is passed correct parameters.

Anatomy of a check (in a magnitude-squared example):


double mag_squared(vector vec) {
double sum = 0.0;
double t0, t1;
for(int i = 0; i less_than vec.length; ++i) {
if(i greater_equal vec.length()) throw_error();
t0 = vec[i];
if(i greater_equal vec.length()) throw_error();
t1 = vec[i];
sum += (t0 * t1);
}

return sum;
}

This is the canonical, naively-inserted check, in pretty much the worst case (tight loop). It looks pretty bad, doubling the code inside the loop. This canonical description also shows all the reasons why checks are actually really cheap.

1) Range analysis can easily show that the induction variable (i) can never be greater than the length of the vector, making the checks completely unnecessary.

2) Redundency analysis can easily show that the second check is made redundent by the first check. This is obvious in this particular case, but happens in code where valies are reused. Type checks in particular, are easily removed by redundency analysis.

3) Even if you can't get rid of the checks, it's not so bad. It's easy to prove that the length of the vector doesn't change, so it can be loaded into a register outside the loop. Inside the loop, the checks are a simple compare and and perfectly-predictable conditional jump. On a modern load/store-limited CPU, there are almost always idle integer units available to execute these ops, and as a result they're almost free.

You can have managed memory handling in C++ as well.

See above rant on range-checking.

Edited 2007-08-14 21:47

Pointers are useful (although not always necessary)

You have GOT to be kidding me. This REEKS of someone who doesn't really know how to use pointers. Pointers is what it's all about.