Re: BSD Unix: Weird call to structure constructor in formatter.h
* James Kanze:
Alf P. Steinbach wrote:
* Gerhard Menzl:
Alf P. Steinbach wrote:
* James Kanze:
Most people (I think) don't consider them as such, because they do
more.
You're onto a slippery slope: an explicit call of a destructor does
about the same, complexity-wise, as an explicit call of a constructor.
I don't think so. An explicit call of a destructor doesn't free memory.
Yes, as I went on to discuss in the article you quoted from, allocation
related actions seem to be a dividing line for James (and now you).
Not allocation per se. It's more general. The dividing line is
simple: if the expression calls X, and only calls X, it can be
said to be, semantically at least, an explicit call of X. If it
does other things (allocating memory just happens to be the
example here), then it is not an explicit call of X (but that
doesn't mean that in some cases, X may be called).
It seems that there is no technically well-defined procedure one could
use to determine what "do more" or "only call" is or isn't.
I thought allocation-related would be it, but now you state that that's
just one example.
For example, elsethread you have stated the position that an explicit
destructor call is a call, but that a destructor call doesn't "do more"
than calling the destructor, so evidently, automatically added calls are
not necessarily "do more" -- it all depends, on something unstated.
On the other hand, I don't find it surprising that that there seems to
be no general technical definition possible for the "do more".
That's because, as I've shown elsethread, the very concept of denying
that a call is call leads to contradictions when interpreting the
standard, and with a set of contradictions as postulate, anything goes.
[snip]
Sorry, there are expressions that look like explicit constructor calls
and really are: they're constructor calls, and they're explicit. This
has already been discussed, but perhaps a new round of discussion is
needed for each person.
That's because, to date, no one has been convinced. You seem to
be the only one trying to argue the position from a standards
point of view.
I've certainly not been convinced, if that's what you mean. And yes, I'm
one of the few caring to argue that the Earth is round and the Sun is a
star and so on, with arguments based on science and logic. I know it's
probably a lost cause in every case, that in the end I won't have
resqued more than a few souls out of the endless multitude (as far as I
know only a few souls have so far been rescued re "constructor calls"),
but nevertheless, I feel that it's the Right Thing(TM) to do, a kind of
moral imperative -- and besides, it's fun. :-)
And on the other hand, placement new, which
looks like and which you state above has the effect of a direct
constructor call (note: difference between explicit and direct), is a
very indirect constructor call. In particular, it's unspecified whether
the constructor arguments are evaluated before or after the allocation
function is called (and that function can throw).
Not really. The placement new which I think Gerhard was
referring to (as you know, the expression has two different
meanings)
Huh?
But no matter, I think you mean /using/ placement new to construct an
object in-place, which presumably is the origin of that term.
is defined in the standard with a "throw()" exception
specifier, and is required to be a no-op.
It seems you're referring to the standard do-nothing allocation
function, which isn't placement new: it's a function that (also) can be
invoked via placement new, which itself is a syntactical construct.
The semantic effects
are exactly those of explicitly calling the constructor. (The
syntax, of course, is another matter.)
Sorry, those two sentences are not meaningful to me.
Without understanding the indirectness of new and placement
new, this can be hard to grok.
Yes and no. I suppose that one could just learn that it's just
a wierd syntax for explicitly calling the constructor. Of
course, in that case, when one learned the general placement
new, one would wonder about the similarity of the syntaxes.
Huh?
There is no "similarity of the syntaxes".
There is one general placement new syntax, not two or more.
[...]
There's therefore no need to look to additional, imaginary constructor
properties to justify the statement that constructors can't be called
like other member functions.
I think that the problem is more complex. Consider something
like:
struct Toto {} ;
struct Titi { operator Toto() { return x ; } ; Toto x ; }
void f( Toto const& ) ;
void g()
{
Titi a ;
f( Toto( a ) ) ;
}
Is "Toto( a )", in the next to last line an explicit call to the
constructor. It's certainly an "explicit type conversion
(functional notation)".
No, it's not practical to say that a call to 'foo' is a call to some
function that in turn /may/ be called somewhere down the call hierarchy.
This may be just a confusion of syntax and semantics.
In the view that a call is call there is no problem, and it really isn't
complex at all: it's very simple, syntax isn't semantics, which is why
that view is practical.
If the authors of the standard chose this way of describing
things, there's a reason.
Yes, I agree. The authors chose to describe calls as calls, explicit as
explicit, indirect as indirect and so on, as exemplified thrice in this
thread, because that's the most practical. Anything else leads to "more
complex" (and worse, blatant contradictions, as shown elsethread). ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]