Richard Cownie (tich@pobox.com) on 8/28/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/27/09 wrote:
>---------------------------
>
>>>Of course you could: you can do it with a union,
>>
>>Reading from a union member other than the last one you assigned to is unspecified.
>
>Really ? I think that's another example of the
>uselessness of standards.

It can't help it. All of those undefined and unspecified things are in there precisely because C and C++ are designed to allow the languages to be used to write code on a wide range of platforms without any "emulation" required, and some platforms don't support that particular operation.

They are "portable" in the sense that you can use them to write "native" code on any platform.

Languages like Java are portable in a completely different sense -- they allow you to write code for precisely one platform, and then require a sophisticated runtime to convert any real platform into that particular virtual platform. They can make any guarantees they damn well choose -- the only downside is that on some platforms it will be incredibly slow.

>Given that the layout of
>fields in structures is fully specified, there's
>hardly any wiggle room for the implementation ...

The amount of padding is not "fully specified", nor are the contents of pad bytes, so at the very least reading from a different union member to the one you last wrote could involve bytes that are undefined.

There is also no guarantee that the sequence of bits as seen by the union member you are attempting to read with represent a legal value for that member (what the C standard calls a "trap representation") and accessing it on some hardware may cause the program to terminate with an error message -- hence "undefined behaviour" in the standard. However, in this particular aspect, the behaviour is exactly as defined as using reinterpret_cast so it's neither better nor worse.

>>That shouln't even compile unless you use reinterpret_cast or a C-style cast,
>
>Well, a C-style cast is valid standard C++, and that's
>what I was thinking of.

It is, but my point was about the usefulness of reinterpret_cast and saying you could eliminate it by using a C-style cast defeats the purpose if the C-style case is a reinterpret_cast in that case.

The C++ style casts all represent distinct well-defined subsets of what the C-style cast can do -- the point being that a C-style cast can be any of them and sometimes you want to be explicit about what you're trying to do and get an error if you made a mistake. The C-style cast will always work. Because of that goal, if the C++ style casts didn't represent, between them, everything the C-style cast can do, then there'd still be instances that require you to fall back on the C-style cast and be once again exposed to all it's power; reinterpret_cast is required to encapsulate that particular aspect of the C-style cast's behaviour.

So when I say there are instances where reinterpret_cast is required even though they are very rare, that implies the reinterpret_cast behaviour of C-style casts is included in my observation.

>>And even then if you actually try to dereference the pointer to the type you want
>>the result can still be undefined if the type you want is anything other than [u]char.
>>(Think about what happens if the alignment restrictions on the type you want are more onerous than the source type.)
>
>Yes, but you can enforce sufficient alignment.

Then it's no longer a drop-in replacement, it requires extra work. If extra work isn't an obstacle then I can use memcpy() instead.

>And the
>fact that the result is undefined is sort of the *point*
>of reinterpret_cast<>, isn't it ?

My point was that you've added an extra layer of "undefinedness" unrelated to whether the reinterpret_cast itself would have been undefined or not.

Incidentally, you can perfectly legally use reinterpret_cast to store pointers in "large enough" integers (for serialisation, or for constructing a hash value for a hash container) so not every use of it results in undefined or unspecified behaviour.

>>Actually, that's one of the good things about exceptions, and goes to something
>>you said before -- better to have an error noticed immediately rather than silently
>>ignored.
>
>I don't know. Too many people use the presence of the
>exception mechanism as an excuse for failing to design
>an error-handling strategy - leading to the symptoms seen
>on Alto/Dorado.

Well, I can't comment about the number of people who get a false sense of security because exceptions are available, but it seems to me at least that they'd be exactly the same sort of people who would ignore error return codes. I can't imagine any false sense of security lasting very long if they're actually using exceptions.

Maybe force them to write Java for a while -- Java uses exceptions for even routine errors, so any notion that you can write code without worrying about errors because exceptions are used will be quickly dispelled.

>At the technical level, exceptions look
>like a good idea; it's when you look at the unintended
>consequences on typical systems that it gets ugly.

It seems to me that ignorance of the issues surrounding the use of exceptions is no reason to rule out a good idea. Education is the solution to that.

I'm more concerned about intrinsic problems that are discovered once something is used in real systems, like the overheads of managing checked exceptions, which no amount of education can fix.

Likewise, the intrinsic difficulty to managing errors well in a large system without exceptions was precisely the motivation for inventing exceptions in the first place. They are designed to make error management easier, not to make the problem go away entirely. As I said, education seems to be called for, not avoiding a tool because people have misconceptions about it.

>Always bear in mind that the majority of developers are
>not very good, because there's a constant inflow of
>new developers of varying intelligence and zero experience,
>and a constant outflow of very good developers getting
>"promoted" into management, while mediocre developers
>keep on writing code. And I've seen a lot of buggy code,
>but I don't think I've ever heard of anyone losing their
>job for writing buggy code ... Particular organizations
>avoid these traps by careful hiring and management, but
>the general picture is bleak.

The Peter Principle? This is why I think technical people who make good managers should be preferred over lawyers and accountants in technical companies -- when the manager is not equipped to judge the technical abilities of their subordinates, it's easy for the reward system to be distorted by the more "political" employees, leaving the really good workers feeling cheated and uninspired. It's also why I think that management positions should not be the only way of rewarding particularly good employees -- if someone is most valuable as a developer then keep rewarding them for that.

I'm speaking as someone who was a developer, then became R&D manager, and finally managing director, and who still writes a lot of code (preferring it to the administrative side, to be honest) and whose second-highest-paid employee in the company has no subordinates or management responsibility whatsoever.

I'd have serious reservations about the long-term competitiveness of a company that persists in hiring poor quality staff and vigorously implements the Peter Principle to ensure that the best staff get promoted away from their area of expertise. Implementing exception safety is probably the least of their problems.

>Really, it's fine that people are figuring out good
>design patterns and tricks like ScopeGuard. But imposing
>new constraints on old codebases is just not going to
>happen very often (unless it's done in ways that can
>be automated).

The approach we took was to do it one little bit at a time. We never went back through the entire codebase and rewrote it from scratch, but if we happened to be working on something then we would modify it if required. If we got caught by something then we would fix that problem. Gradually, over a period of several years, it got better. Adding uses of scopeguard or replacing all uses of FILE with stream objects implementing RAII makes your code just that little bit more robust and easier to maintain even if it doesn't fix the entire thing overnight.

Something as simple as telling programmers to start using the C++ equivalent that implements RAII instead of the C version will automatically have them writing more robust code without them even knowing it.