By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,650 Members | 1,785 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,650 IT Pros & Developers. It's quick & easy.

Using structs in C++

P: n/a
I have the following struct:

typedef struct
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol) {
synonym = _synonym;
symbol = _symbol;
}
} Synonym ;

When I compile, I get the following warning:

: warning C4183: 'Synonym': missing return type; assumed to be a member
function returning 'int'

Can I not use constructors for structs?. I've seen this done many times
before ..

Is this bad practise ?
Should I worry about this warning ?
Further more, I want to populate this table with values. I want to
declare it as a static member in a class - something like:

Synonyms sym[] = {
....
};

I cant find anyway to do this (i.e. without compilation errors)
static Synonym syms[]

Jul 23 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a

Bit Byte wrote:
I have the following struct:

typedef struct
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol) {
synonym = _synonym;
symbol = _symbol;
}
} Synonym ;
You're stuck in C ville. Your definition should look more like:

struct Synonym
{
...
};

Jul 23 '06 #2

P: n/a
Bit Byte wrote:
I have the following struct:

typedef struct
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol) {
synonym = _synonym;
symbol = _symbol;
}
} Synonym ;

When I compile, I get the following warning:

: warning C4183: 'Synonym': missing return type; assumed to be a member
function returning 'int'

Can I not use constructors for structs?. I've seen this done many times
before ..
You can, but how shall the compiler know that

Synonym(string _synonym, string _symbol)

is meant to be the constructor: it does not match the name of the struct,
which is anonymous. Your typedef just declares Synonym to be an alias for
the unnamed struct. If you want to use a struct like a class, use one that
has a name:
struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol) {
synonym = _synonym;
symbol = _symbol;
}
};

BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

>
Is this bad practise ?
No. The legacy-typedef thing is.
Should I worry about this warning ?
Yes.
>

Further more, I want to populate this table with values. I want to
declare it as a static member in a class - something like:

Synonyms sym[] = {
....
};

I cant find anyway to do this (i.e. without compilation errors)
Your struct is not a POD. I think, there is no array-initializer syntax for
non-POD types.
Best

Kai-Uwe Bux
Jul 23 '06 #3

P: n/a

"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...
BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

>>
Is this bad practise ?

No. The legacy-typedef thing is.
As is the leading underscore in the variable names.
Jul 23 '06 #4

P: n/a
In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...
BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

>
Is this bad practise ?
No. The legacy-typedef thing is.

As is the leading underscore in the variable names.
Not in that particular context.
Jul 23 '06 #5

P: n/a

"Daniel T." <da******@earthlink.netwrote in message
news:da****************************@news.west.eart hlink.net...
In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
>"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...
BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

Is this bad practise ?

No. The legacy-typedef thing is.

As is the leading underscore in the variable names.

Not in that particular context.
Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.
Jul 23 '06 #6

P: n/a
Duane Hebert wrote:
>
"Daniel T." <da******@earthlink.netwrote in message
news:da****************************@news.west.eart hlink.net...
>In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
>>"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...

BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

Is this bad practise ?

No. The legacy-typedef thing is.

As is the leading underscore in the variable names.

Not in that particular context.

Variable names with leading underscores are reserved.
That is an over-simplification. Please refer to section [17.4.3.1.2] for the
details.
I wasn't aware that there are any conditions where they are allowed.
A name like _symbol is not unconditionally reserved. It is only reserved in
global namespace and ::std. Thus, as a parameter name, it is fine (although
it might shadow a name from global namespace).
Best

Kai-Uwe Bux
Jul 23 '06 #7

P: n/a
In article <5p*****************@weber.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
"Daniel T." <da******@earthlink.netwrote in message
news:da****************************@news.west.eart hlink.net...
In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...

BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};



Is this bad practise ?

No. The legacy-typedef thing is.

As is the leading underscore in the variable names.
Not in that particular context.

Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.
They are only reserved in the global namespace.
Jul 23 '06 #8

P: n/a

"Daniel T." <da******@earthlink.netwrote in message
news:da****************************@news.west.eart hlink.net...
>Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.

They are only reserved in the global namespace.
Ok.
Jul 23 '06 #9

P: n/a
>>>As is the leading underscore in the variable names.
Not in that particular context.
Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.

They are only reserved in the global namespace.
Not quite. A leading underscore followed by a capital is reserved
implementation-wide, as a leading double underscore (or any identifier
with a double underscore anywhere).
Jul 23 '06 #10

P: n/a
In article <PT*******************@newssvr27.news.prodigy.net> ,
red floyd <no*****@here.dudewrote:
>>As is the leading underscore in the variable names.
Not in that particular context.
Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.
They are only reserved in the global namespace.

Not quite. A leading underscore followed by a capital is reserved
implementation-wide, as a leading double underscore (or any identifier
with a double underscore anywhere).
The context though was a leading underscore followed by a lower-case
letter.
Jul 24 '06 #11

P: n/a

Daniel T. wrote:
In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...
BTW: you may want to prefer initialization:
>
struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};
>
>
>>
>Is this bad practise ?
>
No. The legacy-typedef thing is.
As is the leading underscore in the variable names.

Not in that particular context.
It may be ok as far as the language is concerned but imho it is still
bad practice. It is too easy to forget the particulars of when you can
vs. cannot use the underscore as first character in a name. Easier
just to never use it.

Jul 24 '06 #12

P: n/a

Noah Roberts wrote:
It may be ok as far as the language is concerned but imho it is still
bad practice. It is too easy to forget the particulars of when you can
vs. cannot use the underscore as first character in a name. Easier
just to never use it.
I seem to recall Herb Sutter in some book that was a collection of
"guru of the week" articles, suggesting that a trailing underscore
should be used in cases where the class member name was effectively the
same as the parameter name... Thus avoiding any implementation issues
and still making the mapping obvious.
Jon

Jul 24 '06 #13

P: n/a

Jon Clements wrote:
Noah Roberts wrote:
It may be ok as far as the language is concerned but imho it is still
bad practice. It is too easy to forget the particulars of when you can
vs. cannot use the underscore as first character in a name. Easier
just to never use it.

I seem to recall Herb Sutter in some book that was a collection of
"guru of the week" articles, suggesting that a trailing underscore
should be used in cases where the class member name was effectively the
same as the parameter name... Thus avoiding any implementation issues
and still making the mapping obvious.
Yeah, I'm yet to be convinced that is necissary.

Jul 24 '06 #14

P: n/a

"Daniel T." <da******@earthlink.netskrev i meddelandet
news:da****************************@news.west.eart hlink.net...
In article <5p*****************@weber.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:
>"Daniel T." <da******@earthlink.netwrote in message
news:da****************************@news.west.ear thlink.net...
In article <cG*****************@wagner.videotron.net>,
"Duane Hebert" <sp**@flarn2.comwrote:

"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ea**********@murdoch.acc.Virginia.EDU...

BTW: you may want to prefer initialization:

struct Synonym
{
string symbol;
string synonym;
Synonym(string _synonym, string _symbol)
: symbol ( _symbol )
, synonym ( _synonym )
{}
};

Is this bad practise ?

No. The legacy-typedef thing is.

As is the leading underscore in the variable names.

Not in that particular context.

Variable names with leading underscores are
reserved. I wasn't aware that there are
any conditions where they are allowed.

They are only reserved in the global namespace.
But as these names are reserved for gobal names, it is confusing to
also use them for local names. That makes it a bad practice.
Bo Persson

Jul 24 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.