asking for an opinion from the collective wisdom here

[Devon Null]

I was simply wondering if this was a mal-formed class header:

#ifndef _items_h_
#define _items_h_

#include <iostream>
#include <string>
#include <vector>

using namespace std;

class Item
{
public:
Item( float weight = 0, bool set_can_equip = false, bool
set_can_attack = false, bool set_can_defend = false, bool set_can_drink
= false, bool set_can_eat = false, bool set_can_use = false, bool
set_is_consumable = false, bool set_is_magical = false );
//Below are the set and get functions for all variables in this
class
void set_weight( float weight ) { item_weight = weight; }
float get_weight() { return item_weight; }

void set_can_equip( bool set_can_equip ) { can_equip =
set_can_equip; }
bool get_can_equip() { return can_equip; }

void set_can_attack( bool set_can_attack ) { can_attack =
set_can_attack; }
bool get_can_attack() { return can_attack; }

void set_can_defend( bool set_can_defend ) { can_defend =
set_can_defend; }
bool get_can_defend() { return can_defend; }

void set_can_drink( bool set_can_drink ) { can_drink =
set_can_drink; }
bool get_can_drink() { return can_drink; }

void set_can_eat( bool set_can_eat ) { can_eat = set_can_eat; }
bool get_can_eat() { return can_eat; }

void set_can_use( bool set_can_use ) { can_use = set_can_use; }
bool get_can_use() { return can_use; }

void set_is_consumable( bool set_is_consumable ) { is_consumable
= set_is_consumable; }
bool get_is_consumable() { return is_consumable; }

void set_is_magical( bool set_is_magical ) { is_magical =
set_is_magical; }
bool get_is_magical() { return is_magical; }

void describe(); // simply returns description (see below)
void clear_describe(); // clears description
void add_describe( string line_to_add );
/*Line above checks to see if description is set to either
need_set or desc_cleared, and if so description.clear()
then push_back( line_to_add ), else just push_back( line_to_add)*/

private: // These are stats that will be set for every item created
string need_set; // description is initialized with this
string desc_cleared; // description will be set to this after it
has been cleared
vector<stringdescription; // This is to allow multi-line
descriptions
float item_weight; // These are pretty self explanatory I think
bool can_equip;
bool can_attack;
bool can_defend;
bool can_drink;
bool can_eat;
bool can_use;
bool is_consumable;
bool is_magical;
};

#endif

but as I read along I was confused over something. The above works just
fine, but I was also wondering should the constructor be this:

Item( float weight = 0, bool set_can_equip = false, bool set_can_attack
= false, bool set_can_defend = false, bool set_can_drink = false, bool
set_can_eat = false, bool set_can_use = false, bool set_is_consumable =
false, bool set_is_magical = false );

with a constructor body like this in the cpp file:

Item::Item( float weight, bool set_can_equip, bool set_can_attack, bool
set_can_defend, bool set_can_drink, bool set_can_eat, bool set_can_use )
{
item_weight = weight;
can_equip = set_can_equip;
can_attack = set_can_attack;
can_defend = set_can_defend;
can_drink = set_can_drink;
can_eat = set_can_eat;
can_use = set_can_use;
is_consumable = set_is_consumable;
is_magical = set_is_magical;
need_set = "You need to set a description here!\n";
desc_cleared = "The description has been cleared.\n";
description.clear();
description.push_back( need_set );
}

or this:

Item() : float weight( 0 ), bool can_equip( false ), bool can_attack(
false ), bool can_defend( false ), bool can_drink( false ), bool
can_eat( false ), bool can_use( false ), bool is_consumable( false ),
bool is_magical( false );

and lose the entire body of the constructor in the cpp file? I will need
to pass in parameters to override the defaults when I instantiate the
objects.

Question 1: Is this a mal-formed class header?
Question 2: Which should I use for the initialization list?

Thanks in advance.
DN
--
[there are no x's in my email]

I have the right to remain silent
(and should probably use it as much as possible)
Anything I type can and will be used against me
in a court of idiocy
I have the right to be wrong
(and probably am)
If I can not furnish my own wrongness
I'm sure someone will provide it for me.

[red floyd]

Devon Null wrote:

I was simply wondering if this was a mal-formed class header:

#ifndef _items_h_
#define _items_h_

Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

[Daniel T.]

Devon Null <th*************@xgmailx.comwrote:

I was wondering should the constructor be this:

Item( float weight = 0, bool set_can_equip = false, bool set_can_attack
= false, bool set_can_defend = false, bool set_can_drink = false, bool
set_can_eat = false, bool set_can_use = false, bool set_is_consumable =
false, bool set_is_magical = false );

with a constructor body like this in the cpp file:

Item::Item( float weight, bool set_can_equip, bool set_can_attack, bool
set_can_defend, bool set_can_drink, bool set_can_eat, bool set_can_use )
{
item_weight = weight;
can_equip = set_can_equip;
can_attack = set_can_attack;
can_defend = set_can_defend;
can_drink = set_can_drink;
can_eat = set_can_eat;
can_use = set_can_use;
is_consumable = set_is_consumable;
is_magical = set_is_magical;
need_set = "You need to set a description here!\n";
desc_cleared = "The description has been cleared.\n";
description.clear();
description.push_back( need_set );
}

or this:

Item() : float weight( 0 ), bool can_equip( false ), bool can_attack(
false ), bool can_defend( false ), bool can_drink( false ), bool
can_eat( false ), bool can_use( false ), bool is_consumable( false ),
bool is_magical( false );

and lose the entire body of the constructor in the cpp file? I will need
to pass in parameters to override the defaults when I instantiate the
objects.

You can't lose the entire body of the constructor. However to answer the
underlying question, you should use the no argument constructor and just
initialize all the variables.

Item::Item() :
weight( 0 ),
can_equip( false ),
can_attack( false ),
can_defend( false ),
can_drink( false ),
can_eat( false ),
can_use( false ),
is_consumable( false ),
is_magical( false )
{ }

At some point you will realize that your code is full of blocks that
check the various flags in this class and behave differently depending
on the setting of the flag. Then when you learn about polymorphism, you
will start writing better classes.

[terminator]

On Jun 3, 1:06 am, "Daniel T." <[e-mail]:

Devon Null <[e-mail]:

I was wondering should the constructor be this:

Item( float weight = 0, bool set_can_equip = false, bool set_can_attack
= false, bool set_can_defend = false, bool set_can_drink = false, bool
set_can_eat = false, bool set_can_use = false, bool set_is_consumable =
false, bool set_is_magical = false );

with a constructor body like this in the cpp file:

Item::Item( float weight, bool set_can_equip, bool set_can_attack, bool
set_can_defend, bool set_can_drink, bool set_can_eat, bool set_can_use )
{
item_weight = weight;
can_equip = set_can_equip;
can_attack = set_can_attack;
can_defend = set_can_defend;
can_drink = set_can_drink;
can_eat = set_can_eat;
can_use = set_can_use;
is_consumable = set_is_consumable;
is_magical = set_is_magical;
need_set = "You need to set a description here!\n";
desc_cleared = "The description has been cleared.\n";
description.clear();
description.push_back( need_set );
}

or this:

Item() : float weight( 0 ), bool can_equip( false ), bool can_attack(
false ), bool can_defend( false ), bool can_drink( false ), bool
can_eat( false ), bool can_use( false ), bool is_consumable( false ),
bool is_magical( false );

and lose the entire body of the constructor in the cpp file? I will need
to pass in parameters to override the defaults when I instantiate the
objects.

You can't lose the entire body of the constructor. However to answer the
underlying question, you should use the no argument constructor and just
initialize all the variables.

Item::Item() :
weight( 0 ),
can_equip( false ),
can_attack( false ),
can_defend( false ),
can_drink( false ),
can_eat( false ),
can_use( false ),
is_consumable( false ),
is_magical( false )
{ }

At some point you will realize that your code is full of blocks that
check the various flags in this class and behave differently depending
on the setting of the flag. Then when you learn about polymorphism, you
will start writing better classes.- Hide quoted text -

- Show quoted text -

both forms can be used for ctors but the later is better when const
data members exist and the former is needed when members have to be
assigned assciated values:

int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is called
twice which time expensive.*/
};

[terminator]

On Jun 2, 11:51 pm, red floyd <[e-mail]:

Devon Null wrote:

I was simply wondering if this was a mal-formed class header:

#ifndef _items_h_
#define _items_h_

Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

what is wrong with it?
This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

regards,
FM

[Jerry Coffin]

In article <11*********************@h2g2000hsg.googlegroups.c om>,
fa***********@gmail.com says...

On Jun 2, 11:51 pm, red floyd <[e-mail]:

Devon Null wrote:

I was simply wondering if this was a mal-formed class header:

#ifndef _items_h_
#define _items_h_

Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

what is wrong with it?
This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

As he already pointed out, what's wrong is the _name_ you've used. The
technique is perfectly legitimate and allowable, but the name you've
used is not. If you change to something like:

#ifndef ITEMS_H_INCLUDED
#define ITEMS_H_INLCUDED

you'll be fine, because this name does NOT have a leading underscore
like the one you used.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Robert Bauck Hamar]

terminator wrote:

On Jun 2, 11:51 pm, red floyd <[e-mail]:

>Devon Null wrote:

>>I was simply wondering if this was a mal-formed class header:
#ifndef _items_h_
#define _items_h_

Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

what is wrong with it?

_items_h_ starts with an underscore.

This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

Yes, but there are two rules:

1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.

Include guards are very handy, but name them properly.

--
rbh

[Daniel T.]

terminator <fa***********@gmail.comwrote:

both forms can be used for ctors but the later is better when const
data members exist and the former is needed when members have to be
assigned assciated values:

int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has shown that
they are necessary. For this specific case, if the function has no side
effects, I expect the compiler would be smart enough to cache the return
value for the second use.

[Pete Becker]

terminator wrote:

On Jun 2, 11:51 pm, red floyd <[e-mail]:

>Devon Null wrote:

>>I was simply wondering if this was a mal-formed class header:
#ifndef _items_h_
#define _items_h_

Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

what is wrong with it?
This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

It's not at all advanced. Every header should have include guards. The
problem it solves is repeating definitions at compile time, which
produces compile-time errors, not linker errors. The problem with this
particular example, as has been pointed out in several other messages,
is the name of the guard.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[terminator]

On Jun 3, 8:46 am, "Daniel T." <[e-mail]:

terminator <[e-mail]:

both forms can be used for ctors but the later is better when const
data members exist and the former is needed when members have to be
assigned assciated values:

int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has shown that
they are necessary. For this specific case, if the function has no side
effects, I expect the compiler would be smart enough to cache the return
value for the second use.- Hide quoted text -

- Show quoted text -

you pointed to the side effects ;that is exactly what I mean ,and
since there is no way for the compiler to guess the existance of such
side effects it must not censor your code-or cache the value as you
wrote.

regards

[terminator]

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:

terminator wrote:

On Jun 2, 11:51 pm, red floyd <[e-mail]:

Devon Null wrote:
I was simply wondering if this was a mal-formed class header:
#ifndef _items_h_
#define _items_h_
Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.

what is wrong with it?

_items_h_ starts with an underscore.

This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

Yes, but there are two rules:

1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.

Include guards are very handy, but name them properly.

--
rbh

header guards from mainstream libraries that I have faced , all have
underscored guards. In fact since gaurds are not intended to be used
more than a few times - in header related stuff only - , they are the
best candidates for dirty names .This way good names can be reserved
for more important things which are supposed to be introduced in
global namespace.

regards

[James Kanze]

On Jun 7, 2:53 pm, terminator <[e-mail]:

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:

terminator wrote:

On Jun 2, 11:51 pm, red floyd <[e-mail]:
>Devon Null wrote:
>>I was simply wondering if this was a mal-formed class header:
>>#ifndef _items_h_
>>#define _items_h_
>Yes, you are malformed right here. Per the Standard, any identifier
>with a leading underscore is reserved to the implementation in the
>global namespace. _items_h_ is in the global namespace.

what is wrong with it?

_items_h_ starts with an underscore.

This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.

Yes, but there are two rules:

1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.

Include guards are very handy, but name them properly.

header guards from mainstream libraries that I have faced , all have
underscored guards. In fact since gaurds are not intended to be used
more than a few times - in header related stuff only - , they are the
best candidates for dirty names .This way good names can be reserved
for more important things which are supposed to be introduced in
global namespace.

Unless the library is part of the implementation, such names are
illegal, and result in undefined behavior.

Many basic libraries (e.g. Posix) do consider themselves "part
of the implementation". Third party libraries which don't,
however, are in error if they use such names. Or maybe the
fact that they use such names is a signal that they do consider
themselves as an extention of the implementation. (At any rate,
I tend to consider things like the data base library as "part of
the implementation.")

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gavin Deane]

On 7 Jun, 13:53, terminator <[e-mail]:

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:

Yes, but there are two rules:
1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.

Include guards are very handy, but name them properly.

header guards from mainstream libraries that I have faced , all have
underscored guards. In fact since gaurds are not intended to be used
more than a few times - in header related stuff only - , they are the
best candidates for dirty names .This way good names can be reserved
for more important things which are supposed to be introduced in
global namespace.

The point is not whether the names are sufficiently dirty to avoid
name collisions. The point is that, unless these libraries are part of
the implementation, they are invading the "namespace" set aside by the
standard for the sole use of the implementation, and that is illegal.

Since include guards are #define'd macro names, the best way to avoid
name clashes between them and the rest of your code is whatever you
normally do to prevent macro names clashing with code. The most common
example I've seen is that macro names (including include guards) are
always ALL_CAPS and everything else is never ALL_CAPS, but any naming
convention that creates a separate "namespace" for macros is
sufficient (as long as it doesn't invade the implementation's
namespace).

And, of course, you can have naming conventions within that to protect
include guard names from other macros if you want. For example,
include guards always ending in _H and other macros never ending in
_H. But again, any naming convention works as long as it doesn't break
the two rules above.

Gavin Deane

[terminator]

On Jun 8, 11:12 am, James Kanze <[e-mail]:

On Jun 7, 2:53 pm, terminator <[e-mail]:

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:

terminator wrote:
On Jun 2, 11:51 pm, red floyd <[e-mail]:
Devon Null wrote:
>I was simply wondering if this was a mal-formed class header:
>#ifndef _items_h_
>#define _items_h_
Yes, you are malformed right here. Per the Standard, any identifier
with a leading underscore is reserved to the implementation in the
global namespace. _items_h_ is in the global namespace.
what is wrong with it?
_items_h_ starts with an underscore.
This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.
Yes, but there are two rules:
1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.
Include guards are very handy, but name them properly.

header guards from mainstream libraries that I have faced , all have
underscored guards. In fact since gaurds are not intended to be used
more than a few times - in header related stuff only - , they are the
best candidates for dirty names .This way good names can be reserved
for more important things which are supposed to be introduced in
global namespace.

Unless the library is part of the implementation, such names are
illegal, and result in undefined behavior.

Many basic libraries (e.g. Posix) do consider themselves "part
of the implementation". Third party libraries which don't,
however, are in error if they use such names. Or maybe the
fact that they use such names is a signal that they do consider
themselves as an extention of the implementation. (At any rate,
I tend to consider things like the data base library as "part of
the implementation.")

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]- Hide quoted text -

- Show quoted text -

please inform me of the disadvantages of having such form of
guards.These are possible combinations of legal characters ,why not to
device them?? are they reserved for none-portable issues only?

regards,
FM

[Gavin Deane]

On 9 Jun, 20:59, terminator <[e-mail]:

On Jun 8, 11:12 am, James Kanze <[e-mail]:

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:
Yes, but there are two rules:
1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.
Include guards are very handy, but name them properly.

<snip>

Unless the library is part of the implementation, such names are
illegal, and result in undefined behavior.

<snip>

please inform me of the disadvantages of having such form of
guards.These are possible combinations of legal characters ,why not to
device them?? are they reserved for none-portable issues only?

Please trim your posts to only include sufficient context to make the
post comprehensible. And please don't quote signatures, or the "quoted
text" garbage that Google inserts. Thanks.

Your answer is in the discussion above. Using names reserved to the
implementation results in undefined behaviour. That's it. That's all
the disadvantage you need. That statement alone should be sufficient
reason for you to avoid such names.

comp.lang.c++ discusses *what* is in the C++ standard. As far as
*what* goes, that's all there is to it. However, you are asking *why*
- and there is generally a reason for these things. One could
speculate in this case that the rules above give implementors a
separate "namespace" they can use. If they only use the names that are
reserved to them, and you never use the names that are reserved to
them, you can be confident that you won't suffer name clashes with the
implementation. If one didn't want to speculate, comp.std.c++ is a
more topical place to discuss *why* the C++ standard is the way it is.

Gavin Deane

[James Kanze]

On Jun 9, 9:59 pm, terminator <[e-mail]:

On Jun 8, 11:12 am, James Kanze <[e-mail]:

On Jun 7, 2:53 pm, terminator <[e-mail]:

On Jun 3, 3:23 am, Robert Bauck Hamar <[e-mail]:
terminator wrote:
On Jun 2, 11:51 pm, red floyd <[e-mail]:
>Devon Null wrote:
>>I was simply wondering if this was a mal-formed class header:
>>#ifndef _items_h_
>>#define _items_h_
>Yes, you are malformed right here. Per the Standard, any identifier
>with a leading underscore is reserved to the implementation in the
>global namespace. _items_h_ is in the global namespace.
what is wrong with it?
_items_h_ starts with an underscore.
This is an avanced technique used in proffesional libraries to prevent
probable linker errors generated by repetition.It also decreases
compile time.
Yes, but there are two rules:
1. Never use a name starting with an underscore in the global namespace.
2. Never use a name starting with an underscore followed by a capital
letter, or a name containing __ in _any_ namespace.
Include guards are very handy, but name them properly.
header guards from mainstream libraries that I have faced , all have
underscored guards. In fact since gaurds are not intended to be used
more than a few times - in header related stuff only - , they are the
best candidates for dirty names .This way good names can be reserved
for more important things which are supposed to be introduced in
global namespace.

Unless the library is part of the implementation, such names are
illegal, and result in undefined behavior.

Many basic libraries (e.g. Posix) do consider themselves "part
of the implementation". Third party libraries which don't,
however, are in error if they use such names. Or maybe the
fact that they use such names is a signal that they do consider
themselves as an extention of the implementation. (At any rate,
I tend to consider things like the data base library as "part of
the implementation.")

please inform me of the disadvantages of having such form of
guards.

The disadvantage is that they are illegal, and using them causes
your code to have undefined behavior.

These are possible combinations of legal characters ,why not to
device them?? are they reserved for none-portable issues only?

The reason the standard bans them is precisely to give the
implememters a set of names they can use, without risk of
conflicts with your code. Thus, for example, some library
header might contain something like:

class SomeStandardClass
{
private:
int _items_h_
} ;

Now what happens if you include that library header in your
header?

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Daniel T.]

On Jun 7, 8:46 am, terminator <[e-mail]:

On Jun 3, 8:46 am, "Daniel T." <[e-mail]:

int f(int,int);//A big function
>
class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is
called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has
shown that they are necessary. For this specific case, if the
function has no side effects, I expect the compiler would be
smart enough to cache the return value for the second use.-

you pointed to the side effects ;that is exactly what I mean ,and
since there is no way for the compiler to guess the existance of
such side effects it must not censor your code-or cache the value
as you wrote.

I disagree that "there is no way for the compiler to guess the
existance of such side effects". If the function deals with only its
parameters and local variables, there is no way for it to *have* side
effects.

[terminator]

On Jun 11, 5:06 pm, "Daniel T." <[e-mail]:

On Jun 7, 8:46 am, terminator <[e-mail]:

int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is
called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has
shown that they are necessary. For this specific case, if the
function has no side effects, I expect the compiler would be
smart enough to cache the return value for the second use.-

you pointed to the side effects ;that is exactly what I mean ,and
since there is no way for the compiler to guess the existance of
such side effects it must not censor your code-or cache the value
as you wrote.

I disagree that "there is no way for the compiler to guess the
existance of such side effects". If the function deals with only its
parameters and local variables, there is no way for it to *have* side
effects

I have commented 'f' to be a large function whose value cannot be
deduced before excution specifically 'f' can be a random value
generating function.I would delare 'f' as 'inline' if it was a simple
value-forcastable function;this would motivate the compiler for
optimization. Moreover what I wrote is not a micro-
optimization.consider these two cases:
1. 'f' is an input function
2. 'f' is a random-return function
the return of 'f' will be different on every call in these cases.

regards,
FM

[terminator]

On Jun 11, 1:41 am, James Kanze <[e-mail]:

>
The disadvantage is that they are illegal, and using them causes
your code to have undefined behavior.

Illegal? You keep repeating this sentence.Please define illegal; I
think that must mean something syntactically wrong, but if you mean
none-std then I would humblly ask why is it none-std?

By the way thanks to everyone I have found that underscored names are
supposed to be used by implementors and others including third-party
libraries had better keep off them(it is not a must).

regards,
FM.

[Daniel T.]

terminator <fa***********@gmail.comwrote:

On Jun 11, 5:06 pm, "Daniel T." <[e-mail]:

On Jun 7, 8:46 am, terminator <[e-mail]:

int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is
called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has
shown that they are necessary. For this specific case, if the
function has no side effects, I expect the compiler would be
smart enough to cache the return value for the second use.-

you pointed to the side effects ;that is exactly what I mean ,and
since there is no way for the compiler to guess the existance of
such side effects it must not censor your code-or cache the value
as you wrote.

I disagree that "there is no way for the compiler to guess the
existance of such side effects". If the function deals with only its
parameters and local variables, there is no way for it to *have* side
effects

I have commented 'f' to be a large function whose value cannot be
deduced before excution specifically 'f' can be a random value
generating function.I would delare 'f' as 'inline' if it was a simple
value-forcastable function;this would motivate the compiler for
optimization. Moreover what I wrote is not a micro-
optimization.consider these two cases:
1. 'f' is an input function
2. 'f' is a random-return function
the return of 'f' will be different on every call in these cases.

In that case, calling f more than once will probably change the behavior
of the program and we are in a whole different world. Your initial
comment that you are doing it because it is "time expensive" is then in
error, your not calling it twice because that would be an error
regardless of the time it takes.

If that is the case, then you could do something like this:

class A {
const int m;
int n;
public:
A( int i, int j ): m( f( i, j ) ), n( m ) { }
};

Based on your earlier post, you are under the impression that assigning
in the body of the constructor is required under certain circumstances,
I don't think that is the case.

[Gavin Deane]

On 12 Jun, 22:13, terminator <[e-mail]:

On Jun 11, 1:41 am, James Kanze <[e-mail]:

The disadvantage is that they are illegal, and using them causes
your code to have undefined behavior.

Illegal? You keep repeating this sentence.Please define illegal; I
think that must mean something syntactically wrong,

No. It's not a syntax error to use a name reserved to the
implementation. It is a violation of one of the (many) rules in the C+
+ standard that tell you what you are and are not allowed to write in
a C++ program.

>From the standard:

<quote>
17.4.3.1.2
Certain sets of names and function signatures are always reserved to
the implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter is reserved to the
implementation for any use.
- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
</quote>

And just before that in 17.4.3.1/3
<quote>
If the program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by this clause, the
behavior is undefined.
</quote>

The "explitly allowed" part is talking about template specialisations
within namespace std - nothing to do with what we are discussing here.
So for the purposes of this discussion you can assume 17.4.3.1/3 says
"If the program declares or defines a name in a context where it is
reserved the behavior is undefined."

Is the meaning of any of that unclear to you?

but if you mean
none-std then I would humblly ask why is it none-std?

There are two parts to the answer to that question:
1. This rule provides a "namespace" that implementors use and you
avoid, thereby ensuring no name clashes between the implementation and
your code.
2. Further in-depth discussion of *why* the standard is the way it is
belongs in comp.std.c++. In this forum it is sufficient to say "Those
are the rules and you have to stick to them".

You have had both those parts of the answer before in this thread. Did
you not read them?

By the way thanks to everyone I have found that underscored names are
supposed to be used by implementors and others including third-party
libraries had better keep off them(it is not a must).

I have not seen anyone tell you here that "it is not a must". Whoever
told you it is not a must has mislead you. The standard is extremely
clear. If your code uses reserved names, the behaviour of your program
is undefined. Do you know what that means?

Gavin Deane

[James Kanze]

On Jun 12, 11:13 pm, terminator <[e-mail]:

On Jun 11, 1:41 am, James Kanze <[e-mail]:

The disadvantage is that they are illegal, and using them causes
your code to have undefined behavior.

Illegal? You keep repeating this sentence.Please define illegal;

Something that is forbidden by the language definition.

I think that must mean something syntactically wrong,

Or semantically wrong. The standard says that you must do this,
or may not do that, and that defines what is legal and what is
illegal. Depending on the type of error, the standard *may*
require a diagnostic, but there are a lot of cases where it
doesn't; where it basically says that whatever happens is the
programmer's fault.

but if you mean none-std then I would humblly ask why is it
none-std?

Because the language definition says so.

By the way thanks to everyone I have found that underscored names are
supposed to be used by implementors and others including third-party
libraries had better keep off them(it is not a must).

That's the motivation for the rule. But the rule is part of the
language definition: §2.10/2:

In addition, some identifiers are reserved for use by
C++ implementations and standard libraries (17.4.3.1.2)
and shall not be used otherwise; no diagnostic is
required.

and §17.4.3.1.2:

Certain sets of names and function signatures are always
reserved to the implementation:

-- Each name that contains a double underscore __ or
begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for
any use.

-- Each name that begins with an underscore is reserved
to the implementation for use as a name in the
global namespace.

Note in particular, in the first citation, the words "shall
not be used otherwise", and "no diagnostic is required".
"Shall not" means exactly that---it is forbidden, and "no
diagnostic required" means that it is undefined behavior is
you disobey; the implementation is not required to diagnose
the error, but may do anything it likes.

--
James Kanze (GABI Software, from CAI) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[terminator]

On Jun 13, 2:58 pm, Gavin Deane <[e-mail]:

Gavin Deane

thx every 1. got it.
regards,
FM.

[terminator]

On Jun 13, 2:18 am, "Daniel T." <[e-mail]:

terminator <[e-mail]:

On Jun 11, 5:06 pm, "Daniel T." <[e-mail]:

On Jun 7, 8:46 am, terminator <[e-mail]:
int f(int,int);//A big function

class A{
public:
const int m;
int n,p;
A(int i,int j):
p(0),
m(f(i,j))//const must be initialized here.
{n=m;};/*if n is initailized in the initializer list f is
called
twice which time expensive.*/
};

I try to avoid such micro-optimizations unless profiling has
shown that they are necessary. For this specific case, if the
function has no side effects, I expect the compiler would be
smart enough to cache the return value for the second use.-

you pointed to the side effects ;that is exactly what I mean ,and
since there is no way for the compiler to guess the existance of
such side effects it must not censor your code-or cache the value
as you wrote.

I disagree that "there is no way for the compiler to guess the
existance of such side effects". If the function deals with only its
parameters and local variables, there is no way for it to *have* side
effects

I have commented 'f' to be a large function whose value cannot be
deduced before excution specifically 'f' can be a random value
generating function.I would delare 'f' as 'inline' if it was a simple
value-forcastable function;this would motivate the compiler for
optimization. Moreover what I wrote is not a micro-
optimization.consider these two cases:
1. 'f' is an input function
2. 'f' is a random-return function
the return of 'f' will be different on every call in these cases.

In that case, calling f more than once will probably change the behavior
of the program and we are in a whole different world. Your initial
comment that you are doing it because it is "time expensive" is then in
error, your not calling it twice because that would be an error
regardless of the time it takes.

If that is the case, then you could do something like this:

class A {
const int m;
int n;
public:
A( int i, int j ): m( f( i, j ) ), n( m ) { }

};

Based on your earlier post, you are under the impression that assigning
in the body of the constructor is required under certain circumstances,
I don't think that is the case.- Hide quoted text -

the compiler is not smart enough to guess when a function has random
return ,more over input or random functions need not be low-cost ;they
might wait for other threads , allocate/deallocate buffers.
And these where just two possible cases of a the general term
function ,and this much is enough 4 the compiler not to make
optimizations except in very simple cases.

regards,
FM.

[Daniel T.]

terminator <fa***********@gmail.comwrote:

On Jun 13, 2:18 am, "Daniel T." <[e-mail]:

the compiler is not smart enough to guess when a function has random
return

I dispute that assertion as well. Any function that has a "random"
return will deal with a global. The compiler knows which variables are
global and I expect can tell that a function that changes a global
cannot have its returns cached.

,more over input or random functions need not be low-cost ;they
might wait for other threads , allocate/deallocate buffers.
And these where just two possible cases of a the general term
function ,and this much is enough 4 the compiler not to make
optimizations except in very simple cases.

Your missing the point. You asserted that assignment within the body is
required under certain circumstances. I dispute that assertion. So far,
you have not provided an example that requires it.