Thread View: comp.std.c++
2 messages
2 total messages
Started by Valentin Bonnard
Sun, 03 Mar 1996 23:34
Some ideas about C++ and a question
Author: Valentin Bonnard
Date: Sun, 03 Mar 1996 23:34
Date: Sun, 03 Mar 1996 23:34
162 lines
4681 bytes
4681 bytes
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).
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.
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:
> 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 = π
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)
}
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 ||.
I can't see the point of doing that, so if it's the case for you to don't ask
me nor criticise.
Valentin Bonnard
bonnardv@pratique.fr
[ 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
]
Re: Some ideas about C++ and a question
Author: Steve Clamage
Date: Mon, 04 Mar 1996 18:30
Date: Mon, 04 Mar 1996 18:30
111 lines
4855 bytes
4855 bytes
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
]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads