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

[Randy]

Is there a way to override operators for user-defined types
(e.g., typedefs) rather than class types?

I'm trying to override the extractor operator for a user-defined
enumeration type but getting no joy. For example,

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

istream& operator>> (istream& is, WEEK& x)
{
x = blah blah;
return is;
}

--RY

[Victor Bazarov]

Randy wrote:

Is there a way to override operators for user-defined types
(e.g., typedefs) rather than class types?
'typedefs' are _not_ user-defined types.
I'm trying to override the extractor operator for a user-defined
enumeration type but getting no joy. For example,

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

istream& operator>> (istream& is, WEEK& x)
{
x = blah blah;
return is;
}

FAQ 5.8. Aside from 'blah blah', the code should be fine.

V

[Randy]

#include <string>
#include <iostream>
#include <sstream>
using namespace::std
#include <stdint.h>

typedef enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;

#define MAXCHARS_IN_ALINE 256

istream& operator>> (istream& is, WEEK& x)
{
char aline[MAXCHARS_IN_ALINE];

is.getline(aline, MAXCHARS_IN_ALINE;

if (((string)aline).find("SUN", 0) != string::npos)
{
x = SUN;
return is;
}

if (((string)aline).find("MON", 0) != string::npos)
{
x = MON;
return is;
}

if (((string)aline).find("TUE", 0) != string::npos)
{
x = TUE;
return is;
}

if (((string)aline).find("WED", 0) != string::npos)
{
x = WED;
return is;
}

if (((string)aline).find("THU", 0) != string::npos)
{
x = THU;
return is;
}

if (((string)aline).find("FRI", 0) != string::npos)
{
x = FRI;
return is;
}

if (((string)aline).find("SAT", 0) != string::npos)
{
x = SAT;
return is;
}

x = MON;
return is;
}

int main(int argc, char **argv)
{
string strTest;
WEEK week;

strTest = "THU";
istringstream(strTest) >> week;

cout << (uint16_t)week;
return 0;
}

yields the following slurry of errors:

make -f over.mak TARGET=native PLATFORM=linux
DSPROOT_DIR=/home/yates/modetest/
over.mak:101: no file name for `include'
Building Autodependencies (over) for Application over
over.mak:101: no file name for `include'
Building Component (over) for Application over
/home/yates/modetest/host/app/modetest/over.cpp:7: error: expected `;'
before "typedef"
/home/yates/modetest/host/app/modetest/over.cpp: In function
`std::istream& operator>>(std::istream&, WEEK&)':
/home/yates/modetest/host/app/modetest/over.cpp:15: error: expected `)'
before ';' token
/home/yates/modetest/host/app/modetest/over.cpp: In function `int
main(int, char**)':
/home/yates/modetest/host/app/modetest/over.cpp:69: error: no match for
'operator>>' in 'istringstream(((const std::basic_string<char,
std::char_traits<char>, std::allocator<char> >&)((const
std::basic_string<char, std::char_traits<char>, std::allocator<char>

*)(&strTest))), _S_in) >> week'

/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:87:
note: candidates are: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT,
_Traits>::operator>>(std::basic_istream<_CharT,
_Traits>&(*)(std::basic_istream<_CharT, _Traits>&)) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:93:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(std::basic_ios<_CharT,
_Traits>&(*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:102:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT,
_Traits>::operator>>(std::ios_base&(*)(std::ios_ba se&)) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:111:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(bool&) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:133:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(short int&) [with
_CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:164:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(short unsigned int&)
[with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:186:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(int&) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:217:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(unsigned int&) [with
_CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:239:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(long int&) [with _CharT
= char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:261:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(long unsigned int&)
[with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:284:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(long long int&) [with
_CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:306:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(long long unsigned
int&) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:329:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(float&) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:351:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(double&) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:373:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(long double&) [with
_CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:395:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(void*&) [with _CharT =
char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/istream.tcc:417:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT,
_Traits>::operator>>(std::basic_streambuf<_CharT, _Traits>*) [with
_CharT = char, _Traits = std::char_traits<char>]
/home/yates/modetest/host/app/modetest/over.cpp:12: note:
std::istream& operator>>(std::istream&, WEEK&)
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/istream:692:
note: std::basic_istream<char, _Traits>&
std::operator>>(std::basic_istream<char, _Traits>&, signed char*) [with
_Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/istream:687:
note: std::basic_istream<char, _Traits>&
std::operator>>(std::basic_istream<char, _Traits>&, unsigned char*)
[with _Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/istream:651:
note: std::basic_istream<char, _Traits>&
std::operator>>(std::basic_istream<char, _Traits>&, signed char&) [with
_Traits = std::char_traits<char>]
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/istream:646:
note: std::basic_istream<char, _Traits>&
std::operator>>(std::basic_istream<char, _Traits>&, unsigned char&)
[with _Traits = std::char_traits<char>]
make: *** [/home/yates/modetest/host/app/modetest/nativelinux/over.o]
Error 1

Compilation exited abnormally with code 2 at Wed Jan 4 16:27:23

[Randy]

> 'typedefs' are _not_ user-defined types.

Why not?!!! They define types that aren't built-in, so they're
user.

--RY

[Jay Nabonne]

On Wed, 04 Jan 2006 13:28:29 -0800, Randy wrote:

#include <string>
#include <iostream>
#include <sstream>
using namespace::std
using namespace::std;
The error message says it all (missing ; before typedef):
/home/yates/modetest/host/app/modetest/over.cpp:7: error: expected `;'
before "typedef"

- Jay

[Jay Nabonne]

On Wed, 04 Jan 2006 13:35:24 -0800, Randy wrote:

'typedefs' are _not_ user-defined types.

Why not?!!! They define types that aren't built-in, so they're
user.

--RY

Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;

I think the confusion came about because you defined an enum and typedef'd
it at the same time.

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

declares an unnamed enum and then creates an alias for it called WEEK. All
you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

- Jay

[Victor Bazarov]

Randy wrote:

#include <string>
#include <iostream>
#include <sstream>
using namespace::std ^^^^^^^^^^^^^^^^^^^^
Semicolon is missing at the end of this line.
#include <stdint.h>
There is no such standard header.

typedef enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;

#define MAXCHARS_IN_ALINE 256

istream& operator>> (istream& is, WEEK& x)
{
char aline[MAXCHARS_IN_ALINE];

is.getline(aline, MAXCHARS_IN_ALINE; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A closing parenthesis is missing in this line
[...]
istringstream(strTest) >> week;
This is not going to work. A reference to non-const object cannot be
bound to a temporary. You need a named object (not temporary).
[...]

After fixing syntax errors and removing "(uint16_t)", your code compiled
and executed fine under VC++ v7.1 and VC++ v8, and MIPSpro 7.4 compilers.
I was unable to test with Comeau online since the server is not responding
but I am sure it would also compile it.

V

[mlimber]

Randy wrote:

Is there a way to override operators for user-defined types
(e.g., typedefs) rather than class types?

I'm trying to override the extractor operator for a user-defined
enumeration type but getting no joy. For example,

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

istream& operator>> (istream& is, WEEK& x)
{
x = blah blah;
return is;
}

You might be interested in this article:

http://www.cuj.com/documents/s=8470/cujboost0306besser/

Cheers! --M

[Randy]

> Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;
OK, so typedef doesn't ALWAYS define a new type. However, it can.
I think the confusion came about because you defined an enum and typedef'd
it at the same time.

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

declares an unnamed enum and then creates an alias for it called WEEK. All
you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

Here you are mistaken. If I replace the typedef with a simple enum, I
get

over.cpp:12: error: `WEEK' is not a type

You need to typedef it if you want to declare variables of that type.

--RY

[Pete Becker]

Randy wrote:

Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;

OK, so typedef doesn't ALWAYS define a new type. However, it can.

A typedef never defines a new type. It defines a synonym for an existing
type. Jay's discussion is correct:

I think the confusion came about because you defined an enum and typedef'd
it at the same time.

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

declares an unnamed enum and then creates an alias for it called WEEK. All
you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

Here you are mistaken. If I replace the typedef with a simple enum, I
get

over.cpp:12: error: `WEEK' is not a type

You need to typedef it if you want to declare variables of that type.

No, you don't. But since you didn't include the code for you "simple
enum" it's not possible for anyone to tell what triggered that error
message.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Jay Nabonne]

On Wed, 04 Jan 2006 14:03:51 -0800, Randy wrote:

Typedefs create aliases for other types. For example:
All
you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

Here you are mistaken. If I replace the typedef with a simple enum, I
get

over.cpp:12: error: `WEEK' is not a type

You need to typedef it if you want to declare variables of that type.

In C yes (which is why typedefs were so prevalent). That's no longer
the case in C++. This code compile fine using Visual C++:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

int main()
{
WEEK week = MON;
return 0;
}

- Jay

[Jay Nabonne]

On Wed, 04 Jan 2006 14:03:51 -0800, Randy wrote:

Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;

OK, so typedef doesn't ALWAYS define a new type. However, it can.

Oops. Missed the first part.

I would love to see a typedef that actually defines a type as opposed
to being an alias for one.

Even in your case, if you name the enum:

typedef enum week_t {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

WEEK is an alias for the enumeration week_t (or, in C, "enum week_t").

- Jay

[Randy]

> Randy wrote:

#include <string>
#include <iostream>
#include <sstream>
using namespace::std

^^^^^^^^^^^^^^^^^^^^
Semicolon is missing at the end of this line.

Right. Sorry about that.

#include <stdint.h>

There is no such standard header.

Yes there is - see ISO C 99.

typedef enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;

#define MAXCHARS_IN_ALINE 256

istream& operator>> (istream& is, WEEK& x)
{
char aline[MAXCHARS_IN_ALINE];

is.getline(aline, MAXCHARS_IN_ALINE;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A closing parenthesis is missing in this line

Correct. Sorry again. (I fixed all these after posting - I
didn't realize they were there at first.)

[...]

> istringstream(strTest) >> week;

This is not going to work. A reference to non-const object cannot be
bound to a temporary. You need a named object (not temporary).

OK, this seems to be the crux of the matter. I found that streaming
from cin works so it's not the overloaded operator.

Bear with me because I don't understand the meaning of your words. What
in "istringstream(strTest) >> week;" is non-const? What do you mean
by "You need a named object (not temporary)."?

> [...]

After fixing syntax errors and removing "(uint16_t)", your code compiled
and executed fine under VC++ v7.1 and VC++ v8, and MIPSpro 7.4 compilers.
I was unable to test with Comeau online since the server is not responding
but I am sure it would also compile it.

Thanks Victor. How did you fix the non-const blah blah above?

--RY

[Ben Pope]

Randy wrote:

Randy wrote:

#include <string>
#include <iostream>
#include <sstream>
using namespace::std

^^^^^^^^^^^^^^^^^^^^
Semicolon is missing at the end of this line.

Right. Sorry about that.

#include <stdint.h>

There is no such standard header.

Yes there is - see ISO C 99.

How is C99 relevant to C++?

<from a different "branch" of this thread>

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

declares an unnamed enum and then creates an alias for it called WEEK. All you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

Here you are mistaken. If I replace the typedef with a simple enum, I
get

over.cpp:12: error: `WEEK' is not a type

You need to typedef it if you want to declare variables of that type.

Perhaps you should be writing C++ code and using a C++ compiler.

Or if you want to use C, maybe you should go to some place where C is
relevant.
Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Victor Bazarov]

Randy wrote:

Randy wrote:

#include <string>
#include <iostream>
#include <sstream>
using namespace::std

^^^^^^^^^^^^^^^^^^^^
Semicolon is missing at the end of this line.

Right. Sorry about that.

#include <stdint.h>

There is no such standard header.

Yes there is - see ISO C 99.

Then you need to rewrite your program in C 99 and post to comp.lang.c.
C++ Standard only refers to C 90 at this point.

typedef enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;

#define MAXCHARS_IN_ALINE 256

istream& operator>> (istream& is, WEEK& x)
{
char aline[MAXCHARS_IN_ALINE];

is.getline(aline, MAXCHARS_IN_ALINE;

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A closing parenthesis is missing in this line

Correct. Sorry again. (I fixed all these after posting - I
didn't realize they were there at first.)

[...]

> istringstream(strTest) >> week;

This is not going to work. A reference to non-const object cannot be
bound to a temporary. You need a named object (not temporary).

OK, this seems to be the crux of the matter. I found that streaming
from cin works so it's not the overloaded operator.

Bear with me because I don't understand the meaning of your words. What
in "istringstream(strTest) >> week;" is non-const? What do you mean
by "You need a named object (not temporary)."?

> [...]

After fixing syntax errors and removing "(uint16_t)", your code compiled
and executed fine under VC++ v7.1 and VC++ v8, and MIPSpro 7.4 compilers.
I was unable to test with Comeau online since the server is not responding
but I am sure it would also compile it.

Thanks Victor. How did you fix the non-const blah blah above?

istringstream is(strTest); // named object (not a temporary)
is >> week;

V

[Randy]

> Randy wrote:

Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;

OK, so typedef doesn't ALWAYS define a new type. However, it can.

A typedef never defines a new type. It defines a synonym for an existing
type. Jay's discussion is correct:

OK. OK, OK! I'll relent. This does appear to be the viewpoint most
widely used
(it's in K&R). I guess I just never thought of it that way.

To me, something like

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

is not a "permanent" definition of a type but a temporary one. That's
why,
to use it, you have to write

struct Car myCar;

instead of just

Car myCar;

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

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

I think the confusion came about because you defined an enum and typedef'd
it at the same time.

typedef enum {SUN,MON,TUES,WED,THURS,FRI,SAT} WEEK;

declares an unnamed enum and then creates an alias for it called WEEK. All
you need is:

enum WEEK {SUN,MON,TUES,WED,THURS,FRI,SAT};

to define an enum called WEEK.

Here you are mistaken. If I replace the typedef with a simple enum, I
get

over.cpp:12: error: `WEEK' is not a type

You need to typedef it if you want to declare variables of that type.

No, you don't. But since you didn't include the code for you "simple
enum" it's not possible for anyone to tell what triggered that error
message.

You're right. I had written:

enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;

and gotten the previously-mentioned compiler error. If instead I write

enum WEEK {SUN,MON,TUE,WED,THU,FRI,SAT};

it compiles.

--RY

[JustBoo]

On Wed, 04 Jan 2006 22:23:11 GMT, Jay Nabonne
<ja*********@sonicNOSPAM.com> wrote:

I would love to see a typedef that actually defines a type as opposed
to being an alias for one.
- Jay

I'm aware of the thread title, but if you're going to create a new
type and not just alias an intrinsic...

I'll ask this as a question. Does the keyword " class " actually do
what Jay is asking?

Class design IS type design, right? :-)

"Why isn't phonetic spelled the way it sounds?"

[Ben Pope]

Randy wrote:

Randy wrote:

Typedefs create aliases for other types. For example:

typedef int BOOL;
typedef char* PCHAR;

OK, so typedef doesn't ALWAYS define a new type. However, it can.
A typedef never defines a new type. It defines a synonym for an existing
type. Jay's discussion is correct:

OK. OK, OK! I'll relent. This does appear to be the viewpoint most
widely used
(it's in K&R). I guess I just never thought of it that way.

To me, something like

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

is not a "permanent" definition of a type but a temporary one. That's
why,
to use it, you have to write

struct Car myCar;

instead of just

Car myCar;

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

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

Yeah, speaking the same language helps. Here, we speak C++ and English.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Randy]

> > Yes there is - see ISO C 99.

Then you need to rewrite your program in C 99 and post to comp.lang.c.
C++ Standard only refers to C 90 at this point.
Like that, Victor? As if the separation of the two has historically
been clearly defined...
istringstream is(strTest); // named object (not a temporary)
is >> week;

Thanks.

[Pete Becker]

Randy wrote:

to use it, you have to write

struct Car myCar;

instead of just

Car myCar;

You need to figure out which language you're programming in, and post to
the appropriate newsgroup. That's true for C, but not for C++. This is a
C++ newsgroup, and, if you're using iostreams, you're writing C++ code.

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

Semantics. But if everyone else looks at it that way, then, yeah, I'll
line up with them for the sake of communication.
It's more than semantics. It's deep meaning: names that refer to the
same type can be used interchangeably; names that refer to different
types cannot.


You're right. I had written:

enum {SUN,MON,TUE,WED,THU,FRI,SAT} WEEK;
That defines an object named WEEK whose type is an unnamed enumeration
whose enumerators are SUN, MON, etc.

and gotten the previously-mentioned compiler error. If instead I write

enum WEEK {SUN,MON,TUE,WED,THU,FRI,SAT};

it compiles.

Yup.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Victor Bazarov]

Randy wrote:

[..]
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]

Randy wrote:

Yes there is - see ISO C 99.

Then you need to rewrite your program in C 99 and post to comp.lang.c.
C++ Standard only refers to C 90 at this point.

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]

Victor Bazarov wrote:

Randy wrote:

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

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Randy Yates]

Pete Becker <pe********@acm.org> writes:

Victor Bazarov wrote:

Randy wrote:

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

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.

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."
%%%% <ya***@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

[Victor Bazarov]

Randy Yates wrote:

Pete Becker <pe********@acm.org> writes:

Victor Bazarov wrote:

Randy wrote:

To me, the typedef actually defines the type permanently - these
other things are temporary.
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.

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