Why does c++ not allow taking an address of a constructor or destructor?

I know people say it is useless but if the language wanted to support
it, would it be technically possible? If so, how? If not why?

What I got so far based on the answers from comp.lang.c++ is that
- it is useless AND
- to support it, it needs a different mechanism from ptr to normal
member functions

Hence, it is NOT allowed.

If this is true, then what I want to know is why, to support it, we
needs a different mechanism from ptr to normal member functions.

thanks
kn

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <W_idnQAeU7Qa_KiiU-KYgg@comcast.com>, root
<royalmacaronipenguin@yahoo.com> writes
>Why does c++ not allow taking an address of a constructor or
>destructor?
>
>I know people say it is useless but if the language wanted to support
>it, would it be technically possible? If so, how? If not why?
>
>What I got so far based on the answers from comp.lang.c++ is that
>- it is useless AND
>- to support it, it needs a different mechanism from ptr to normal
>member functions
>
>Hence, it is NOT allowed.
>
>If this is true, then what I want to know is why, to support it, we
>needs a different mechanism from ptr to normal member functions.

So what would the type of a ctor be? AFAICT every ctor has a unique type
which sort of makes its address pointless:)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root wrote:
> Why does c++ not allow taking an address of a constructor or destructor?

Because they're not regular functions, and there is
no syntactical way to take their address. Syntax could
be added, but it's not worth doing so unless someone
makes a case for it.  I don't think a successful case
is likely to be made.

> I know people say it is useless but if the language wanted to support
> it, would it be technically possible? If so, how? If not why?

No need.

template <typename TypeToConstruct>
void call_constructor(void *address)
{
   (void) new (address) TypeToConstruct;
}

You can take the address of call_constructor<T> if you
wish.

> What I got so far based on the answers from comp.lang.c++ is that
> - it is useless AND

Fair comment.

> - to support it, it needs a different mechanism from ptr to normal
> member functions

Regular function pointers are sufficient, no need for ptmfs.
A constructor does not act on an existing object, it acts on
raw memory and converts it to an object.

-- James.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> So what would the type of a ctor be? AFAICT every ctor has a unique type
> which sort of makes its address pointless:)
>
>

Assuming ptr to member function was to use for ctor also:



class apple {
     int _i;
public:
     explicit apple():_i(8) {}

     void f(int i) {....}
};

typedef void(apple::*PMF)(int);

PMF pmf1 = &apple::apple; //take int arg for addr to initialize
PMF pmf2 = &apple::f;

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> Because they're not regular functions, and there is
> no syntactical way to take their address. Syntax could
> be added,



This sounds like the kind of reasoning I'm looking for. BUt can you
elaborate more on the part
"they're not regular functions, and there is
  no syntactical way to take their address"

You say "....Syntax could be added", can u give me some example please.

>
>> - to support it, it needs a different mechanism from ptr to normal
>> member functions
>
>
> Regular function pointers are sufficient, no need for ptmfs.
> A constructor does not act on an existing object, it acts on
> raw memory and converts it to an object.
>
The above you say ".... there is
 > no syntactical way to take their address." AND here you say normal
ptr is sufficient.

What am I misunderstanding?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bJOdna8zU511PquiU-KYuQ@comcast.com>, root
<royalmacaronipenguin@yahoo.com> writes
>
>>  So what would the type of a ctor be? AFAICT every ctor has a unique
>>type  which sort of makes its address pointless:)
>>
>
>Assuming ptr to member function was to use for ctor also:
>
>
>
>class apple {
>    int _i;
>public:
>    explicit apple():_i(8) {}
>
>    void f(int i) {....}
>};
>
>typedef void(apple::*PMF)(int);

But that is wrong. ctors do not have return types FULL STOP and it would
be an error to make it otherwise, they are fundamentally different form
member functions that return void.

>
>PMF pmf1 = &apple::apple; //take int arg for addr to initialize
>PMF pmf2 = &apple::f;


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <bJOdna8zU511PquiU-KYuQ@comcast.com>, root
> <royalmacaronipenguin@yahoo.com> writes
>
>>
>>>  So what would the type of a ctor be? AFAICT every ctor has a unique
>>> type  which sort of makes its address pointless:)
>>>
>>
>> Assuming ptr to member function was to use for ctor also:
>>
>>
>>
>> class apple {
>>    int _i;
>> public:
>>    explicit apple():_i(8) {}
>>
>>    void f(int i) {....}
>> };
>>
>> typedef void(apple::*PMF)(int);
>
>
> But that is wrong. ctors do not have return types FULL STOP and it would
> be an error to make it otherwise, they are fundamentally different form
> member functions that return void.
>
>
yeah I agree. I did hat because my compiler happens to internally define
a constructor that way. And yes I also agree that it's not the standard.

About the pointless part. I agree then.
But that doesn't answer my question "why can't we take the address of a
cotr or dtor?" Again,

According to Bjarne Stroustrup,
"The C++ Programming Language: Third Edition",
Chapter 15 Class Hierarchies, Section 5 Free Store,
Subsection 2 "Virtual Constructors", page 424:

"Furthermore, a constructor is not quite an ordinary function.
  In particular, it interacts with memory management routines
  in ways that ordinary member functions don't.
  Consequently, you cannot have a pointer to a constructor."

It doesn't sound like because it is useless that it is not allowed. BUt
can anybody elaborate what he says there?

thanks,
kn



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root wrote:

> PMF pmf1 = &apple::apple; //take int arg for addr to initialize
> PMF pmf2 = &apple::f;

pmf1 and pmf2 would have the same type, but the set of pointers they can
be called on is almost disjoint. You would need to call a constructor on
an uninitialized memory and a method on an initialized object.

IMHO it would be too easy to forget it and call the constructor on an
initialized object, which is conceptually wrong, even if it works for
POD types.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root wrote:
>
>>
>> Because they're not regular functions, and there is
>> no syntactical way to take their address. Syntax could
>> be added,
>
>
>
>
> This sounds like the kind of reasoning I'm looking for. BUt can you
> elaborate more on the part
> "they're not regular functions, and there is
>  no syntactical way to take their address"

They are "special" functions.  Constructors cannot be called by
users; they are only invoked by the new operator (not to be
confused with operator new).

> You say "....Syntax could be added", can u give me some example please.

Sure.  We could change the language to allow

struct s {};

typedef void (*no_arg_constructor)();
no_arg_constructor constructor_of_s(__constructor<no_arg_constructor>(s));

If we defined a new keyword __constructor.

It's not worth the trouble to do so, given that we can
get a similar effect trivially with function templates,
as illustrated by an example in my previous post.

>>
>>> - to support it, it needs a different mechanism from ptr to normal
>>> member functions
>>
>>
>>
>> Regular function pointers are sufficient, no need for ptmfs.
>> A constructor does not act on an existing object, it acts on
>> raw memory and converts it to an object.
>>
> The above you say ".... there is
>  > no syntactical way to take their address." AND here you say normal
> ptr is sufficient.
>
> What am I misunderstanding?

I don't know.  There is no syntax you can currently use to
take the address of a constructor, but if you could do so
then an implementation would not need the complexity of ptmfs
to store the address of a constructor.  Ptmfs are more complex
to cope with the complexities of inheritance, particularly
multiple inheritance.  To call a constructor all the compiler
needs is to know where you want an object constructed, the type
of that object, and the arguments (other than this) to pass to
the constructor.

I showed in my previous post how a normal pointer is sufficient,
given a wrapper function that uses placement new to call a
constructor.

-- James.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcin 'Qrczak' Kowalczyk wrote:
> root wrote:
>
>
>>PMF pmf1 = &apple::apple; //take int arg for addr to initialize
>>PMF pmf2 = &apple::f;
>
>
> pmf1 and pmf2 would have the same type, but the set of pointers they can
> be called on is almost disjoint. You would need to call a constructor on
> an uninitialized memory and a method on an initialized object.
>
> IMHO it would be too easy to forget it and call the constructor on an
> initialized object, which is conceptually wrong, even if it works for
> POD types.
>

how about the case of destructor for "placement new" where you can call
it for an object.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> They are "special" functions.  Constructors cannot be called by
> users; they are only invoked by the new operator (not to be
> confused with operator new).


sure. how about the case of dtor? It can and should be called in case of
the placement new


> Sure.  We could change the language to allow
>
> struct s {};
>
> typedef void (*no_arg_constructor)();
> no_arg_constructor constructor_of_s(__constructor<no_arg_constructor>(s));
>
> If we defined a new keyword __constructor.
>

Can't we just use the normal syntax for a member function since it
already exists:

no_arg_constructor constructor_of_s = &s::s;  //if s has a constructor


  There is no syntax you can currently use to
> take the address of a constructor, but if you could do so
> then an implementation would not need the complexity of ptmfs
> to store the address of a constructor.

yes but my point is that if ptr to member function is sufficient too, we
can just use it and the normal syntax used to take a member function's
address to assign to it like

typedef void(PMF*)();

PMF pmf = &apple::apple;

That is if we do NOT need an additional, special support for it, why
disallow it (both ctor and dtor)?


thanks,
kn

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root wrote:

> Francis Glassborow wrote:
> > root wrote:
> >>
> >> typedef void(apple::*PMF)(int);

This effectively takes two arguments: the "this" argument
and an integer.  I think it more likely that the type should
be one of

  void (apple::*PMF)();

or
  void (*PMF)(apple&);

... probably the latter.


> > But that is wrong. ctors do not have return types FULL STOP and it would
> > be an error to make it otherwise, they are fundamentally different form
> > member functions that return void.

I've never really understood why a constructor is
fundamentally any different from a function returning void
(syntactic issues of use aside). In practice the calling
convention used by many compilers for constructors is
exactly the same as ordinary functions returning void.

  struct X {
    static void __constructor(X& uninitialised_object);
  };


> About the pointless part. I agree then.
> But that doesn't answer my question "why can't we take the address of a
> cotr or dtor?" Again,

For a start, there's more than one sort of constructor and
destructor.

  struct B {
    virtual ~B();
  };

  B* make(); // creates some unknown derived class

  int main() {
    B* b1 = new D;
    b1->~B();   // calls D::~D() -- see below

    B* b2 = new D;
    delete b2;  // calls D::~D() and D::operator delete
  }

  struct D : B {
    void* operator new(std::size_t);
    void operator delete(void*);
  };

  B* make() { return new D; }


Add to this virtual bases (only the most derived class calls
virtual base constructors / destructors) and you have three
sorts of destructor:

  1.  Calls base class destructors but not virtual base
      destructors.

  2.  Calls base class destructors and virtual base
      destructors.

  3.  Calls base class destructors, virtual base destructors
      and operator delete.

If I take a pointer to a destructor, which one should I get?
I expect the best answer is (2), but which ever is chosen
it'll be wrong for someone.  If you really need a pointer to
a destructor, why not do something like

  template <class T> void destroy(T* t) { t->~T(); }
  int main() {
    void (*destructor)(my_type*) = &destroy<my_type>;
  }

> "Furthermore, a constructor is not quite an ordinary function.
>   In particular, it interacts with memory management routines
>   in ways that ordinary member functions don't.
>   Consequently, you cannot have a pointer to a constructor."

If the object is being allocated on the stack, someone needs
to make space on the stack for that object (typically this
has to be the caller) and pass a pointer to that memory
location.  Similarly, if the object is heap allocated,
someone needs to call operator new, and make sure the
correct operator delete is called if the constructor throws
an exception.  (Note that this deletion operator is not in
general the same one that gets called if the constructor
succeeds.)

> It doesn't sound like because it is useless that it is not allowed. BUt
> can anybody elaborate what he says there?

If pointers to constructors and/or destructors were allowed,
it would mean specifying in much more detail exactly how
memory management interacts with constructors and
destructors.  The standard currently just states what has to
be done, and is silent on most issues of who has to do them.

As I can't see any reason to want constructor / destructor
pointers, it seems better that the standard should avoid
this extra complexity by forbidding them.

--
Richard Smith

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bJOdna8zU511PquiU-KYuQ@comcast.com>,
 on Sun, 10 Aug 2003 20:33:47 +0000 (UTC),
 royalmacaronipenguin@yahoo.com (root) wrote:

>> So what would the type of a ctor be? AFAICT every ctor has a unique
>> type which sort of makes its address pointless:)
>>
>
> Assuming ptr to member function was to use for ctor also:
>
>
>
> class apple {
>      int _i;
> public:
>      explicit apple():_i(8) {}
>
>      void f(int i) {....}
> };
>
> typedef void(apple::*PMF)(int);
>
> PMF pmf1 = &apple::apple; //take int arg for addr to initialize

You need an object to bind the pointer to in order to call it. How do
you plan to do that?

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root wrote:
> Why does c++ not allow taking an address of a constructor or destructor?

Constructors and destructors are very complicated beasts. Because of
multiple and virtual inheritance, and the fact that while a *tor is
running the type of the object is the class of that *tor, invocations
of *tors do a lot of manipulation behind the scenes, and indeed they
may come in several different versions, silently selected depending
on circumstance.

Suppose you had such a pointer. What is your expected usage of it?
You may be able to use templates to get the effect you want:

     #include <memory>
     template <typename T>
     struct cdtor
     {
         static void destruct(T *p) { p->~T(); }

         static T *construct(void *p) { return new(p) T; }

         template <typename A1>
         static T *construct(void *p, A1 a1) { return new(p) T(a1); }

         template <typename A1, typename A2>
         static T *construct(void *p, A1 a1, A2 a2) { return new(p) T(a1,a2); }

         // etc.
     };

     struct A { A(int x, double y) : x(x), y(y) { } int x; double y; };

     A *(*init)(void *, int, double) = &cdtor<A>::construct<int, double>;

Variations on this theme should come readily to mind.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <bJOdna8zU511PquiU-KYuQ@comcast.com>, root
> <royalmacaronipenguin@yahoo.com> writes
>>
>>>  So what would the type of a ctor be? AFAICT every ctor has a
>>> unique type  which sort of makes its address pointless:)
>>>
>>
>>Assuming ptr to member function was to use for ctor also:
>>
>>
>>
>>class apple {
>>    int _i;
>>public:
>>    explicit apple():_i(8) {}
>>
>>    void f(int i) {....}
>>};
>>
>>typedef void(apple::*PMF)(int);
>
> But that is wrong. ctors do not have return types FULL STOP and it
> would be an error to make it otherwise, they are fundamentally
> different form member functions that return void.

In several cases, e.g. typical implementations of certain
    standard library containers, it is necessary to wrap constructors
    and destructors in functions. For this reason, I believe that the
    decision to make constructors and destructors non-functions was a
    mistake. Note - I don't think they should have been member
    functions - mem_fun and related contortions are a lesson that
    member functions never should have been made incompatible with
    non-member functions. Hopefully when / if closures are added to
    C++, the triply-repated mistake of making a function-like thing
    incompatible with functions won't be made again.



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Ev2E$vBPXrN$Ew$K@robinton.demon.co.uk>,
 francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> But that is wrong. ctors do not have return types FULL STOP and it would
> be an error to make it otherwise, they are fundamentally different form
> member functions that return void.

But are they 'fundamentally different' from a static member function
returning the constructed type?  A pointer-to-constructor would surely
be a pointer-to-function rather than a pointer-to-member-function. (A
pointer-to-destructor OTOH would obviously need to be a
pointer-to-member-function.)  Consider:

class Widget {
public:
   Widget();
   Widget(int);
   static Widget defaultWidget() { return Widget();}
};

Widget magicWidget() {return Widget(42);}

int main() {

   Widget (*widgetMaker)();

   widgetMaker = &magicWidget; //OK.
   widgetMaker = &Widget::defaultWidget; //OK.
   widgetMaker = &Widget::Widget; //Not OK.  Why not?

}

AFAICS, there is no _semantic_ reason not to allow widgetMaker to point
directly to the constructor.  The fact that the wrapper function
defaultWidget does absolutely nothing except forward the call makes this
clear.  There is however the _syntactic_ problem that the constructor
cannot be named.

Best wishes,
Matthew Collett

--
Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

root> About the pointless part. I agree then.  But that doesn't answer
root> my question "why can't we take the address of a cotr or dtor?"

Constructors and destructors interface with the implementation behind
the scenes for memory-management purposes, which means that if it were
possible to call them, they would not behave like ordinary functions.
Which means that if the standard allowed programs to call constructors
and destructors, the standards committee would have to define the
meaning of doing so.

It is not enough to say ``You should be able to take the address of a
constructor or destructor.''  In order to be able to use such an
address, you need to know how it behaves.  What is its type?  What
arguments does it take?  What result does it return?  What does it do
when you call it?

There is more than one possible way to answer these questions.  If the
standard were to allow programs to take the addresses of constructors
or destructors, the standards committee would have to decide on which
of the several possible answers was the right one.

So far, no one has justified the work involved in answering those
questions.  A justification would probably include some evidence
that the feature would be useful if implemented.

--
Andrew Koenig, ark@acm.org

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

How would you use a pointer to a constructor? Since it is a
constructor, you'd have to provide it with an uninitialized object. In
C++, you can't use an uninitialized object: before you can do anything
with an object of some class, some constructor has been executed to
initialize it:

my_class my_obj; //calls the default constructor

To call a constructor through a pointer-to-member, you'd need to
somehow refer to an object before it has been initialized. C++ is
specifically designed to make this impossible to do.

--Emil

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m.collett-CE3ED7.19152411082003@lust.ihug.co.nz>,
Matthew Collett wrote:
> In article <Ev2E$vBPXrN$Ew$K@robinton.demon.co.uk>,
>  francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>
>> But that is wrong. ctors do not have return types FULL STOP and it would
>> be an error to make it otherwise, they are fundamentally different form
>> member functions that return void.
>
> But are they 'fundamentally different' from a static member function
> returning the constructed type?  A pointer-to-constructor would surely
> be a pointer-to-function rather than a pointer-to-member-function. (A
> pointer-to-destructor OTOH would obviously need to be a
> pointer-to-member-function.)  Consider:
>
> class Widget {
> public:
>    Widget();
>    Widget(int);
>    static Widget defaultWidget() { return Widget();}
> };
>
> Widget magicWidget() {return Widget(42);}
>
> int main() {
>
>    Widget (*widgetMaker)();
>
>    widgetMaker = &magicWidget; //OK.
>    widgetMaker = &Widget::defaultWidget; //OK.
>    widgetMaker = &Widget::Widget; //Not OK.  Why not?
>
> }
>
> AFAICS, there is no _semantic_ reason not to allow widgetMaker to point
> directly to the constructor.
<snip>

Returning a Widget requires that Widget have an accessible copy
constructor, but this is not normally a requirement for construction.
A constructor turns an uninitialised region of storage into a live
object.  I think this is better expressed in the C++ type system as:

    Widget & (void *, /* usual parameters */);

or alternately:

    Widget & (char (&)[sizeof(Widget)], /* usual parameters */);

(the latter being safer, but rather hard to use).

If you want memory allocation as well as construction, then naturally
you need a wrapper.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

m.collett@auckland.ac.nz (Matthew Collett) wrote in message news:<m.collett-CE3ED7.19152411082003@lust.ihug.co.nz>...
> In article <Ev2E$vBPXrN$Ew$K@robinton.demon.co.uk>,
>  francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>
> > But that is wrong. ctors do not have return types FULL STOP and it would
> > be an error to make it otherwise, they are fundamentally different form
> > member functions that return void.
>
> But are they 'fundamentally different' from a static member function
> returning the constructed type?

Yes. Constructors don't return anything. It might seem otherwise, but
T() is not a function call which calls the constructor. It's syntax
which causes memory to be allocated, which then calls the constructor
to initialize that memory, then returns the constructed object as the
value of the expression. A constructor might be more accurately
represented as a void function that, like a non-static member
function, takes a hidden extra parameter declared as "T* this".

If a constructor actually returned a value of it's type, then the copy
constructor would, by definition, involve infinite regression. Not a
pretty sight!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>
> For a start, there's more than one sort of constructor and
> destructor.

  Can this be a way an implementation takes advantage of the fact that
constructor/destructor ptrs are not allowed?


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <slrnbjkat8.1n4.do-not-spam-benh@tin.bwsint.com>,
 do-not-spam-benh@bwsint.com (Ben Hutchings) wrote:

> > class Widget {
> > public:
> >    Widget();
> >    static Widget defaultWidget() { return Widget();}
> > };
> >
> > int main() {
> >
> >    Widget (*widgetMaker)();
> >
> >    widgetMaker = &Widget::defaultWidget; //OK.
> >    widgetMaker = &Widget::Widget; //Not OK.  Why not?
> >
> > }
> >
> > AFAICS, there is no _semantic_ reason not to allow widgetMaker to point
> > directly to the constructor.
>
> Returning a Widget requires that Widget have an accessible copy
> constructor, but this is not normally a requirement for construction.

Very true, and so there are situations where an object could be
constructed, but you could not call an ordinary function returning one.
But a semantic justification for prohibiting a pointer_to_function from
pointing to the constructor would need to be the other way round.  The
key question is this:  are there any contexts where you could call an
ordinary function returning an object but could not call a constructor?

> A constructor turns an uninitialised region of storage into a live
> object.  I think this is better expressed in the C++ type system as:
>
>     Widget & (void *, /* usual parameters */);
>
> or alternately:
>
>     Widget & (char (&)[sizeof(Widget)], /* usual parameters */);
>
> (the latter being safer, but rather hard to use).
>
> If you want memory allocation as well as construction, then naturally
> you need a wrapper.

But this is not the interface declared in the class and exposed to the
user.

Note that I am talking about client _usage_ of constructors.  I am well
aware that the implemetation details of a constructor call are very
different to those of an ordinary function.  So taking the address of a
constructor might in practice result in the implementation automatically
generating a wrapper function and then returning the address of that.

Best wishes,
Matthew Collett

--
Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:
> root> About the pointless part. I agree then.  But that doesn't answer
> root> my question "why can't we take the address of a cotr or dtor?"
>
> Constructors and destructors interface with the implementation behind
> the scenes for memory-management purposes, which means that if it were
> possible to call them, they would not behave like ordinary functions.
> Which means that if the standard allowed programs to call constructors
> and destructors, the standards committee would have to define the
> meaning of doing so.
>


  I see it for a ctor case. But how about a destructor that we can call
  for an object created with the placement new.


class apple {
  ~apple() {}
};

char buffer[1024];

apple* pa = new (buffer) apple;
pa.~apple(); //Do we refer to this as "calling a destructor"?
              //Does this destructor have a name (and address)?


thanks
kn







---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"root" <royalmacaronipenguin@yahoo.com> wrote in message
news:cPucnXOJ2paqvKqiXTWJhw@comcast.com...
>
> >
> > They are "special" functions.  Constructors cannot be called by
> > users; they are only invoked by the new operator (not to be
> > confused with operator new).
>
>
> sure. how about the case of dtor? It can and should be called in case of
> the placement new

dtor is slightly different from the constructor - you *have* an object and
call a method against it.
I might argue though that a 'placement delete' syntax would have been more
symmetric.

However, after the dtor is called the caller should not call any more
methods against that object - its gone.
This is sematically different from other member functions, which change the
internal state of the object.

Roger Orr
--
MVP in C++ at www.brainbench.com



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"root" <royalmacaronipenguin@yahoo.com> skrev i meddelandet
news:Qp6dnaiyWasjKKeiXTWJjg@comcast.com...
> Andrew Koenig wrote:
> > root> About the pointless part. I agree then.  But that doesn't
answer
> > root> my question "why can't we take the address of a cotr or
dtor?"
> >
> > Constructors and destructors interface with the implementation
behind
> > the scenes for memory-management purposes, which means that if it
were
> > possible to call them, they would not behave like ordinary
functions.
> > Which means that if the standard allowed programs to call
constructors
> > and destructors, the standards committee would have to define the
> > meaning of doing so.
> >
>
>
>   I see it for a ctor case. But how about a destructor that we can
call
>   for an object created with the placement new.
>
>
> class apple {
>   ~apple() {}
> };
>
> char buffer[1024];
>
> apple* pa = new (buffer) apple;

This might not be properly aligned. :-)

> pa.~apple(); //Do we refer to this as "calling a destructor"?

Possibly, or destructing an object.

Also, if pa is a pointer, it should be pa->~apple()

>               //Does this destructor have a name (and address)?

It might have an address, but what would you use it for? You already
have ~apple() for the destructor of this class. As a class can only
have one destructor, what use is there for a pointer to it?

A pointer-to-member or a pointer-to-member-function can conceivably
point to different members at different times, but there is only one
destructor, and only one constructor for each signature. IMO, this
*really* reduces the usefulness of a pointer-to-special-member.


Bo Persson

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]