| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 20:30 UTC (Wed) by mathstuf (subscriber, #69389)In reply to: Day: GNOME OS by nix Parent article: Day: GNOME OS
It's not a compatibility with C issue, but it happens because C++ tried to be fully C compatible. If you're doing C casts in a template or something, it acts differently based on whether the template type is POD or not. If C++ had just said "we don't support C casts" this wouldn't be an issue. Plus, if you do rely on C casts for some (C++ POD) struct for some reason, you need to document the struct that it needs to stay a POD struct.
I really would have liked 'implicit' to be the keyword rather than 'explicit' as well, but alas…
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 23:01 UTC (Wed) by nix (subscriber, #2304) [Link]
I think everybody agrees with you on that last point (and perhaps similarly for 'virtual', though changing that to 'nonvirtual' would violate the 'you don't pay for what you don't use' principle, so perhaps not), but such is the backward-compatibility burden...
Day: GNOME OS Posted Aug 8, 2012 23:47 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Not sure I feel the same about virtual because of the "only pay for what you use" principle. Another thing: something like a 'delayed const' (similar to 'final' in Java IINM) so that you can modify a variable and then 'constify' it so that it doesn't change after that point (something the compiler could enforce rather than assignment to a const& and relying on people to not use the pre-const& variable after).
Day: GNOME OS Posted Aug 10, 2012 7:49 UTC (Fri) by nix (subscriber, #2304) [Link]
The 'delayed const' sounds like a finer-grained 'mutable'.
(But don't mention Java. Java's lack of constness is *awful*. More than once I have introduced horrible bugs because I accidentally modified a hash key due to the silent aliasing and lack of const of java.util.Map -- meanwhile such bugs never ever happen in the STL, not due to its nifty space-age genericity, but simply because its data structures copy the types handed into them, and won't give you something back that shouldn't be modified without a const on it. For that matter I have written data structures in poor old crude C with the same 'always copy, use const' rules as the STL, and *they* never suffered from this either.)
Day: GNOME OS Posted Aug 10, 2012 8:10 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> But don't mention Java. Java's lack of constness is *awful*.
Yes, that's one of the very few features that I truly miss in Java. There are workarounds like defensive copies and immutable wrappers but they're no fun.
Day: GNOME OS Posted Aug 10, 2012 17:42 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Also typedefs. I hated using Strings for everything and 5 parameters all of String to Android APIs means having to look up what the order is. At least the ordering is consistent where I used it (unlike, e.g., PHP)
Day: GNOME OS Posted Aug 10, 2012 10:57 UTC (Fri) by jwakely (subscriber, #60262) [Link] If C++ hadn't supported C casts (or had used a FFI for C interop, as you suggested above) it would never have achieved the success it enjoys today, which only happened by building on C's popularity and success. C compatibility is sometimes a millstone around the neck of C++ now, but without it this discussion probably wouldn't even be happening.Without supporting C-style casts you couldn't write something as simple as this and have it be valid in both C and C++: int* p = (int*)malloc(n*sizeof(int));It's the right design for a C-style cast to invoke a user-defined conversion if one exists, for the reasons nix gives. Why would you want to use C-style casts in templates anyway? Code in templates doesn't need to be C-compatible. You can't cast between arbitrary POD types anyway, in C or C++. Can you give an example that shows what you mean?
Day: GNOME OS Posted Aug 10, 2012 11:09 UTC (Fri) by hummassa (subscriber, #307) [Link]
You can't c-cast from a POD type to another, but you can c-cast from a pointer-to-any-type to another (even if you have to cast to void* in the middle).
Day: GNOME OS Posted Aug 10, 2012 11:18 UTC (Fri) by jwakely (subscriber, #60262) [Link]
Was mathstuf's statement "it acts differently based on whether the template type is POD or not" talking about casting pointers?
Day: GNOME OS Posted Aug 10, 2012 14:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
You can always do:
>int *p = reinterpret_cast<int*>(malloc(n*sizeof(int))
Day: GNOME OS Posted Aug 10, 2012 15:51 UTC (Fri) by jwakely (subscriber, #60262) [Link]
How would that be valid C?
Day: GNOME OS Posted Aug 10, 2012 16:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
It's not, and that's the point. C++ could have avoided lots of warts caused by C-compatibility without losing in functionality.
|
|||||||||||||