asking for an opinion from the collective wisdom here

[Gavin Deane]

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]

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.

 

[terminator]

Gavin Deane

thx every 1. got it.
regards,
FM.

 

[terminator]

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

On Jun 13, 2:18 am, "Daniel T." <[email protected]> wrote:

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.