Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++14: Papers

Reply
Thread Tools

C++14: Papers

 
 
James Kanze
Guest
Posts: n/a
 
      05-29-2013
On Thursday, May 23, 2013 9:27:18 PM UTC+1, Stefan Ram wrote:
> Jorgen Grahn <(E-Mail Removed)> writes:
> >On Tue, 2013-04-16, Sam wrote:
> >>I don't think there's anything inherently wrong with "most classes derive
> >>from object". Having an object superclass does have many advantages.

> >For those of us who have spent too much time with C++, what would
> >those advantages be?


> In C, void * effectively is a supertype of all pointers. So when
> you want to write a function for any kind of pointer, you can use:


> f( void * );


> . In Java, java.lang.Object is a supertype of all reference types.
> By this, they can enforce that every object implements toString(),
> which make debugging easier: You can print any object o, by printing
> the string o.toString(). When you overwrite toString() in your new
> class, standard functions immediately start to use this. When it makes
> no sense to overwrite a java.lang.Object method in a new class, that
> method can usually just be ignored without harm. So one is not forced
> to always implement every java.lang.Object method for every little new
> class.


Java's java.lang.Object.toString() is exactly the equivalent of
ostream:perator<<( void* ). In other words, totally useless.

--
James
 
Reply With Quote
 
 
 
 
Tobias Müller
Guest
Posts: n/a
 
      05-30-2013
James Kanze <(E-Mail Removed)> wrote:
> Java's java.lang.Object.toString() is exactly the equivalent of
> ostream:perator<<( void* ). In other words, totally useless.


Not at all:
- toString() is a dynamically dispatched method (aka virtual member
function), while operator<<(void*) is just an ordinary function with no
dynamic dispatch on the parameter.
- toString() creates a string while operator<<(void*) writes to a stream.

But I agree that a specialized interface would be much better in the Java
case.

But a root type like object in Java is probably still necessary for the
same reason we have void* in C++, to cast around pointers (references in
Java).
To come back to topic, if you look at 'void' as a zero-sized implicit root
type that inhabits every other C++ type, you are probably not that far from
reality.

Actually, with modern, templatized C++ you mostly get away without having
to use void*. I don't know if this is also true for Java generics. Anyway,
Java's object dates back when generics were not yet part of the language.

Tobi
 
Reply With Quote
 
 
 
 
Tiib
Guest
Posts: n/a
 
      05-30-2013
On Thursday, 30 May 2013 00:38:50 UTC+3, James Kanze wrote:
> On Friday, May 24, 2013 1:02:08 AM UTC+1, Tiib wrote:
> > It means basically standardizing some common virtuals like 'equals',
> > 'swap', 'clone', 'dump' and 'hash'. On most cases those could be made
> > to default to something that makes sense:
> > 'T* T::clone() const {return new T(*this);}'

>
> I'm afraid I don't see the logic here. Consider equals. In
> C++, this is spelled operator==, and it is implemented over a
> large number of object types (like int, double, etc.). Making
> everything derive from Object, and have a virtual function
> equals, however, doesn't make sense: it means that you can
> compare the incomparable, and only get an error at runtime,
> rather than from the compiler.


The incomparable objects are not equal. Why it does not make sense?
I avoided operator== because that requires the objects to be
comparable or convertible to comparable.

I nowhere said that everything should derive from object. Only
the classes that for whatever reason have virtual functions can
be made to implicitly derive from object. The feature as I see it is
questionable feature for close to zero cost.

> Similar comments apply to all of
> the functions you define: they don't make sense across unrelated
> types (and in some cases, don't make sense at all).


Most examples were common unary operations so why across different
types? Copy assignment and copy constructor do not also make sense
at all on lot of cases.

> Not to mention that most classes in (well written) C++ don't
> have virtual functions.


So such classes do not get those things that do not make sense
for them.

> > The advantages (and disadvantages) of it can be similar to other
> > implicitly available things. There is number of such things in C++
> > (like copy constructor or assignment operator) already. Sometimes these
> > are helpful.

>
> Things like copy construction and assignment were originally
> only present for reasons of C compatibility.


Regardless, we have now something. Something that is sometimes good to
have.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-31-2013
On Thursday, May 30, 2013 10:59:08 AM UTC+1, Tiib wrote:
> On Thursday, 30 May 2013 00:38:50 UTC+3, James Kanze wrote:
> > On Friday, May 24, 2013 1:02:08 AM UTC+1, Tiib wrote:
> > > It means basically standardizing some common virtuals like 'equals',
> > > 'swap', 'clone', 'dump' and 'hash'. On most cases those could be made
> > > to default to something that makes sense:
> > > 'T* T::clone() const {return new T(*this);}'


> > I'm afraid I don't see the logic here. Consider equals. In
> > C++, this is spelled operator==, and it is implemented over a
> > large number of object types (like int, double, etc.). Making
> > everything derive from Object, and have a virtual function
> > equals, however, doesn't make sense: it means that you can
> > compare the incomparable, and only get an error at runtime,
> > rather than from the compiler.


> The incomparable objects are not equal. Why it does not make sense?


It makes sense. And comparing void* does that in C++.

> I avoided operator== because that requires the objects to be
> comparable or convertible to comparable.


> I nowhere said that everything should derive from object. Only
> the classes that for whatever reason have virtual functions can
> be made to implicitly derive from object. The feature as I see it is
> questionable feature for close to zero cost.


In real applications, there will be a number of "generic" base
classes: Serializable, etc. But it makes more sense to me for
the application to define them. The fact that I write class
Something shouldn't automatically lead to any inheritance.

> > Similar comments apply to all of
> > the functions you define: they don't make sense across unrelated
> > types (and in some cases, don't make sense at all).


> Most examples were common unary operations so why across different
> types? Copy assignment and copy constructor do not also make sense
> at all on lot of cases.


Exactly. The only reason they exist is for reasons of C
compatility.

> > Not to mention that most classes in (well written) C++ don't
> > have virtual functions.


> So such classes do not get those things that do not make sense
> for them.


> > > The advantages (and disadvantages) of it can be similar to other
> > > implicitly available things. There is number of such things in C++
> > > (like copy constructor or assignment operator) already. Sometimes these
> > > are helpful.


> > Things like copy construction and assignment were originally
> > only present for reasons of C compatibility.


> Regardless, we have now something. Something that is sometimes good to
> have.


And usually leads to errors, since the default copy constructor
and assignment operator don't do what we want.

--
James
 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      05-31-2013
On Friday, May 31, 2013 9:00:41 AM UTC-5, James Kanze wrote:
> On Thursday, May 30, 2013 10:59:08 AM UTC+1, Tiib wrote:
>
>
> > I avoided operator== because that requires the objects to be
> > comparable or convertible to comparable.

>
> > I nowhere said that everything should derive from object. Only
> > the classes that for whatever reason have virtual functions can
> > be made to implicitly derive from object. The feature as I see it is
> > questionable feature for close to zero cost.

>
>
> In real applications, there will be a number of "generic" base
> classes: Serializable, etc. But it makes more sense to me for
> the application to define them. The fact that I write class
> Something shouldn't automatically lead to any inheritance.
>


I think you had it right with "Not to mention that most
classes in (well written) C++ don't have virtual functions."
A lot of classes need to be serialized, but they don't need
to inherit from a "Serializable" base class. A lot of classes
benefit from being move constructed, but not via a "Movable"
base class.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
2nd Call for Papers | Extended deadline: April 07 |CENTERIS'2009 - Conference on ENTERprise Information Systems | 2nd Callfor Papers CENTERIS'2009 - Conference on ENTERprise Information Systems Python 0 03-16-2009 01:59 PM
Submitted papers for the Conference: 489. Accepted papers: 158. Fromthem 6 BEST papers are also accepted to the WSEAS journals Kostas I. C++ 0 11-29-2007 11:03 AM
Submitted papers for the Conference: 489. Accepted papers: 158. Fromthem 6 BEST papers are also accepted to the WSEAS journals shuchen. C Programming 0 11-29-2007 10:59 AM
call for papers INFO VHDL 0 08-20-2003 07:24 PM
DesignCon 2004 Call for Papers J. Bhasker VHDL 0 08-05-2003 04:13 PM



Advertisments