Quote:

Quote:

Quote: Original post by Hodgman
what are you on about with C++ not having type safety?

Would you really call a language that lets you cast pointers back and forth at will type safe?

Uh, yes. C++ has strong type safety, but also gives you mechanisms to circumvent this system if you need to. Some of these mechanisms still check for invalid type conversions to an extent (static_cast) while others hand over trust completely (reinterpret_cast, C). It largely prevents type errors, and when it doesn't prevent them it still discourages them - the one flaw here is that C-style syntax can still be used instead of the rightfully-ugly reinterpret_cast syntax.

Simply adding the mechanism for circumvention doesn't remove the rest of they type system -- you may as well argue that C# is a buggy language because you can *choose* to access a null reference.

Obviously, there are various levels of type safety, and indeed an actually safe type system wouldn't be appropriate for C++. For example, having a type safe language while still allowing pointer arithmetic is not possible, and in the case of C++, pointers simply win the day without argument. For the record, I do consider the fact that dereferencing a null reference is possible in C# as unsafe (though most definitely not buggy.) Note, however, I'm not saying that any and all unsafety is always bad. Languages are different, that's just the way it is.

Quote:

Quote:

Quote: Oh FFS, are you done with your petty Ad Hominems yet?

I don't think that word means what you think it means. Why are you getting this upset over a friggin' language?

He knows what it means -- you made a personal attack against his character by implying that he's arguing against you simply because he "thinks C++ is leet" -- attacking the person not the argument. Now on top of that you're attacking his vocabulary for no reason. FFS indeed.

I didn't think implying a somewhat excessive liking for a particular technology would rouse that strong feelings; I'm not shy about the fact that I like Haskell more than what might be strictly rational. Anyone claiming to be completely objective and impartial about programming languages would be lying. I guess the wording was unfortunate though.

Quote:

Quote: That's why "language X doesn't have feature Y so it's less powerful than language Z which has that feature" is such a stupid line of reasoning.

Ok... but no one said that. Stop being belligerent.

Actually, yes:

Quote: One could argue that the competitors to C++ are not languages which "stay out of the way". They have, for example, no multiple inheritance or operator overloading not through a technical limitation but exactly because they want to limit the power of the user.

(My emphasis.)

EDIT: it's interesting to note that questioning C++ as the One True Language while essentially agreeing with everyone else about its usefulnes has lead to a rating drop 5x the size of the worst I ever got from participating in any inflamed religious or political debate. I guess it's a good thing the Middle East isn't run by programmers or we'd be in the middle of WWIII by now. [grin]

[Edited by - Valderman on June 3, 2010 7:03:27 AM]

Quote: Original post by Valderman
EDIT: it's interesting to note that questioning C++ as the One True Language while essentially agreeing with everyone else about its usefulnes has lead to a rating drop

Everyone that you've been replying to has been calling it a niche language as well (not the One True Language), except Katie, who simply said that they find it's competitors annoying to use and arbitrarily limited.

Maybe you got rated down for daring to question peoples xenophobic beliefs in the other lounge thread? ;)

(For the record you're still +/- 0 rated here :P)

Quote: Original post by Hodgman

Quote: Original post by Valderman
EDIT: it's interesting to note that questioning C++ as the One True Language while essentially agreeing with everyone else about its usefulnes has lead to a rating drop

Everyone that you've been replying to has been calling it a niche language as well (not the One True Language), except Katie, who simply said that they find it's competitors annoying to use and arbitrarily limited.

Maybe you got rated down for daring to question peoples xenophobic beliefs in the other lounge thread? ;)

(For the record you're still +/- 0 rated here :P)

Might be; I tend to forget that people in another time zone will probably read and react while I'm not looking. There also seems to be an inverse correlation between number of comments and number of up-/downratings; if someone annoys you you either rate or comment, but rarely both, it seems.

But on topic, saying that "other languages" are arbitrarily limited is just being closed-minded. (Yes, I know it's not you saying it, just trying to get the thread back on topic. ;) Why can't I have pattern matching, tail recursion, garbage collection or type inference in C++? After all, those are also "arbitrary," as opposed to technical, constraints that "limit the power of the user." To me, all of those are far more important than multiple inheritance or operator overloading.

Quote: Original post by Valderman
For example, having a type safe language while still allowing pointer arithmetic is not possible

Sure it is. STL iterators are an example of that.

Pointer arithmetic is just a way to iterate across arrays. Problems come from reinterpreting memory addresses to cast them into types. And even that can be made safe to a reasonable degree, just requires different memory model.

A huge class of problems in C and C++ comes from equating pointers with arrays, but pointers and pointer arithmetic as technique is not problematic or cause for loss of typing.

Quote: Original post by Antheus

Quote: Original post by Valderman
For example, having a type safe language while still allowing pointer arithmetic is not possible

Sure it is. STL iterators are an example of that.

Pointer arithmetic is just a way to iterate across arrays. Problems come from reinterpreting memory addresses to cast them into types. And even that can be made safe to a reasonable degree, just requires different memory model.

A huge class of problems in C and C++ comes from equating pointers with arrays, but pointers and pointer arithmetic as technique is not problematic or cause for loss of typing.

How do you guarantee that whatever (ptr + x) ends up pointing to is actually of the type ptr is supposed to point to?

Quote: Original post by ValdermanWhy can't I have pattern matching

You can, with templates.

Quote: tail recursion

You can, if your compiler supports it. Nothing in the language prevents it, AFAIK.

Quote: garbage collection

You can; although it's not a core part of the language, it gives you everything you need to implement it. The same can't be said about languages missing operator overloading or pointer arithmetic.

Quote: or type inference

You can, but not until C++0x is released.

Quote: Original post by Valderman
How do you guarantee that whatever (ptr + x) ends up pointing to is actually of the type ptr is supposed to point to?

Foo array[200];Foo * ptr = &array[0]; // needs to be taken from arrayptr++; // okptr+=200; // throws exception

Requires checked arrays and pointers may only be taken as indices into array. Go's arrays, for example, use slices for this purpose.

But this has nothing to do with typing, it's just the ambiguity between pointers and arrays in C and C++ along with undefined memory model.

And as before, std::advance() is how this can be done using most collections.

Quote: Original post by Hnefi

Quote: Original post by ValdermanWhy can't I have pattern matching

You can, with templates.

How do you propose I do the following with templates? I don't think we mean the same thing when we're talking about pattern matching.

find k' (Tree k v l r)  | k > k' = find k' r  | k < k' = find k' l  | otherwise = Just vfind _ Nil = NothingaddOneIfItsThereOtherwiseZero k t = case find k t of  Just x -> x + 1  _      -> 0

Quote: tail recursion

Quote: You can, if your compiler supports it. Nothing in the language prevents it, AFAIK.

Tail calls aren't an optimization but a language feature, and are therefore useless unless the language guarantees that they will compile into loops.

Quote:

Quote: garbage collection

You can; although it's not a core part of the language, it gives you everything you need to implement it. The same can't be said about languages missing operator overloading or pointer arithmetic.

So basically, every Turing complete language has every feature because you can implement it yourself?

Quote:

Quote: or type inference

You can, but not until C++0x is released.

That's nice, I didn't know about that. Is said type inference guaranteed to always infer the most general type?

You're completely missing the point though; languages are different, that's just the way it is. If a language had every single feature there is, it'd be a useless hodgepodge where you couldn't even use the entire language if you wanted to write code that anyone could read and understand.

Quote: Original post by Antheus

Quote: Original post by Valderman
How do you guarantee that whatever (ptr + x) ends up pointing to is actually of the type ptr is supposed to point to?

Foo array[200];Foo * ptr = &array[0]; // needs to be taken from arrayptr++; // okptr+=200; // throws exception

Requires checked arrays and pointers may only be taken as indices into array. Go's arrays, for example, use slices for this purpose.

But this has nothing to do with typing, it's just the ambiguity between pointers and arrays in C and C++ along with undefined memory model.

And as before, std::advance() is how this can be done using most collections.

Uh, yes, of course pointer arithmetic is type safe if you only use them as indices into arrays bounds checked arrays. I might not have been clear enough; what I'm saying is that performing arithmetic on arbitrary pointers (which is what pointer arithmetic in C++ is) can never be type safe. Sorry for causing misunderstandings.

Quote: Original post by Valderman
Uh, yes, of course pointer arithmetic is type safe if you only use them as indices into arrays bounds checked arrays. I might not have been clear enough; what I'm saying is that performing arithmetic on arbitrary pointers (which is what pointer arithmetic in C++ is) can never be type safe. Sorry for causing misunderstandings.

Pointer arithmetic doesn't make sense on non-array types. That is a deliberate design choice made by language.

Foo * f;Foo * g = f+5

is type safe. But it may result in undefined behavior if memory pointed to by g hasn't been properly initialized as instance of f. If Bar is incompatible type with Foo, then

Bar * h = f+5;

will fail at compile time.

Typing system is fine, unless deliberately subverted by user. Given:

Foo * x;char * y = x;

requires an explicit reinterpret_cast, which tells compiler to turn off type checking. There is a very long chapter on what all is undefined when doing that, and what kinds of platform-specific gotchas there are. It's just a system's language, so that comes with territory.

Given:

Foo * x;Foo * g = x+5;

is also fine, remains typed, and it's a way of saying - x points to array of Foos. If it doesn't, then it's just an allocation problem.

Quote: Original post by Antheus

Quote: Original post by Valderman
Uh, yes, of course pointer arithmetic is type safe if you only use them as indices into arrays bounds checked arrays. I might not have been clear enough; what I'm saying is that performing arithmetic on arbitrary pointers (which is what pointer arithmetic in C++ is) can never be type safe. Sorry for causing misunderstandings.

Pointer arithmetic doesn't make sense on non-array types. That is a deliberate design choice made by language.

Foo * f;Foo * g = f+5

is type safe. But it may result in undefined behavior if memory pointed to by g hasn't been properly initialized as instance of f. If Bar is incompatible type with Foo, then

Bar * h = f+5;

will fail at compile time.

Typing system is fine, unless deliberately subverted by user. Given:

Foo * x;char * y = x;

requires an explicit reinterpret_cast, which tells compiler to turn off type checking. There is a very long chapter on what all is undefined when doing that, and what kinds of platform-specific gotchas there are. It's just a system's language, so that comes with territory.

Given:

Foo * x;Foo * g = x+5;

is also fine, remains typed, and it's a way of saying - x points to array of Foos. If it doesn't, then it's just an allocation problem.

I agree that it doesn't make sense, but the fact is that you can do it. I guess it all boils down to my opinion that it's far too easy to completely circumvent the type checker in C++.