Gene Bushuyev  wrote:

> There is one thing wrong with this idea that isn't present with multiple
> constructors. We should have a reasonable and intuitive way of adding const
> to the object.
> class A
> {
>   public:
>   A();
>   A()const;
> };
> void foo()
> {
> A a = A();
> const A ca = A();
> const A& car1 = a;
> const A& car2 = ca;
> }
>
> to everybody's surprise car1 and car2 reference completely differently
> constructed objects.

I recommand that we remove short and long from C++, and only
keep int.

Having short, int and long ca lead to surprises:

void foo (int i)
{
  make_tea ();
}

void foo (long l)
{
  make_coffe ();
}

int num;
foo (num);

Now, say that you discover that you'll have to store very large
numbers in num, and change its type to long: then your previously
working program makes coffe instead of tea   !

--

Valentin Bonnard

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Valentin Bonnard" <Valentin.Bonnard@free.fr> wrote in message
news:915og8$e2o$1@nef.ens.fr...
[...]
>
> I recommand that we remove short and long from C++, and only
> keep int.
>
> Having short, int and long ca lead to surprises:
>
[...]
Though surprises are possible in many ways there is still something about
const that makes them especially naughty.
There is nothing wrong if some changes in code would add to or remove const
from the object. But since the const object can be constructed differently
now, such an operation becomes dangerous.
When functions accepts const T& it doesn't mean it expects class T created
with const constructor. It just promises not to modify it. In fact it can
break that promise. Now this function must be aware about the two different
constructors. Temporaries are always bound with const T&, but it doesn't
mean the temporary is created const.
Multiple constructors are used to allow construction from different sources,
suggestion for const constructor is to distinguish construction on the basis
of future uses. In the final analysis, const and non-const constructors
cannot know in what circumstances constructed object will be used, and
therefore one cannot discriminate construction on the basis of constness.

--
-------------------------
Gene Bushuyev
No one cares what my definition of "is" is (Bart Simpson)



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A35EE51.4837A376@cscs.ch>,
  John Kewley <kewley@cscs.ch> wrote:
> Anthony Williams wrote:
> >
> > In article <3A30A217.FC691B7B@cscs.ch>,
> >   John Kewley <kewley@cscs.ch> wrote:
> > > Anthony Williams wrote:
> > > > ...
> > > ...
> > > If I understand you correctly here, you are saying that only
mutable
> > > members can be change inside the braces. Do you mean members
declared
> > > to be mutable or members that are not declared const?
> > >
> >
> > I meant "members that are declared mutable" - i.e. once inside the
> > braces, a const constructor is just like any other const member
> > function.
> >
> > Anthony
>
> I don't believe this should be the case.
>
> The suggestion was that a const constructor should be used to
> create const objects. Obviously const and ref members need assigning
> using initialisation syntax, but all other members need initialising
> at some point and this sometimes HAS to be done "between the curlies",
> even for const objects.
>
> For subobjects and parent classes, const constructors should be called
> (if not available, is this a problem? or do normal ones get called
instead?)

I was actually trying to show that this is a potential problem with the
scenario for precisely the reason you give, since logical consistency
requires my position. e.g.:

class constConstructible
{
public:
  constConstructible() const;
  constConstructible(); // not required, but may behave differently
  someNonConstMemberFunction();
  someConstMemberFunction() const;
};

class anotherClass
{
  constConstructible cc;
  mutable constConstructible ncc;
  anotherClass() const:
    cc(),ncc()
  {
    // at this point, cc is fully constructed via it's const constructor
    // so it is now a fully-constructed const object
    // on which you can use only const member functions
    // Thus the next line should fail to compile
    cc.someNonConstMemberFunction();
    // whilst the next should be OK
    cc.someConstMemberFunction();
    // ncc is mutable, so non-const, so the next line is OK
    ncc.someNonConstMemberFunction();
  }
};

Otherwise, what we are effectively saying is that a const object is not
const until all the constructors for any objects that may contain it
are finished. Since anyone may freely create a class with a member
variable of our class type, and define a const constructor for their
class, this means that anyone can thus use non-const members on our
const object, which defeats the purpose of knowing that it's a const
object. Basically, you have to guarantee that all required
initialization for a class can be done in its (const) constructor, and
that all required initialization for its members can be done in the
member initialization list.

If you need additional functionality, to decide on the parameters to
pass to a constructor, why not define an empty local class, which
provides a member function or functions for determining these
parameters, and then pass the results of these functions as parameters
to the real member. e.g.:

class YAClass
{
private:
  class initSetStatic
  {
  public:
    static std::string getStringValue(int i)
    {
      if(i<10) return "less than 10";
      if(i==10) return "equal to 10";
      return "greater than 10";
    }
  };
  class initSetMember
  {
  public:
    int i;
    int j;
    initSetMember(int ni,int nj)const:i(ni),j(nj){}
    std::string getStringValue() const
    {
      if(i>j) return "i>j";
      if(i==j) return "i==j";
      return "i<j";
    }
  };
  std::string stringMember1;
  initSetMember ism;
  std::string stringMember2;
public:
  YAClass(int a,int b) const:
    stringMember1(initSetStatic::getStringValue(a)),
    ism(a,b),stringMember2(ism.getStringValue())
  {}
};

You can, of course, pass already-constructed member variables to these
functions as parameters if necessary.

Anthony
--
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net  -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc


Sent via Deja.com
http://www.deja.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Gene Bushuyev" <gbush@deja.com> wrote in
<t3dciekdq1jo94@corp.supernews.com>:

>"Valentin Bonnard" <Valentin.Bonnard@free.fr> wrote in message
>news:915og8$e2o$1@nef.ens.fr...
>[...]
>>
>> I recommand that we remove short and long from C++, and only
>> keep int.
>>
>> Having short, int and long ca lead to surprises:
>>
>[...]
>Though surprises are possible in many ways there is still something
>about const that makes them especially naughty.
>There is nothing wrong if some changes in code would add to or remove
>const from the object. But since the const object can be constructed
>differently now, such an operation becomes dangerous.
>When functions accepts const T& it doesn't mean it expects class T
>created with const constructor. It just promises not to modify it. In
>fact it can break that promise. Now this function must be aware about
>the two different constructors. Temporaries are always bound with const
>T&, but it doesn't mean the temporary is created const.
>Multiple constructors are used to allow construction from different
>sources, suggestion for const constructor is to distinguish construction
>on the basis of future uses. In the final analysis, const and non-const
>constructors cannot know in what circumstances constructed object will
>be used, and therefore one cannot discriminate construction on the basis
>of constness.
>

Sorry, I don't follow this. What is the difference with any class having
overloaded constructors? I mean, if I make one constructor do one thing and
another something unrelated, I'm doing something stupid, and the language
will not stop me. The same goes imho for const/non-const constructors.

M4

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Victor Bazarov" <vAbazarov@dAnai.com> wrote in message
news:90minr$h1h$1@nnrp.atgi.net...
> "MucusPig" <nospam@nospam.UCAR.EDU> wrote...
> > It would make sense to allow for a volatile and a const volatile
> version of
> > the constructors as well.
> >
> > By the way, which constructor should the following code call?
> >
> > struct S
> > {
> >     S() volatile;
> >     S() const;
> > };
> >
> > S volatile const s;

Neither; you haven't declared

S::S() volatile const;

<grin>

The rule should be orthogonal to all other uses of cv-qualifiers; a call may
be made to a more cv-qualified function, but not to a less qualified one.

--
Mike Dimmick


---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

see below.

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:9q86GEBa15L6Ew8O@ntlworld.com...
[snip]
> BTW, why do people argue that const ctors are pointless because there is
> no distinction in the construction of const and non const instances? We
> allow objects to have multiple ctors, some of those can even depend on
> the const qualifications of some of the parameters. We allow this
> because we know that there are multiple ways of constructing objects. At
> the same time we know that the type of a const X is different from the
> type of X, so why is it wrong to consider allowing const ctors?

There is one thing wrong with this idea that isn't present with multiple
constructors. We should have a reasonable and intuitive way of adding const
to the object.
class A
{
  public:
  A();
  A()const;
};
void foo()
{
A a = A();
const A ca = A();
const A& car1 = a;
const A& car2 = ca;
}

to everybody's surprise car1 and car2 reference completely differently
constructed objects. I don't think anybody would like to have such
surprises. Another thing, imagine, in a working program an object was
changed from non-const to const. Oops, the program is no longer working.
I think it's in the nature of const object to be constructed the same way
non-const object is constructed. Desiring the opposite sugests some design
flaw.

Gene Bushuyev
--------------------
"I did not invent Internet"(me)

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

John Kewley  wrote:
> Anthony Williams wrote:

>> For const constructors, you could initialize data members differently,
>> knowing that once a value was set it would be immutable (unless
>> explicitly declared mutable). Note that class-type data members would
>> have their const constructors called too, unless they were mutable.
>>
>> The consequence of this is that if a class member was constructed as
>> const, then once its constructor had exited, then it would be const,
>> and immutable, which would mean that any code inside the braces of a
>> const constructor would only be able to modify mutable members.
>
> If I understand you correctly here, you are saying that only mutable
> members can be change inside the braces. Do you mean members declared
> to be mutable or members that are not declared const?

He means only members declared with the mutable keyword.

But actually, every members w/o const ctors could be changed
w/o breaking the system.

--

Valentin Bonnard

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A30A217.FC691B7B@cscs.ch>,
  John Kewley <kewley@cscs.ch> wrote:
> Anthony Williams wrote:
> > ...
> > For const constructors, you could initialize data members
differently,
> > knowing that once a value was set it would be immutable (unless
> > explicitly declared mutable). Note that class-type data members
would
> > have their const constructors called too, unless they were mutable.
> >
> > The consequence of this is that if a class member was constructed as
> > const, then once its constructor had exited, then it would be const,
> > and immutable, which would mean that any code inside the braces of a
> > const constructor would only be able to modify mutable members.
>
> If I understand you correctly here, you are saying that only mutable
> members can be change inside the braces. Do you mean members declared
> to be mutable or members that are not declared const?
>

I meant "members that are declared mutable" - i.e. once inside the
braces, a const constructor is just like any other const member
function.

Anthony

--
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net  -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

(Please don't overquote=A0!)

Richard Damon wrote:
=20
> Probably ambiguous just like
>=20
> struct S
> {
>     foo() volatile;
>     foo() const;
> };
>=20
> int main() {
>   S s;
>   s.foo();
> }


This isn't ambiguous, as there is no viable function=20
to be called: a cv-qualify ctor cannot construct a=20
non cv-qualified object, *that's the point of this=20
feature*=A0!

--=20

Valentin Bonnard

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <976316261.26113.4.nnrp-14.d4e5bde1@news.demon.co.uk>, Mike
Dimmick <mike@dimmick.demon.co.uk> writes
>Neither; you haven't declared
>
>S::S() volatile const;
>
><grin>
>
>The rule should be orthogonal to all other uses of cv-qualifiers; a call may
>be made to a more cv-qualified function, but not to a less qualified one.

Unfortunately that would break existing code, which is why I suggested
the inverse of the normal rule.



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <AkAY5.290$It.125429@news.pacbell.net>, Gene Bushuyev
<gbush@deja.com> writes
>There is one thing wrong with this idea that isn't present with multiple
>constructors. We should have a reasonable and intuitive way of adding const
>to the object.
>class A
>{
>  public:
>  A();
>  A()const;
>};
>void foo()
>{
>A a = A();
>const A ca = A();
>const A& car1 = a;
>const A& car2 = ca;
>}
>
>to everybody's surprise car1 and car2 reference completely differently
>constructed objects. I don't think anybody would like to have such
>surprises. Another thing, imagine, in a working program an object was
>changed from non-const to const. Oops, the program is no longer
working.
>I think it's in the nature of const object to be constructed the same
way
>non-const object is constructed. Desiring the opposite sugests some
design
>flaw.,

Sorry, but I do not follow your argument. car1 and car2 already
reference different types of objects because only one of them is
physically const (you can safely cast away the const from the other)

IOWs the compiler already distinguishes between const and non-const
objects.



Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Anthony Williams wrote:
>
> In article <3A30A217.FC691B7B@cscs.ch>,
>   John Kewley <kewley@cscs.ch> wrote:
> > Anthony Williams wrote:
> > > ...
> > ...
> > If I understand you correctly here, you are saying that only mutable
> > members can be change inside the braces. Do you mean members declared
> > to be mutable or members that are not declared const?
> >
>
> I meant "members that are declared mutable" - i.e. once inside the
> braces, a const constructor is just like any other const member
> function.
>
> Anthony

I don't believe this should be the case.

The suggestion was that a const constructor should be used to
create const objects. Obviously const and ref members need assigning
using initialisation syntax, but all other members need initialising
at some point and this sometimes HAS to be done "between the curlies",
even for const objects.

For subobjects and parent classes, const constructors should be called
(if not available, is this a problem? or do normal ones get called instead?)

--
John M. Kewley                             Tel: +41 (0) 91 610 8248
Senior Scientist                           Fax: +41 (0) 91 610 8282
Swiss Center for Scientific Computing      mailto:John.Kewley@cscs.ch
Via Cantonale, CH-6928 Manno, Switzerland  http://www.cscs.ch/%7Ekewley/

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A2E61DB.48332801@sensor.com>, Ron Natalie <ron@sensor.com>
writes
>In C++, constness doesn't have any bearing on object creation or deletion.

No, it doesn't because we do not have the ability to const qualify a
ctor, if we had that ability then it could have an affect and I know
some programmers think it would benefit them.

>

Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a2ec8cd$1_1@news.nwlink.com>, MucusPig
<nospam@nospam.UCAR.EDU> writes
>It would make sense to allow for a volatile and a const volatile version of
>the constructors as well.
>
>By the way, which constructor should the following code call?
>
>struct S
>{
>    S() volatile;
>    S() const;
>};
>
>S volatile const s;

ambiguity because it cannot select.

BTW, why do people argue that const ctors are pointless because there is
no distinction in the construction of const and non const instances? We
allow objects to have multiple ctors, some of those can even depend on
the const qualifications of some of the parameters. We allow this
because we know that there are multiple ways of constructing objects. At
the same time we know that the type of a const X is different from the
type of X, so why is it wrong to consider allowing const ctors?


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:90me4u$9nf$1@panix3.panix.com...
>
> And the "good enough case" would also have to demonstrate
> what it would even mean, as some would argue it would have
> no distinguishable meaning ("object creation is object creation").
>

It would mean, that the object knows on construction that it will never
change, which could be used to open the resources which the object will
associate with in "readonly" modes.

It could also be useful to define a "const" version of the object, with
implicit const members:

class A
{
 B &m_b;
 A(B &b) : m_b(b) {} // m_b is a B &
 A(const B &b) const : m_b(b) {} // this works, since m_b is a const B &
now!!
};

void foo(B &b, const B &bc)
{
 A a(b);
 const A ac(bc); // also okay.
}


--
-- Marco

dig @138.195.138.195 goret.org. axfr | grep '^c..\..*A' | sort |
cut -b5-36
| perl -e 'while(<>){print pack("H32",$_)}' | gzip -d



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"MucusPig" <nospam@nospam.UCAR.EDU> wrote...
> It would make sense to allow for a volatile and a const volatile
version of
> the constructors as well.
>
> By the way, which constructor should the following code call?
>
> struct S
> {
>     S() volatile;
>     S() const;
> };
>
> S volatile const s;

First the volatile one, then the const one :-)

Victor
--
Please remove capital A's from my address when replying by mail





---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Anthony Williams wrote:
> ...
> For const constructors, you could initialize data members differently,
> knowing that once a value was set it would be immutable (unless
> explicitly declared mutable). Note that class-type data members would
> have their const constructors called too, unless they were mutable.
>
> The consequence of this is that if a class member was constructed as
> const, then once its constructor had exited, then it would be const,
> and immutable, which would mean that any code inside the braces of a
> const constructor would only be able to modify mutable members.

If I understand you correctly here, you are saying that only mutable
members can be change inside the braces. Do you mean members declared
to be mutable or members that are not declared const?

Cheers,

--
John M. Kewley                             Tel: +41 (0) 91 610 8248
Senior Scientist                           Fax: +41 (0) 91 610 8282
Swiss Center for Scientific Computing      mailto:John.Kewley@cscs.ch
Via Cantonale, CH-6928 Manno, Switzerland  http://www.cscs.ch/%7Ekewley/

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Why is it not possible to distinguish between construction of const and
non const object?
#include <iostream>
struct test {
void init() { std::cout << " construct object " << std::endl; }
void init() const { std::cout << "construct const object " << std::endl;
}
void done() { std::cout << "destruct object " << std::endl; }
void done() const { std::cout << "destruct const object" << std::endl; }
test() { init(); }
//test() const  { init(); }   // error, constructor cannot be const
~test() { done(); }
// ~test() const { done(); }   // error, destructor cannot be const
};
int main() {
test  t;
const test  tc;
}

 output :

 construct object
 construct object
destruct object
destruct object


 I would like to have such possibility. What are the reason not too ?
I understand that regular constructor should have possibility to
initialize members of const object, but it doesn't seem to be the reason
not to
have const constructor like above.

--

@@@@ grzegorz

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A2DA12B.7A53D565@jps.net>, grzegorz <grzegorz@jps.net>
writes
>Why is it not possible to distinguish between construction of const and
>non const object?

Because at the time the Standards committees did not think it
worthwhile. If enough people think otherwise and can put up a good
enough case, I do not see why it should not be possible to add at some
future date. However there would need to be a rule that in the absence
of a const version of a ctor, the non-const version would be used (but
not the other way round)


Francis Glassborow      Association of C & C++ Users
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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

grzegorz wrote:
>
> Why is it not possible to distinguish between construction of const and
> non const object?

Why do you want to distinguish this?

In C++, constness doesn't have any bearing on object creation or deletion.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <T1RBRrBuQmL6Ewp7@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <3A2DA12B.7A53D565@jps.net>, grzegorz <grzegorz@jps.net>
>writes
>>Why is it not possible to distinguish between construction of const and
>>non const object?
>
>Because at the time the Standards committees did not think it
>worthwhile. If enough people think otherwise and can put up a good
>enough case, I do not see why it should not be possible to add at some
>future date. However there would need to be a rule that in the absence
>of a const version of a ctor, the non-const version would be used (but
>not the other way round)

And the "good enough case" would also have to demonstrate
what it would even mean, as some would argue it would have
no distinguishable meaning ("object creation is object creation").

- Greg
--
Comeau Computing / Comeau C/C++ "so close" 4.2.44 betas NOW AVAILABLE
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

It would make sense to allow for a volatile and a const volatile version of
the constructors as well.

By the way, which constructor should the following code call?

struct S
{
    S() volatile;
    S() const;
};

S volatile const s;

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:T1RBRrBuQmL6Ewp7@ntlworld.com...
> In article <3A2DA12B.7A53D565@jps.net>, grzegorz <grzegorz@jps.net>
> writes
> >Why is it not possible to distinguish between construction of const and
> >non const object?
>
> Because at the time the Standards committees did not think it
> worthwhile. If enough people think otherwise and can put up a good
> enough case, I do not see why it should not be possible to add at some
> future date. However there would need to be a rule that in the absence
> of a const version of a ctor, the non-const version would be used (but
> not the other way round)
>
>
> Francis Glassborow      Association of C & C++ Users
> 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.research.att.com/~austern/csc/faq.html                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <90me4u$9nf$1@panix3.panix.com>,
  comeau@comeaucomputing.com wrote:
> In article <T1RBRrBuQmL6Ewp7@ntlworld.com>,
> Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
> >In article <3A2DA12B.7A53D565@jps.net>, grzegorz <grzegorz@jps.net>
> >writes
> >>Why is it not possible to distinguish between construction of const
and
> >>non const object?
> >
> >Because at the time the Standards committees did not think it
> >worthwhile. If enough people think otherwise and can put up a good
> >enough case, I do not see why it should not be possible to add at
some
> >future date. However there would need to be a rule that in the
absence
> >of a const version of a ctor, the non-const version would be used
(but
> >not the other way round)
>
> And the "good enough case" would also have to demonstrate
> what it would even mean, as some would argue it would have
> no distinguishable meaning ("object creation is object creation").

Declaring just const constructors would prevent the creation of non-
const objects of that type. Declaring const and non-const constructors
with different signatures would force users to use a specific
constructor depending whether the object was const or not. Here I
disagree with Francis on the ideal behaviour - the const constructor
should be used for non-const objects if there was no non-const
constructor, like other const member functions, rather than vice-versa -
 but I can see that this would break all C++ code in existence, so is
not very practical.

For const constructors, you could initialize data members differently,
knowing that once a value was set it would be immutable (unless
explicitly declared mutable). Note that class-type data members would
have their const constructors called too, unless they were mutable.

The consequence of this is that if a class member was constructed as
const, then once its constructor had exited, then it would be const,
and immutable, which would mean that any code inside the braces of a
const constructor would only be able to modify mutable members.

Anthony
--
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net  -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I think that if the const version of a class has to be so different from
the non const one that it needs different constructors and destructors,
you should consider having two classes. Inheritance and templates can
then help you avoid code duplication.

Best regards,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Probably ambiguous just like

struct S
{
    foo() volatile;
    foo() const;
};

int main() {
  S s;
  s.foo();
}
"MucusPig" <nospam@nospam.UCAR.EDU> wrote:

>It would make sense to allow for a volatile and a const volatile version of
>the constructors as well.
>
>By the way, which constructor should the following code call?
>
>struct S
>{
>    S() volatile;
>    S() const;
>};
>
>S volatile const s;
>
>Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
>news:T1RBRrBuQmL6Ewp7@ntlworld.com...
>> In article <3A2DA12B.7A53D565@jps.net>, grzegorz <grzegorz@jps.net>
>> writes
>> >Why is it not possible to distinguish between construction of const and
>> >non const object?
>>
>> Because at the time the Standards committees did not think it
>> worthwhile. If enough people think otherwise and can put up a good
>> enough case, I do not see why it should not be possible to add at some
>> future date. However there would need to be a rule that in the absence
>> of a const version of a ctor, the non-const version would be used (but
>> not the other way round)
>>
>>
>> Francis Glassborow      Association of C & C++ Users
>> 64 Southfield Rd
>> Oxford OX4 1PA          +44(0)1865 246490
>> All opinions are mine and do not represent those of any organisation

--
richard_damon@iname.com (Redirector to my current best Mailbox)
rdamon@beltronicsInspection.com (Work Adddress)
Richad_Damon@msn.com (Just for Fun)

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

On Thu,  7 Dec 2000 17:42:08 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:

> BTW, why do people argue that const ctors are pointless because there is
> no distinction in the construction of const and non const instances? We
> allow objects to have multiple ctors, some of those can even depend on
> the const qualifications of some of the parameters. We allow this
> because we know that there are multiple ways of constructing objects. At
> the same time we know that the type of a const X is different from the
> type of X, so why is it wrong to consider allowing const ctors?

Here is an old work-around for the ctor.

struct S {
   int i;
   S (S&, int v) : i(v) { cout << "non-const ctor\n"; }
   S (S const&, int v) : i(v + v) { cout << "const ctor\n"; }
   };
int main () {
   S s1(s1, 21);
   S const s2(s2, 21);
   cout << s1.i << ' ' << s2.i << '\n';
   }

If you can't get a const* this, use a const&.

For amusement only? :)

John

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]