3 ms·

C++ Streams & Typedefs: Be Charful

15 points by humbledrone 16y ago

joezydeco 16y ago
Wh-at the he-ck is up with the brea-ks in this art-icle?
- humbledrone 16y ago
  Are you using Chrome? If so, you might check the bug report at http://code.google.com/p/chromium/issues/detail?id=65941 http://code.google.com/p/chromium/issues/detail?id=65941.
  - joezydeco 16y ago
    Wow, that's a browser bug? Thanks. (And yes, Chrome 80552)
anonymous246 16y ago
IIRC, Pascal had the opposite problem. Typedefs were considered distinct even if the underlying type was the same.
- humbledrone 16y ago
  It would be really handy if C++ supported both its existing typedef behavior (aliasing) and the Pascal kind (distinct copy). I wonder if any other strongly typed languages (e.g. Haskell) support both kinds of behavior.
  - dododo 16y ago
    haskell does support it. c style: type Foo = Int pascal style: newtype Foo = Foo Int
makecheck 16y ago
I don't think focusing on a particular case is helpful, because what they're really talking about is the entire C++ type system. This could happen in any case where types are converted: calling functions, assigning variables...whether or not any printing or typedefs or chars are involved. You could see surprising behavior anywhere, and arguably in places where it is a lot harder to debug. The "explicit" keyword for constructors addresses part of the problem, but not all of it. The real issue is one of programming style. Personally, I feel this is a case where C++ programmers should think more like C programmers, and not be offended by having to give functions different names, or otherwise making things more distinct when the behavior is totally different anyway. If I have to call handleChar() and handleInt() with an "if" statement, instead of relying on one of the 12 overloads of handleAnything() to perform magic, I think that is fine because it will one day save me hours of debugging. Notice that printf("%c", c) has pretty damned clear behavior, and it requires someone to say the equally-clear printf("%d", (int)c) to get a number when they want a number; this might not be C++-like, but it's the right way to think about the problem.
- Someone 16y ago
  On the other hand, to make things really interesting, one could do typedef signed char int8_t; to 'solve' the problem that char and int8_t are the same type. That also fixes a portability problem: AFAIK, there is no guarantee that 'char' is signed.
- nuxi 16y ago
  > Notice that printf("%c", c) has pretty damned clear behavior, and it requires someone to say the equally-clear printf("%d", (int)c) to get a number when they want a number; It does have a clear behaviour, but it's possibly different from what you think. From your examples I'm assuming "c" is a char variable - since you're casting it to int in the second example - which is then (incorrectly) passed to printf with "%c". Both %c and %d require an integer parameter, so "c" should be an integer to begin with (thus no need for a cast). Nitpicking, I know, but such code can lead to many subtle bugs.
  - makecheck 16y ago

15 points by humbledrone 16y ago

joezydeco 16y ago

Wh-at the he-ck is up with the brea-ks in this art-icle?

humbledrone 16y ago
Are you using Chrome? If so, you might check the bug report at http://code.google.com/p/chromium/issues/detail?id=65941 http://code.google.com/p/chromium/issues/detail?id=65941.
- joezydeco 16y ago
  Wow, that's a browser bug? Thanks. (And yes, Chrome 80552)

anonymous246 16y ago

IIRC, Pascal had the opposite problem. Typedefs were considered distinct even if the underlying type was the same.

humbledrone 16y ago
It would be really handy if C++ supported both its existing typedef behavior (aliasing) and the Pascal kind (distinct copy). I wonder if any other strongly typed languages (e.g. Haskell) support both kinds of behavior.
- dododo 16y ago
  haskell does support it. c style: type Foo = Int pascal style: newtype Foo = Foo Int

makecheck 16y ago

I don't think focusing on a particular case is helpful, because what they're really talking about is the entire C++ type system. This could happen in any case where types are converted: calling functions, assigning variables...whether or not any printing or typedefs or chars are involved. You could see surprising behavior anywhere, and arguably in places where it is a lot harder to debug. The "explicit" keyword for constructors addresses part of the problem, but not all of it. The real issue is one of programming style. Personally, I feel this is a case where C++ programmers should think more like C programmers, and not be offended by having to give functions different names, or otherwise making things more distinct when the behavior is totally different anyway. If I have to call handleChar() and handleInt() with an "if" statement, instead of relying on one of the 12 overloads of handleAnything() to perform magic, I think that is fine because it will one day save me hours of debugging. Notice that printf("%c", c) has pretty damned clear behavior, and it requires someone to say the equally-clear printf("%d", (int)c) to get a number when they want a number; this might not be C++-like, but it's the right way to think about the problem.

Someone 16y ago
On the other hand, to make things really interesting, one could do typedef signed char int8_t; to 'solve' the problem that char and int8_t are the same type. That also fixes a portability problem: AFAIK, there is no guarantee that 'char' is signed.
nuxi 16y ago
> Notice that printf("%c", c) has pretty damned clear behavior, and it requires someone to say the equally-clear printf("%d", (int)c) to get a number when they want a number; It does have a clear behaviour, but it's possibly different from what you think. From your examples I'm assuming "c" is a char variable - since you're casting it to int in the second example - which is then (incorrectly) passed to printf with "%c". Both %c and %d require an integer parameter, so "c" should be an integer to begin with (thus no need for a cast). Nitpicking, I know, but such code can lead to many subtle bugs.
- makecheck 16y ago