A few minor questions

[Bart van Ingen Schenau]

Sounds good, I was going to try to code an exception within an
exception
but then I tried this in Cygwin:

try {
int *a = 0;
*a = 0;

This results in Undefined Behaviour, which means that anything can
happen.
It is specifically NOT required to throw an exception.

}
catch ( ... ) {
cout << "uh oh\n";
}

And got:

Whatever result you got from the program is a correct result, because
you invoked UB. Be glad that it was something as obvious as a crash.

Bart v Ingen Schenau

 

[Bart van Ingen Schenau]

* James Kanze:

Sorry, that's incorrect.

Then you must be able to quote the standard on where it describes a
grammar production as a constructor call.

For a function call, we have the grammar production (clause 5.2/1)
postfix-expression:
postfix-expression ( expression-list_opt )

and the description (clause 5.2.2/1)
"[...] A function call is a postfix expression followed by parentheses
containing a possibly empty, comma-separated list of expressions which
constitute the arguments to the function. [...]"

Can you give me a similar quote for constructor call?
If not, that should be proof enough that there is no construct in the
C++ grammar for calling a constructor.
And if the grammar does not have a construct for something, you also can
not express that thing in source code.

Sorry, it's not, it refers to source code.

If you think "can be called" refers to anything but source code then
you have to demonstrate that the paragraph, with that non-source code
interpretation, still provides a clear cut definition of a default
constructor, and not the least, one that is consistent with what we
"know" is a default constructor from the source code interpretation,
e.g. that T( int = 5 ) is a T default constructor.

How about this interpretation: "The implementation arranges for the
constructor to be called". Here, there is no source code involved, but
the definition of a default constructor is still equally clear and it
even matches the semantics of initialisation (as specified in 8.5).

Note that the syntactic construct of an initialiser can not be called "a
constructor call", because an initialiser also covers the initialisation
of types that don't have constructors.

You have repeatedly failed to do that earlier, throughout the years,
so chances would be slim of achieving it now, but,.



Right, although extremely irrelevant.

Then this whole discussion is completely irrelevant, because that is
exactly the point being discussed here.

Syntactically it's a definition, semantically it's one whose effect
contains a constructor call.

Correct, but the semantics don't describe source code constructs. The
semantics describe the meaning of the source code constructs that are
described by the syntax.

It could, with a little modification, be a definition containing an
ordinary function call, like 'int x = MessageBox( 0, "James, you're
being silly", "Look!", 0 )'. The standard would still call it a
"definition", not an "ordinary function call", and most C++
programmers I know would speak about "declaring a variable" at the
source code level...

Now you are trying to muddy the waters, because you are starting to
realise you are wrong.

Yes.


Cheers,

- Alf

Bart v Ingen Schenau

 

[Alf P. Steinbach]

* Bart van Ingen Schenau:

Then you must be able to quote the standard on where it describes a
grammar production as a constructor call.

I'm sorry, that inference is incorrect.

The C++ syntax has no dedicated grammar production for e.g. constructor calls.

It's simply not the case that the C++ grammar has a dedicated production for
every feature of the language, or for every term employed by the standard.


[snip]

Correct, but the semantics don't describe source code constructs. The
semantics describe the meaning of the source code constructs that are
described by the syntax.

I'm sorry, the "but" in there, indicating some contradiction, is incorrect: what
you describe is of itself correct, not contradicting the first "correct".

Now you are trying to muddy the waters,

Sorry again, but that's just silly.

A clear exposition of an invalid water-muddling argument as such, is to muddy
the waters?

Jeez.

because you are starting to
realise you are wrong.

And again sorry, but assigning possible motives to me for your silly hypothesis
does not help.

I will not be impressed no matter how many silly descriptions you invent and
even sillier motives you hypothesize for whatever silliness you invent.

Rather, the contrary.


Cheers & hth.,

- Alf

 

[Juha Nieminen]

try {
int *a = 0;
*a = 0;
}
catch ( ... ) {
cout << "uh oh\n";
}

Try (no pun intended) this instead:

try
{
std::vector<int> v;
v.at(0) = 0;
}
catch(...)
{
std::cout << "uh oh...\n";
}

 

[James Kanze]

* James Kanze:

* Jeff Schwab:

[...]

Which if you think about it implies very different things at
the machine code level and at the source code level.

You keep insisting on this distinction.

Yes.

Yes, I think that's correct -- which was my point.

Sorry, that's incorrect.

So where does it specify it. I've searched and I've searched,
but I can't find it. (Logically, it should be section 5, since
that's where expressions are treated.)

That's true.

Sorry, it's not, it refers to source code.

What makes you say that?

If you think "can be called" refers to anything but source
code then you have to demonstrate that the paragraph,

If you think "can be called" can only refer to source code, then
you'll have to demonstrate that somehow. All the standard says
is "can be called", it doesn't say anything about a particular
source code syntax here.

with that non-source code interpretation, still provides a
clear cut definition of a default constructor, and not the
least, one that is consistent with what we "know" is a default
constructor from the source code interpretation, e.g. that T(
int = 5 ) is a T default constructor.

The standard is consistent in this case---T( int = 5 ) is a
default constructor, and can be called (by the compiler) without
arguments (since the compiler knows what arguments it needs).

You have repeatedly failed to do that earlier, throughout the
years, so chances would be slim of achieving it now, but,.

Right, although extremely irrelevant.

Syntactically it's a definition, semantically it's one whose
effect contains a constructor call.

Certainly. There are several different constructs which have,
as a side effect, a call to a constructor. That's not the same
as the programmer calling a constructor.

It could, with a little modification, be a definition
containing an ordinary function call, like 'int x =
MessageBox( 0, "James, you're being silly", "Look!", 0 )'. The
standard would still call it a "definition", not an "ordinary
function call", and most C++ programmers I know would speak
about "declaring a variable" at the source code level...

If MessageBox is a function, the standard calls the
sub-expression "MessageBox(...)" a "function call" (§5.2.2). If
MessageBox is the name of a class (unlikely, since it apparently
returns an int), then the standards calls this same
sub-expression an "Explicit type conversion (functional
notation)" (§5.2.3). The entire statement is a definition, but
a definition can contain (at the source code level) an
expression, and that expression can contain function calls,
explicit type conversions, and just about anything else.

I fail to see how this is relevant to the case in question,
however:
MyClass c ;
There's no expression there, and no explicit call to anything.

 

[James Kanze]

* Bart van Ingen Schenau:

I'm sorry, that inference is incorrect.

The C++ syntax has no dedicated grammar production for e.g.
constructor calls.

It's simply not the case that the C++ grammar has a dedicated
production for every feature of the language, or for every
term employed by the standard.

There are two separate issues. It's a perfectly reasonable
interpretation that anything expressed in source code must have
a corresponding grammar; in fact, I find it hard to understand
any other interpretation. That doesn't mean that what can be
expressed in the grammar is all of C++---nobody's arguing that
constructors can't be called or are never called.

 

[Alf P. Steinbach]

* James Kanze:

* James Kanze:

* Jeff Schwab:
[...]
Which if you think about it implies very different things at
the machine code level and at the source code level.
You keep insisting on this distinction.

Yes.

Yes, I think that's correct -- which was my point.

Sorry, that's incorrect.

So where does it specify it. I've searched and I've searched,
but I can't find it. (Logically, it should be section 5, since
that's where expressions are treated.)

Hm, short term memory problems?

It's pointed out else-thread and up-thread.

Which you have even replied to.

What makes you say that?

Just a feeling the it's the right thing to do, correcting the incorrect
impression I responded to.

But perhaps you meant to ask, why does the standard refer to source code.

That's because the standard is about specifying the meaning of source code.

It maps Source code to an abstract Machine, S -> M.

It does NOT define the Effect of source code in terms of an abstract machine, it
doesn't use an abstract machine as the starting point, e.g. it doesn't compare S
-> E and M -> E, or whatever it is that you imagine (but veer away from making
too concrete), because then it would have to define the abstract machine like
e.g. Vienna, and then the standard would be perhaps twice the size.

If you think "can be called" can only refer to source code, then
you'll have to demonstrate that somehow.

Already done quite a few times here.

All the standard says
is "can be called", it doesn't say anything about a particular
source code syntax here.

That's right.

The standard is consistent in this case---T( int = 5 ) is a
default constructor, and can be called (by the compiler) without
arguments (since the compiler knows what arguments it needs).

And if you remove the parentheses that's also right.

Unfortunately, with the parentheses it's just complete nonsense.

The first parenthesis is nonsense: A C++98 compiler doesn't call anything in the
program being compiled, it generates machine code that calls.

The second parenthesis is nonsense: a machine code routine can't be called with
fewer arguments than it has and expect any well-defined effect.


The above is *what you need to address* to make your point (or at least one way
of doing it), namely to show that the standard's definition of a default
constructor under your non-source code interpretation, whatever it is, still
provides a clear cut definition of a default constructor, and not the least, one
that is consistent with what we "know" is a default constructor from the source
code interpretation, e.g. that T(int=5) is a T default constructor.

However, as far as I know that's impossible to show.

And that's borne out by your repeated failure to show it. You're one of the most
competent persons around here and you've tried for, I don't know, 5 years?, to
do that, and you have utterly failed every time, not even managing some likely
start or even handwaiving argument in that direction, but mostly, as this time
just steadfastly ignoring and evading. I don't think anyone else can do it when
you can't, and since you've failed every time, I don't think you can.

Considering that the textual interpretation works very well and is eminently
practical, and that your apparently impossible-to-clarify wooly and evasive
"it's something else!" doesn't currently work at all (no concrete description of
it available) and is thus completely impractical, well...

'Nuff said. Except -- I remember the one time you conceded the point above. It
wasn't then due to any valid technical argument such as those I've presented,
but only when I coughed up a logically invalid authority argument, namely
quoting Bjarne Stroustrup and Andrew Koenig referring to their source code call
as an "explicit constructor call". Would you like that again? Anything to
please, if I can still find it, that is.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* James Kanze:

There are two separate issues.

I'm sorry, I can't understand what you're referring to. "Missing context".

It's a perfectly reasonable
interpretation that anything expressed in source code must have
a corresponding grammar;

I'm sorry, it isn't. Not in C++. Consider e.g. the statement

4 + 3u;

This is a "usual arithmetic conversion" (it's also a statement, and it's also a
line of code, and so on, which I mention just because you have a history of
evasion regarding this matter, then usually pointing out some such aspect).

Nowhere will you find a grammar production for a usual arithmetic conversion.

in fact, I find it hard to understand
any other interpretation.

Uh oh. You find it hard to understand anything of C++ that doesn't have
corresponding grammar productions? ROFL.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach]

* Jeff Schwab:

Bingo.

That applause is just more noise.

What James writes is mostly correct, but only because it's meaningless.

Programmers don't call constructors, nor do compilers call constructors, it's
just meaningless verbiage -- or it would be meaningless except that what it's
being proffered as argument for is a view that makes some of the standard's
definitions meaningless and that makes communication really awkward, a wholly
impractical irrational "other" thing that no-one has been able to define, and
that in particular neither you nor James have been able to so much as outline,
in short, pure idiocy.


Cheers & hth.,

- Alf

 

[Bart van Ingen Schenau]

* James Kanze:

That is completely beside the point, because not all C++ features are
syntactic constructs.
For example, implicit conversions are very definitely a feature of C++,
but there is no syntax to describe them in source code. They just happen
when the semantics of the program call for them. The same with calling
constructors.

I'm sorry, I can't understand what you're referring to. "Missing
context".



I'm sorry, it isn't. Not in C++. Consider e.g. the statement

4 + 3u;

This is a "usual arithmetic conversion"

Do you describe this also as "usual arithmetic conversion"?
sqrt(static_cast<long double>(1.0f * 1.0));

Describing a statement that contains an expression to which the usual
arithmetic conversions are applied as BEING a "usual arithmetic
conversion" does everyone and the C++ language in particular a
disservice.

(it's also a statement, and
it's also a line of code, and so on, which I mention just because you
have a history of evasion regarding this matter, then usually pointing
out some such aspect).

Nowhere will you find a grammar production for a usual arithmetic
conversion.

That is right, because it is not a syntactic construct. It is a semantic
result.

Cheers & hth.,

- Alf

Bart v Ingen Schenau

 

[Alf P. Steinbach]

* Bart van Ingen Schenau:

That is completely beside the point, because not all C++ features are
syntactic constructs.

Uhm, the part after the comma restates what I wrote. The part before the comma
says that that is itself the reason why that is "beside the point". Since that's
completely meaningless you may have meant to write something else?

For example, implicit conversions are very definitely a feature of C++,
but there is no syntax to describe them in source code. They just happen
when the semantics of the program call for them. The same with calling
constructors.

Sort of, yes.

You're getting there...

Do you describe this also as "usual arithmetic conversion"?
sqrt(static_cast<long double>(1.0f * 1.0));

Embedding an X example in a complete program would much more dramatically make
the point that the sourrounding code is irrelevant for calling an X an X.

Describing a statement that contains an expression to which the usual
arithmetic conversions are applied as BEING a "usual arithmetic
conversion" does everyone and the C++ language in particular a
disservice.

I'm sorry, in context the above is an argument that you think it's wrong to
describe a clear-cut example of an arithmetic conversion as an arithmetic
conversion, because you're able to add so much irrelevant stuff (as you
demonstrate above) that the example is no longer clear-cut.

And that's a fallacy, not to say an idiocy.

Even though your example-with-much-extra-irrelevant-stuff is unclear, my example
wasn't, and attacking your own example is a bit silly, don't you think?

It's called a "straw-man" fallacy, attacking a distorted version of a position,
and interestingly enough Jeff Scwab also resorted to that technique in another
thread within the last few hours, so I'm copying & pasting the same informative
link I gave him: <url: http://www.nizkor.org/features/fallacies/straw-man.html>.

Anyways, when considering the standard's definitions, and when considering the
standard's use of terms like "constructor invocation" and "constructor call",
and when considering ordinary programmers' use of such terms, they don't apply
to any irrelevant stuff you add around or within a constructor invocation/call.

That is right, because it is not a syntactic construct. It is a semantic
result.

Right.


Cheers & hth.,

- Alf