🚀 go-pugleaf

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).

Yes, it is clearly the "right" thing to do, but it is not the case
for the same reason it is not the case in Standard C: it would break
too much existing code to make the change.


>2) Placement operators
>~~~~~~~~~~~~~~~~~~~~~~
>class Object {
>        void    operator+ // or / or whatever
>                         (Object& result, const Object& b) const;
>        void    operator* (Object& result) const;	#2
>        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.

You will have to present this idea in more detail. I can't figure out
what you are proposing. It looks like you want the function marked #2
to be some form of unary dereferencing operator, but that would change
its existing meaning of a member binary (multiplication) operator.

>3) Use of explicit keyword
>~~~~~~~~~~~~~~~~~~~~~~~~~~

>void    foo (explicit Derived* object) ...

Evidently you want this to mean that "*object" is of type "Derived"
and not of any type derived from "Derived". I guess I don't see
the utility of the declaration. You can create a type which cannot be
derived from, if that is what you want. If you don't want that, I
don't see why the author of "foo" wants to be sure no derived type
is ever passed to it. What programming problem is being solved here?

The whole idea of public derivation is that a derived type can be
used where ever a base type is expected. Why does the author of foo
want to ensure that the actual object has, for example, no additional
data, functionality, or instrumentation, when the author of Derived
has no objections to the possibility?

If for some reason you do care about the actual type of *object,
wouldn't it be enough to use an RTTI expression in the function?


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

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

For the same reason: it could cause a violation of constness without
a cast. The draft standard does allow Type** to be converted to
"Type*const*", since that cannot cause any such violation.


>Now a question:

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

> ...

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

If by "real" overloading you mean adopting the short-circuit evaluation
rules, I don't think that will (or should) happen.

When you write 
	I || Func()
it is just another way to write
	I.operator||( Func() )

Let's simplify things by considering
	A || B // A's type has an operator||
which is the same as
	A.operator||( B )

Suppose the type of A did not have any conversion to bool. You could
not evaluate the "truth" of A, and so you would have to call the
function "||" after evaluating B, no matter what the value of A.
In other words, short-circuit evaluation would not be a possibility.
But if A could be converted to bool, the same expression with the
same value of A could result in short-circuit evaluation (don't
evaluate B and don't call "||"). That sounds like a poor idea to me.
Others might disagree.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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 
]