Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

C++14: Papers

 
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-08-2013
On Tue, 2013-05-07, Joshua Maurice wrote:
> On Apr 7, 4:09*am, Rui Maciel <(E-Mail Removed)> wrote:

....
>> I would go a slightlly different route: stop adding library stuff to the
>> standard, and instead make them available through Boost or a Boost-like
>> library aggregator service with a license that authorizes all forms of use.
>> There is absolutely no need to standardize a component if it's possible to
>> freely download and install it on any computer, or even store the source
>> files in the project tree.

>
> I work at a company that regularly does Java and C++, and I feel that
> one of the best advantages of Java over C++ is it's amazing and big
> standard library. (Not to say that Java is better than C++.) In C++,
> it seems to be the default in many places to roll your own, or hope
> there's a free library online that has a compatible license that also
> happens to run on all of the platforms you care about.


Python and Perl versus C and C++ in my case, but yes it's a difference.

And not only is it like that, but I seem to happy about it! Reinventing
custom wheels, not being locked into an unsuitable framework, and so on.

Sometimes this worries me -- after all I get paid to get things done.
Long-term productivity effects should decide if I use lots of canned
code, not just how fun it is.

On the other hand it's offputting hearing about Java people memorizing
new frameworks all the time, and seeing the stacktraces some of that
software produces (the one from Eclipse I'm staring at right now is 50
levels deep, and I'm sure I've seen 100 and more).

> Downloading a
> third party library, configuring it, and integrating it is nontrivial,
> unlike using Java's standard library which is trivial.


It's slightly different on Linux. There are large functional areas where
- there is a well-known library
- a sane version has already been integrated by the distribution
- there's at least security support
- the license is known and most likely one of GPL, LGPL, or something
more permissive

[snip]

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
Joshua Maurice
Guest
Posts: n/a
 
      05-08-2013
On May 8, 12:47*am, Jorgen Grahn <(E-Mail Removed)> wrote:
> And not only is it like that, but I seem to happy about it! Reinventing
> custom wheels, not being locked into an unsuitable framework, and so on.
>
> Sometimes this worries me -- after all I get paid to get things done.
> Long-term productivity effects should decide if I use lots of canned
> code, not just how fun it is.


I don't understand this. In C and C++, if we added something like
sockets to the standard library, that doesn't stop you from rolling
your own. I'd assume the system calls would still be there, and the
old APIs would probably survive for forever as well. This doesn't make
any sense to me. Do you think that pthreads is going anywhere because
C and C++ have both standardized a new threading API? Am I missing
something?

Even in Java, if I don't like the way Java does something in a
standard library, I can use JNI to do it my way if I really needed to
or wanted to. (At least for most cases.)
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-08-2013
On Wed, 2013-05-08, Joshua Maurice wrote:
> On May 8, 12:47*am, Jorgen Grahn <(E-Mail Removed)> wrote:
>> And not only is it like that, but I seem to happy about it! Reinventing
>> custom wheels, not being locked into an unsuitable framework, and so on.
>>
>> Sometimes this worries me -- after all I get paid to get things done.
>> Long-term productivity effects should decide if I use lots of canned
>> code, not just how fun it is.

>
> I don't understand this. In C and C++, if we added something like
> sockets to the standard library, that doesn't stop you from rolling
> your own. I'd assume the system calls would still be there, and the
> old APIs would probably survive for forever as well. This doesn't make
> any sense to me. Do you think that pthreads is going anywhere because
> C and C++ have both standardized a new threading API? Am I missing
> something?


Yes -- that I wasn't talking about growing the standard library or not;
I was talking about my own (and others') reluctance to use ready-made
components, no matter where they come from.

I deliberately avoided entering the "should the standard library be
big or small?" discussion.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-18-2013
On Sun, 2013-04-28, Ike Naar wrote:
> On 2013-04-27, James Kanze <(E-Mail Removed)> wrote:
>> I live in the real world.

>
> So does everybody else.


(Late reply, and I haven't followed the whole thread so I lack some
context.)

It's still a useful distinction. There's a conflict between

- Getting things done short-term, earning a living and solving actual
problems -- "problems" being defined as something, when you fix it,
people are happier for it.

- Seeing ways to make this easier long-term by using different
technology, although you cannot be sure until you've tried it, and
it would have negative effects short-term.

- Having fun with new technology, feeling modern and cool or building
a better-looking CV ... things which are beneficial to /you/ but not
necessarily to whoever is paying you.

- Being content with knowing and using your current tools well,
like the professionals in older days.

I understood "live in the real world" as being focused on the the
/usefulness/ aspect of work, possibly rather short-term.

People and teams have different tendencies. I've worked in very
conservative teams, and I've worked with people who are really mostly
interested in the "fun" aspect. I've worked with people who resist
all change, and with others who tend to set their hopes to new
unproven tools.

I'm often unsure where I am on the scale. I tend to think of myself
as conservative, but there are certainly things which are too
conservative for me (or I'd still stick to C like most programmers I
know). And sometimes I find myself doing work which is fun but not
strictly needed ...

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-23-2013
On Tue, 2013-04-16, Sam wrote:
....
>> On 16/04/2013 12:21, James Kanze wrote:
>>> (In the early days of C++, there were some who did try to
>>> implement the "everything derives from Object" philosophy, with
>>> boxing for the predefined types. Experience showed that it
>>> wasn't a good idea. At all.)

>>
>> And yet C# does it...
>>
>> I must admit I don't really like it (along with the insistence that a class
>> only ever derives behaviour from one other) but I suspect they put it in for
>> the early versions, where the collections held Objects without any further
>> specification.

>
> 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? Based on what you write below, you seem to
describe a system where even logically unrelated classes derive from
object, but small/numerous objects may be exempted.

> The problem, I think is when "most" become "all". The various advantages
> that come with a superclass come at a cost, and if you do not need any of
> those advantages, you should not have to pay that cost.


I have no real experience with statically typed languages with objects
except for C++, so I may be missing something.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-23-2013
On Thu, 2013-05-23, Jorgen Grahn wrote:
> 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

....

I got carried away and responded to a 5 weeks old posting in a rather
long thread. Sorry. I would not have followed up if I had remembered
to check the date -- it's not fair to ask the original author to revisit
the debate again.

Time to use my newsreader's 'catchup' facility, I suppose.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      05-23-2013
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.

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      05-24-2013
On Thursday, 23 May 2013 21:34:27 UTC+3, Jorgen Grahn wrote:
> On Tue, 2013-04-16, Sam wrote:
> >> On 16/04/2013 12:21, James Kanze wrote:
> >>> (In the early days of C++, there were some who did try to
> >>> implement the "everything derives from Object" philosophy, with
> >>> boxing for the predefined types. Experience showed that it
> >>> wasn't a good idea. At all.)
> >>
> >> And yet C# does it...
> >>
> >> I must admit I don't really like it (along with the insistence that a
> >> class only ever derives behaviour from one other) but I suspect they put
> >> it in for the early versions, where the collections held Objects without
> >> any further specification.

> >
> > 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? Based on what you write below, you seem to
> describe a system where even logically unrelated classes derive from
> object, but small/numerous objects may be exempted.


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);}'

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.

RTTI is currently used for IMHO lot uglier things like 'dynamic_cast<>'
and 'typeid'. I don't know any C++ compilers that implement virtual
functions and RTTI with using something else but vtable pointer. Since
that thing is already there then few fixed entries in pointed at vtable
could be reserved for such implicit virtual functions.

Also the feature could be made optional if someone really has millions
of polymorphic classes but does not need those functions.
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      05-24-2013
On 4/17/2013 12:20 AM, Sam wrote:
> I don't think there's anything inherently wrong with "most classes
> derive from object".


I do.

>Having an object superclass does have many advantages.


Like? Please list thee of the "many". Or at least one.


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-29-2013
On Friday, May 24, 2013 1:02:08 AM UTC+1, Öö Tiib wrote:
> On Thursday, 23 May 2013 21:34:27 UTC+3, Jorgen Grahn wrote:
> > On Tue, 2013-04-16, Sam wrote:
> > >> On 16/04/2013 12:21, James Kanze wrote:
> > >>> (In the early days of C++, there were some who did try to
> > >>> implement the "everything derives from Object" philosophy, with
> > >>> boxing for the predefined types. Experience showed that it
> > >>> wasn't a good idea. At all.)


> > >> And yet C# does it...


> > >> I must admit I don't really like it (along with the insistence that a
> > >> class only ever derives behaviour from one other) but I suspect theyput
> > >> it in for the early versions, where the collections held Objects without
> > >> any further specification.


> > > 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? Based on what you write below, you seem to
> > describe a system where even logically unrelated classes derive from
> > object, but small/numerous objects may be exempted.


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

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

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

--
James
 
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