Overloading Operators for User-Defined Types (NOT Classes!)

[Victor Bazarov]

[..]
To me, something like

struct Car
{
uint16 year;
char[32] color;
};

is not a "permanent" definition of a type but a temporary one.

Uh... I am f****ng speechless.

> That's
why,
to use it, you have to write

struct Car myCar;

instead of just

Car myCar;

What language are you using? I think you need to "unlearn" some C to be
considering C++.

To me, the typedef actually defines the type permanently - these other
things are temporary.

I am befuddled by this statement.

Semantics. But if everyone else looks at it that way, then, yeah, I'll
line up with them for the sake of communication.

Uh... OK... If everyone else says that charcoals are black, then I'll
just line up for the sake of communication... Hello-o-o!!!

[..]

 

[Victor Bazarov]

Like that, Victor? As if the separation of the two has historically
been clearly defined...

WTF are you talking about? C++ Standard _clearly_ refers to the other
document that defines the language that is *not* C99. To us, the standard
is the only _true_ source of definition of what *is* C++. <stdint.h> and
other new things in C99 _can_ find their way into the C++ language at some
point, but they are not there *now*. Is there something here you do not
understand?

V

 

[Pete Becker]

Randy wrote:




I am befuddled by this statement.

Oh, come on now: it's a poor choice of terms (temporary vs. permanent),
but it's a legitimate point. In C, struct, union, and enum names are
not, in themselves, the names of types. In addition to the name you have
to say struct, union, or enum. Using a typedef creates a first-class
name: nothing further needed.

 

[Randy Yates]

Oh, come on now: it's a poor choice of terms (temporary
vs. permanent), but it's a legitimate point. In C, struct, union, and
enum names are not, in themselves, the names of types. In addition to
the name you have to say struct, union, or enum. Using a typedef
creates a first-class name: nothing further needed.

Thank you, Pete.

The problem Victor et al. in this group have was identified
2000 years ago: "Knowledge puffs up..."
--
% Randy Yates % "I met someone who looks alot like you,
%% Fuquay-Varina, NC % she does the things you do,
%%% 919-577-9882 % but she is an IBM."
%%%% <[email protected]> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

 

[Victor Bazarov]

Thank you, Pete.

The problem Victor et al. in this group have was identified
2000 years ago: "Knowledge puffs up..."

Doesn't the same source tell us not to throw pearls before swines?

 

[Randy]

Thanks!

--Randy

 

[Randy]

Hi M,

This looks like a truly wonderful thing except for
the restriction of no explicit enumeration
initializers. I need that for my enumerations.

The slight inefficiency that would occur if
we allowed these is what? Compile-time
inefficiency or run-time inefficiency? I
would be happy with the tradeoff.

I can guarantee 1-1-ness.

--Randy

 

[Randy]

That's true for C, but not for C++.

Wow. I didn't know that. Has this been true from the start,
or at least from circa 1996, when I first started programming
in C++?

Thanks for the education.

--Randy