Re: BSD Unix: Weird call to structure constructor in formatter.h
On Feb 10, 9:52 am, "Alf P. Steinbach" <a...@start.no> wrote:
* 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.
Only what the standard says.
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.
The standard defines what a destructor does. If you explicitly
call a destructor, you do what the standard says a destructor
does.
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.
You're ignoring the arguments others are presenting. No one
says that constructors can't be called. There is just no syntax
for doing so explicitly.
[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.
Arguments based on science and logic don't have much to do with
what you can or cannot do in C++, nor what the standard says.
The standard says that a constructor may be called as a result
of a certain number of different constructs. The only syntactic
construct for an expression which guarantees a call to the
constructor is a new expression. An explicit type conversion
may call the constructor, but it may also call a user defined
conversion operator. Regardless of which syntactic construct is
used: static_cast, functional notation or cast notation. Since
it isn't even guaranteed to call the constructor, I don't see
how you can consider it an explicit call of the constructor.
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. :-)
Up to a point:-). (I like arguing too, and will sometimes take
an opposing point of view just to be able to argue.)
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.
It's also the use in ?18.5.1.3:-). The standard isn't nearly as
clear about it as it could be.
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.
It's also, certainly, what Gerhard was referring to. It's the
"standard" way of invoking the constructor without any other
effects. And the standard does refer to it as the "placement
forms" of operator new.
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.
The standard defines, exactly, what a constructor does. Using a
placement new expression with a single, void* placement
argument, ultimately causes exactly that to be done, and nothing
else. The semantics of such an expression are exactly those of
explicitly calling the constructor (and in fact, it is the
construct we use in reality when we want to explicitly call the
constructor).
As for the syntax, I think you'd agree that it doesn't really
have the syntax one would expect for "explicitly" calling
anything.
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.
In the standard. One doesn't always learn everything exactly
the way it is explained in the standard.
[...]
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.
They are connected. Syntax determines whether something is
"explicit" or "implicit". To speak of something as an
"explicitly calling" the constructor supposes a certain syntax,
which always calls the constructor, and never does anything
else.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]