🚀 go-pugleaf

In article <4h9se5$m2n@s3.iway.fr> Valentin Bonnard <bonnardv@pratique.fr> writes:

|> I have 4 ideas about C++ and a question.

|> 1) String literals
|> ~~~~~~~~~~~~~~~~~~
|> String literals should be const char* instead of char* (if it is not
|> already the case).

I agree.  There was some discussion about this in the committee, but
as far as I know, there was never a real proposal.

|> 2) Placement operators
|> ~~~~~~~~~~~~~~~~~~~~~~
|> class Object {
|>         void    operator+ // or / or whatever
|>                          (Object& result, const Object& b) const;
|>         void    operator* (Object& result) const;
|>         Object  operator* (const Object& result) const; // old one
|> }

|> should be called respectively by:
|> a = b + c;

|> and a = *b;

|> and (old one) a*b;

|> This will solve the [well-known] problem of copying the result into a temporary.
|> The compatibility will be preserved since old syntax will be allowed to.

Presented like this, the idea sounds good.  Now try and define it
exactly.  In which cases is which operator used, and how?  What are
the exact semantics?  I think you'll find that it introduces an
enormous amount of additional confusion in an area which is already
not particularly clear.

|> 3) Use of explicit keyword
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~
|> //========= Test.h =========
|> class Base {
|>     public:
|>         virtual void VirtualFunc ();
|> };

|> class Derived : public Base {
|>     public:
|>         void VirtualFunc () { }
|> };

|> //========= Caller.cp =========
|> #include <Test.h>
|> class Derived2 : public Derived {
|>     public:
|>         void VirtualFunc ();
|> };

|> //========= Foo.cp =========
|> #include <Test.h>

|> void    foo (explicit Derived* object)
|> {
|>     object.VirtualFunc (); // nop (compiler does not generate code for this)

|>     Derived* AnyDerivedObject = object; // ok
|> }

|> void    foo2 (Derived* object)
|> {
|>     object.VirtualFunc (); // object can be Derived2

|>     explicit Derived* RealDerivedObject = object; // error
|> }

|> The meaning of explicit could be: while a derived class ptr [resp. ref] can be
|> convert to a base class ptr [ref], it can't be converted to a base class 
|> explicit ptr [ref].

|> So explicit would be a type qualifier; this usage is different with:

Seems confusing, and I really cannot see any use for it.  If the
derived class cannot be used where ever the base class is used, you
shouldn't be using (public) derivation.

|> > Rich Hickey
|> > rich@rcs-hq.mhs.compuserve.com

|> > I propose that the explicit keyword be allowed as a qualifier of a class
|> > definition, such qualification taking the form of:

|> > explicit class X{
|> >   //the definition of X
|> >   };

|> Here, X cannot be derived but my Derived can be so I think my idea is better
|> (please fell free comment/criticise this assertion).


|> 4) Conversion of Type** to const Type**
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|> It's ok, this is an error; but why cannot Type** be converted to const Type* 
|> const* ?

|> void    foo ()
|> {
|>     typedef int Type;
|>     Type        i;
|>     const Type  ci = 2;
|>     Type*       pi = &i;
|>     Type**      ppi = &pi;

|>     const Type** ppci = ppi;            // error because
|>     *ppci = &ci;                        // now pi == &ci
|>     *pi = 0;                            // and now we modify ci

|>     const Type*const* pcpci = ppi;      // no problem because
|>     *pcpci = &ci;                       // this is impossible (since *pcpci is 
|> const)
|> }

	char const	c( 'a' ) ;
	char const*	pc( &c ) ;
	char*		p ;
	char const**	ppc( &p ) ;	//  Currently illegal, since
					//  &p has type char**, not
					//  char const**.
	*ppc = pc ;
	*p = 'b' ;			//  Guess what is accessed.

Const is violated *without* ever being cast away.

|> Now a question:

|> Will there be any way to redefine (overload) normal && or || on class ?
|> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|> I mean, now:

|> class Int {
|>     public:
|>         operator int () const { return i; }
|>         operator && (int) const;
|>         operator || (int) const;
|>         Int (int I) : i(I) { }

|>     private:
|>         int     i;
|> };

|> int     Func ()
|> {
|>     cout << "called\n";
|>     return 1;
|> }

|> void    foo ()
|> {
|>     int i (1);
|>     Int I (1);

|>     if (i || Func ()) // called is not printed
|>         ;
|>     if (I || Func ()) // called is printed
|>         ;
|> }

|> One could think that the standard should be change in order to support real
|> overloaded operator && and ||.

How?  Write a definition of how you think overloaded operator&& and ||
should work.

In the above case, IMHO, the correct solution is not to overload
operator||, but to define a conversion function for Int, e.g.:
Int::operator bool(), for example.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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 
]

Valentin Bonnard  <bonnardv@pratique.fr> wrote:
>1) String literals
>~~~~~~~~~~~~~~~~~~
>String literals should be const char* instead of char* (if it is not
>already the case).

Actually they're char[], which in practice is almost always decayed to
char*.  The reason they aren't char const[] is that a lot of existing C
code does things like `char *foo="bar";', because const didn't exist in
K&R C.

In my opinion, C++ code tends to use const correctly much more than C
code does.  (I personally always write const correctness into my C
code, but a lot of people do not, quite apart from the matter of
existing code.)  It would therefore probably not be disastrous to have
string literals have type char const[] in C++, though it would be in
C.  Maybe in the next round of standardisation?

>2) Placement operators
>~~~~~~~~~~~~~~~~~~~~~~
>class Object {
>        void    operator+ // or / or whatever
>                         (Object& result, const Object& b) const;
>        void    operator* (Object& result) const;
>        Object  operator* (const Object& result) const; // old one
>}
>
>should be called respectively by:
>a = b + c;
[...]

GCC has a better syntax for this, using a declaration "return result"
between the parameter list and the function body.  The function has a
return value in the usual way, but if it doesn't contain a return
statement with a value then the object in the return declaration is
returned.

>4) Conversion of Type** to const Type**
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>It's ok, this is an error; but why cannot Type** be converted to const Type* 
>const* ?

It can in C++, but not in C.  It is in fact safe, but the discovery of
the problem with converting T** to T const** led to the present C rule,
which was cast in stone (figuratively) before the C++ rule was
developed.

-zefram
-- 
Andrew Main <zefram@dcs.warwick.ac.uk>


[ 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
]