James Kanze writes:

>  |>  Throw a scope around it if you're concerned about temp's lifetime.

> Nice idea, but then what happens to the lifetime of myB?  (I've often
> wanted to do something like this -- declare a temporary, and have it go
> out of scope after use, but with the use being to initialize another
> variable which mustn't go out of scope.  If anyone knows a solution, I'd
> be interested in hearing about it.)

It would be simple if we had nested functions.  Since we don't, you
may use a nested class, and have a static function creating the
temporary and returning it:

void foo() {
  struct temp {
    static A myinit() { A mytemp; return mytemp; }
  };
  B initwithtemp = temp::myinit();
}

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

smeyers@teleport.com (Scott Meyers) writes:

 |>  In article <rf5iv1znrs2.fsf@vx.cit.alcatel.fr>,
 |>  James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
 |>  | Stephen Arnold <sarnold@us.oracle.com> writes:
 |>  |
 |>  | |>  James Kanze wrote:
 |>  | |>  > |>
 |>  | |>  > |>  How about
 |>  | |>  > |>
 |>  | |>  > |>      B   myB( (0, A()) ) ;
 |>  | |>  > |>
 |>  | |>  > |>  ?
 |>  | |>  >
 |>  | |>  > That should work.  Of course, I don't think it will win any beauty
 |>  | |>  > prize.
 |>  | |>
 |>  | |>  That will work only if no such 'operator,(int,const A &)' exists that
 |>  | |>  has undesirable side effects or return value.
 |>  |
 |>  | Point taken.
 |>  |
 |>  | Now, suppose that B has no accessible copy constructor, and that there
 |>  | is such a user defined operator,().  How do I declare an instance of B
 |>  | initialized by an A()?  Maybe:
 |>  |
 |>  |  B   MyB( 1 ? A() : A() ) ;
 |>  |
 |>  | (It's getting uglier and uglier, but at least the user cannot redefine
 |>  | ?:.)
 |>
 |>  I prefer
 |>
 |>    A temp;
 |>    B MyB(temp);

Agreed.  I wasn't really suggesting that people should write things like
I posted.  In real programs, this is what I generally use, too.

 |>  Throw a scope around it if you're concerned about temp's lifetime.

Nice idea, but then what happens to the lifetime of myB?  (I've often
wanted to do something like this -- declare a temporary, and have it go
out of scope after use, but with the use being to initialize another
variable which mustn't go out of scope.  If anyone knows a solution, I'd
be interested in hearing about it.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alexandre Oliva  <oliva@dcc.unicamp.br> wrote:
>If it's in local scope and you really want to avoid copy-construction:
>
>auto B MyB(A());

Uhoh.

If I have two classes, A and B:

class A {
 public:
 A() { cout << "A ctor" << endl; }
};

class B {
 public:
 B(A const&) { cout << "B ctor(A)" << endl; }
 private:
 B();
 B(B const&);
};

int main() {
 auto B  myB(A());
}

and nothing is printed from the program generated by my compiler
(Borland 5.2), is my compiler hopelessly broken?
--
David A. Cuthbert (henry.ece.cmu.edu!dacut)
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alexandre Oliva  <oliva@dcc.unicamp.br> wrote:
>>If it's in local scope and you really want to avoid copy-construction:
>>
>>auto B MyB(A());

I had a little look at the DWP.  Using `auto' here doesn't help.
`auto' can be used to explicitly disambiguate things as declarations,
rather than as expressions, but the default ambiguity resolution is
that anything that could be either a declaration or an expression is
a declaration, so using `auto' never changes the behaviour -- it is
just for documentation.

Also here the ambiguity for the statement as a whole is not an
ambiguity between a declaration and an expression, it is an ambiguity
between two different declarations, a function declaration and an
object declaration, based on the underlying ambiguity of the
sub-component `A()' as either an argument declaration or an
expression.  If you want to use `auto' for documentation, the
appropriate place to put it is in the argument declaration:

 B myB(auto A()); // declare `myB' as a function taking
    // a (pointer to) function returning `A',
    // and returning B.

Since nested function declarations are prohibited, this is allowed
only at global scope, or if you add an explicit `extern' to make
it a nested extern declaration (but note that nested extern
declarations are deprecated).

Going back to your code, the example

>>auto B MyB(A());

is resolved as a function declaration, and then, since functions cannot
be declared `auto', it is ill-formed.

dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
...
> auto B  myB(A());
...
>nothing is printed from the program generated by my compiler
>(Borland 5.2), is my compiler hopelessly broken?

Since the DWP requires the above to be parsed as a function
declaration, not an object declaration, you should not expect any
side-effects from object constructors.

A DWP-conforming compiler must issue a diagnostic, and so if your
compiler claims to be DWP-conforming and you invoked it in the proper
mode, then it is broken.  However, I would not call a compiler that
failed to issue a diagnostic for this "hopelessly" broken.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi!

James Kanze wrote:
> |>
> |>  How about
> |>
> |>      B   myB( (0, A()) ) ;
> |>
> |>  ?
>
> That should work.  Of course, I don't think it will win any beauty
> prize.

That will work only if no such 'operator,(int,const A &)' exists that
has undesirable side effects or return value.

terv: Risto Lankinen
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stephen Arnold <sarnold@us.oracle.com> writes:

|>  James Kanze wrote:
|>  > |>
|>  > |>  How about
|>  > |>
|>  > |>      B   myB( (0, A()) ) ;
|>  > |>
|>  > |>  ?
|>  >
|>  > That should work.  Of course, I don't think it will win any beauty
|>  > prize.
|>
|>  That will work only if no such 'operator,(int,const A &)' exists that
|>  has undesirable side effects or return value.

Point taken.

Now, suppose that B has no accessible copy constructor, and that there
is such a user defined operator,().  How do I declare an instance of B
initialized by an A()?  Maybe:

 B   MyB( 1 ? A() : A() ) ;

(It's getting uglier and uglier, but at least the user cannot redefine
?:.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze writes:

> Now, suppose that B has no accessible copy constructor, and that there
> is such a user defined operator,().  How do I declare an instance of B
> initialized by an A()?  Maybe:

>  B   MyB( 1 ? A() : A() ) ;

> (It's getting uglier and uglier, but at least the user cannot redefine
> ?:.)

If it's in local scope and you really want to avoid copy-construction:

auto B MyB(A());

If it's in namespace scope, you may use the following dirty trick:

template <class T> inline T temporary() { return T(); }
B myB(temporary<A>());

This will fail if A does not provide a visible copy-constructor.  For
this to work, a dirtier trick is necessary:

template <class T>
inline T const& direct_init_from(T const& v)
{ return v; }
B myB(direct_init_from(A()));

The constness of direct_init_from's argument and return value won't
affect the initialization, since, if the constructor of myB required a
non-const reference to A, the original declaration (B myB(A())) would
not be valid at all, since a non-const reference cannot be bound to a
temporary.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Alexandre Oliva <oliva@dcc.unicamp.br> wrote:
>...
>This will fail if A does not provide a visible copy-constructor.  For
>this to work, a dirtier trick is necessary:

>template <class T>
>inline T const& direct_init_from(T const& v)
>{ return v; }
>B myB(direct_init_from(A()));

>The constness of direct_init_from's argument and return value won't
>affect the initialization, since, if the constructor of myB required a
>non-const reference to A, the original declaration (B myB(A())) would
>not be valid at all, since a non-const reference cannot be bound to a
>temporary.

Unless A has a reference conversion operator. In that case though, I
suppose a non-const overload of direct_init_from could be used.

It really is a shame that such contortions are needed for the common
case of construction with a temp, all to allow for the rare usage of
abstract declarators of function type;  especially when it would be
such a trivial change to fix it in the draft by banning function
abstract declarators..

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <rf5iv1znrs2.fsf@vx.cit.alcatel.fr>,
James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
| Stephen Arnold <sarnold@us.oracle.com> writes:
|
| |>  James Kanze wrote:
| |>  > |>
| |>  > |>  How about
| |>  > |>
| |>  > |>      B   myB( (0, A()) ) ;
| |>  > |>
| |>  > |>  ?
| |>  >
| |>  > That should work.  Of course, I don't think it will win any beauty
| |>  > prize.
| |>
| |>  That will work only if no such 'operator,(int,const A &)' exists that
| |>  has undesirable side effects or return value.
|
| Point taken.
|
| Now, suppose that B has no accessible copy constructor, and that there
| is such a user defined operator,().  How do I declare an instance of B
| initialized by an A()?  Maybe:
|
|  B   MyB( 1 ? A() : A() ) ;
|
| (It's getting uglier and uglier, but at least the user cannot redefine
| ?:.)

I prefer

  A temp;
  B MyB(temp);

Throw a scope around it if you're concerned about temp's lifetime.

Scott

--
Scott Meyers, Ph.D.                  Voice: 503/638-6028
C++ Consulting and Training          Fax:   503/638-6614
Author of "Effective C++"            Email: smeyers@netcom.com
  and "More Effective C++"           WWW:   http://www.teleport.com/~smeyers
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Actually, fixing the draft so that abstract declarators of function
type are not allowed (e.g. A () is disallowed, instead one needs to
use A func() or A (*)() ) , as is done in Visual C++ 4.2 would appear
to be an extremely simple fix. In the grammar production for
direct-abstract-declarator, just remove the "optional" subscript from
direct-abstract-declarator in the function case, and then correct the
examples in Section 8.2 [dcl.ambig.res].
I can't imagine that this would cause any problems with old code; the
few cases where function abstract declarators have been used would be
trivially convertible to declarators.
I have probably missed something here. Any comments?

,Brian Parker (bparker@gil.com.au)

---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>I can think of several possible solutions.  To begin with, is there
>really any need to support functions at all in abstract declarators?  I
>don't think that a function, as such, is ever legal in the uses of an
>abstract declarator (casts, new, and sizeof).  Alternatively, one could
>drop the text which says that a function type in an argument declaration
>list converts to a pointer to a function; I see no real advantage in
>being able to declare that a function takes a function as an argument,
>when in fact it takes a pointer to function.  (I've not considered
>templates, however.)

Yes, I think at this stage of the standardisation process the minimal
fix is to simply syntactically ban function  type abstract
declarators.

In fact, I think the fix may be as simple as removing the first opt
from the direct-abstract-declarator production.

It is a good thing you raised this issue and I hope it gets fixed; it
could cause a lot of grief otherwise..

Brian Parker (bparker@gil.com.au)

---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>    B   myB( A() ) ;
>
>According to the CD, this declares a function taking a pointer to an A
>and returning a B.

Don't you mean "this declares a function taking a (pointer to) a
function [taking no arguments and returning an A] and returning a B"?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>Given this, how does one go about defining a B
>initialized with an explicitly constructed A.

How about

    B   myB( (0, A()) ) ;

?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Actually, this problem may be even more serious than I at first
thought.

On checking my code I have found examples like this:

class A {
public:
 A() {}
};

class Vector {
public:
 Vector(A, A, A) {} // construct 3D vector
};

int main()
{
 Vector v( A(), A(), A()); // vector of default values
 ...
}

This compiles OK on Visual C++ 4.2, but from the previous examples in
this thread I fear that this declares v as a function taking three
function pointers. Surely not! If true this would be a major language
flaw; and all this just to allow for the dubious redundant construct
of an abstract declarator of function type. Visual C++ takes what
appears to be the correct approach and simply syntactically disallows
absract declarators of function type and requires either a declarator
of function type or an explicit pointer to function declarator or
abstract declarator.

Unfortunately, the public comment period has ended.  Are there any
plans within the committee to fix this (preferably by banning abstract
declarators of function type) ?

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

bparker@gil.com.au (Brian Parker) writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:
|>
|>  >Consider the following classes:
|>
|>  >    class A { public: A() ; } ;
|>  >    class B {
|>  >    public:
|>  >     B() ;
|>  >    private:
|>  >     B( B const& ) ;
|>  >    } ;
|>
|>  Do you mean for B to have a constructor taking an A?

Yes.  Sloppy typing.  The public constructor should be "B( A const& )".

|>  >Consider:
|>
|>  >    B   myB( A() ) ;
|>
|>  >According to the CD, this declares a function taking a pointer to an A
|>  >and returning a B.  Given this, how does one go about defining a B
|>  >initialized with an explicitly constructed A.  The best I've been able
|>  >to come up with is:
|>
|>  >    B   myB( static_cast< A const& >( A() ) ) ;
|>
|>  I suppose the assignment equivalent
|>  B myB = A();
|>  would be used in most cases except where there is a private copy
|>  constructor (as above) or explicit constructor.

The problem is that well over half of my classes have private copy
constructors.  For this reason, and the fact that I like to clearly
distinguish between initialization and assignment, I generally use the
function form.

|>  The given example of B myB(A()) being a function declaration taking a
|>  A (*)(void)  is a real gotcha. Is that due to a recent change?

|>  The given example of B myB(A()) being a function declaration taking a
|>  A (*)(void)  is a real gotcha. Is that due to a recent change? I have
|>  never stumbled across it before.

I think so.  I can't find anything in the ARM off-hand one way or
another, but CFront considers this a definition of a B.  G++ 2.7.2
conforms to the current draft, however; I don't currently have access to
earlier versions to compare.

|>  It seems that Visual C++ 4.2 won't do an implict conversion of a
|>  parameter from "function" to "pointer to function" unless a full
|>  declarator is used, not just an abstract-declarator. Maybe that would
|>  be a good rule to remove the ambiguity (or maybe not- it would be a
|>  complicating special case). Perhaps it would be better just to
|>  disallow the conversion from "function" to "pointer to function" in
|>  declarations- it is, I think, little-used anyway (in declarations).

I can think of several possible solutions.  To begin with, is there
really any need to support functions at all in abstract declarators?  I
don't think that a function, as such, is ever legal in the uses of an
abstract declarator (casts, new, and sizeof).  Alternatively, one could
drop the text which says that a function type in an argument declaration
list converts to a pointer to a function; I see no real advantage in
being able to declare that a function takes a function as an argument,
when in fact it takes a pointer to function.  (I've not considered
templates, however.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>
|>  >    B   myB( A() ) ;
|>  >
|>  >According to the CD, this declares a function taking a pointer to an A
|>  >and returning a B.
|>
|>  Don't you mean "this declares a function taking a (pointer to) a
|>  function [taking no arguments and returning an A] and returning a B"?
|>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Something like that:-).  It declares a function, and not a local
variable.

|>  >Given this, how does one go about defining a B
|>  >initialized with an explicitly constructed A.
|>
|>  How about
|>
|>      B   myB( (0, A()) ) ;
|>
|>  ?

That should work.  Of course, I don't think it will win any beauty
prize.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

bparker@gil.com.au (Brian Parker) writes:

> Unfortunately, the public comment period has ended.  Are there any
> plans within the committee to fix this (preferably by banning abstract
> declarators of function type) ?

The US public comment period has ended, so it is now too late for
issues to make their way onto the US ballot.  However, the US is
(despite what Americans sometimes think) not the only country in the
world...  It is not too late for you to make comments to
representatives of other national bodies.

I know that the UK, Germany, and Sweden are still able to deal with
comments.  Maybe Australia is too.  I would recommend talking to the
Australian WG21 representative.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Consider the following classes:

    class A { public: A() ; } ;
    class B {
    public:
     B() ;
    private:
     B( B const& ) ;
    } ;

Consider:

    B   myB( A() ) ;

According to the CD, this declares a function taking a pointer to an A
and returning a B.  Given this, how does one go about defining a B
initialized with an explicitly constructed A.  The best I've been able
to come up with is:

    B   myB( static_cast< A const& >( A() ) ) ;

I'm posting this to comp.std.c++ (rather than comp.lang.c++.moderated)
because IMHO, if there isn't a simpler way, something should be changed
in the standard.  It's also possible that I've missed a constraint
somewhere which prevents the first form from being interpreted as a
function declaration.  It was, in fact, my belief that there was such a
constraint, but I've been unable to find it, and there is an example in
8.2 of exactly this.  (My thanks to Lassi Tuura for pointing out to me
that the first form doesn't do what I thought it should.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>Consider the following classes:

>    class A { public: A() ; } ;
>    class B {
>    public:
>     B() ;
>    private:
>     B( B const& ) ;
>    } ;

Do you mean for B to have a constructor taking an A?

>Consider:

>    B   myB( A() ) ;

>According to the CD, this declares a function taking a pointer to an A
>and returning a B.  Given this, how does one go about defining a B
>initialized with an explicitly constructed A.  The best I've been able
>to come up with is:

>    B   myB( static_cast< A const& >( A() ) ) ;

I suppose the assignment equivalent
B myB = A();
would be used in most cases except where there is a private copy
constructor (as above) or explicit constructor.

The given example of B myB(A()) being a function declaration taking a
A (*)(void)  is a real gotcha. Is that due to a recent change? James
Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>Consider the following classes:

>    class A { public: A() ; } ;
>    class B {
>    public:
>     B() ;
>    private:
>     B( B const& ) ;
>    } ;

Do you mean for B to have a constructor taking an A?

>Consider:

>    B   myB( A() ) ;

>According to the CD, this declares a function taking a pointer to an A
>and returning a B.  Given this, how does one go about defining a B
>initialized with an explicitly constructed A.  The best I've been able
>to come up with is:

>    B   myB( static_cast< A const& >( A() ) ) ;

I suppose the assignment equivalent
B myB = A();
would be used in most cases except where there is a private copy
constructor (as above) or explicit constructor.

The given example of B myB(A()) being a function declaration taking a
A (*)(void)  is a real gotcha. Is that due to a recent change? I have
never stumbled across it before.
It seems that Visual C++ 4.2 won't do an implict conversion of a
parameter from "function" to "pointer to function" unless a full
declarator is used, not just an abstract-declarator. Maybe that would
be a good rule to remove the ambiguity (or maybe not- it would be a
complicating special case). Perhaps it would be better just to
disallow the conversion from "function" to "pointer to function" in
declarations- it is, I think, little-used anyway (in declarations).

Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]