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
 
      04-14-2013
On Wednesday, April 10, 2013 2:46:39 PM UTC+1, Scott Lurndal wrote:
> James Kanze <(E-Mail Removed)> writes:


> >With the major difference that there doesn't seem to be any new
> >competition. C++ seems to have beat out Ada-95, and in a more
> >distant past, Objective-C and Modula-3, but since then, there's
> >not really been any new language which realistically attempts to
> >replace it. If something new does come along, that is to C++
> >what Python is to Perl, I'd jump on it, but I don't see it
> >happening. In the case of C++, the total is simply too large:
> >in the time it would take to redesign a new language with all of
> >the expressivity of C++, but clean, simple and elegant, C++ will
> >have added new functionality that are missing in the new
> >language.


> One could argue that Java is the "python to perl" for C++. It is much
> cleaner (or was prior to java 7) than C++, more maintainable and more
> readable.


Java's "cleaner" because it doesn't try to address many of the
issues C++ addresses. It's actually an interesting case: where
C++ has a less than optimal solution to a problem, Java solves
it by pretending that the problem doesn't exist, and banishing
all solutions to it. Thus, for example, in a large project, you
definitely want to keep the public interface definition (the
class definition) is a separate file from the implementation
code. The C++ solution is probably about the worst one could
conceive of: textual inclusion of the class definition, the
requirement that private data members be defined, etc. But
Java's answer wasn't to create a better solution; it was to
totally forbid the practice, even though it is clearly
desirable. (I know, there are work-arounds: in Java, you define
an interface or an abstract class, with static factory functions
to construct the actual objects. It can usually be made to
work, but it's not really flexible enough.)

> The obvious downsides are bytecode and non-determinism which
> are antithetical to many classes of problems that are solved by C++.


I don't think byte code has much to do with it (although it does
mean that you can't test your program in all of the possible
environments in which it might run). And Java is actually less
non-deterministic than C++---you need garbage collection to be
truly deterministic, for example.

--
James
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-14-2013
On Wednesday, April 10, 2013 4:45:35 PM UTC+1, Jorgen Grahn wrote:
> On Wed, 2013-04-10, James Kanze wrote:


[...]
> Or "in the time it would take to redesign a new language with all of
> the expressivity of C++, but clean, simple and elegant, the new
> language would become no more clean, simple or elegant than C++".


There's something to that, but I think it's more: in the time
it would take to design a new language with all of the
expressivity of C++, but clean, simple and elegant, our
understanding of what is required in the language will have
evolved so that the new language would not meet the new
criteria.

The reason for C++'s success is certainly not its simplicity or
its elegance. The real reason, I'm convinced, is Bjarne's (and
now the committee's) decision to never close a door, even when
it seems only to open to poor programming practice at the time.
When I was first learning C++, I thought it horrible, compared
to Modula 3. Looking at Modula 3 today, however... There's so
many things you can't do in it, that you can in C++.

Other reasons may be more or less serindipity. I don't think
that anyone really realised the power of destructors when they
were invented, and I'm sure that templates weren't originally
designed with template meta-programming in mind.

> I also get less worried, in a way, when I realize that pretty much
> every programmer I know (young and old) still sticks to old ANSI C.
> The APIs they work with are all C APIs, and so on. The hunger for the
> Silver Bullet language cannot be that great.


C is a very good language for defining API's, because it is so
much like a portable assembler. For the same reason, no sane
programmer would use it in a large application.

--
James
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-14-2013
On Wednesday, April 10, 2013 6:57:55 PM UTC+1, Öö Tiib wrote:
> On Wednesday, 10 April 2013 13:36:24 UTC+3, James Kanze wrote:
> > On Tuesday, April 9, 2013 2:50:59 PM UTC+1, Öö Tiib wrote:
> > > On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:
> > > > On Tue, 09 Apr 2013 01:27:09 -0700, Öö Tiib wrote:
> > > > > If C++ wants to stay alive then it needs to have its own libraries
> > > > > and not to rely on libraries made for other languages.


> > > > This statement is nonsensical on its face. If it was even remotely
> > > > close to the truth, C and C++ would never have achieved their
> > > > dominant positions.


> > > Nonsense or not but those dominant positions feel right now about
> > > as dominant as those of Objective-C, Shell script and Perl.


> > With the major difference that there doesn't seem to be any new
> > competition. C++ seems to have beat out Ada-95, and in a more
> > distant past, Objective-C and Modula-3, but since then, there's
> > not really been any new language which realistically attempts to
> > replace it.


> With Objective-C the competition is still quite close. Some like
> one some other. What are your criteria for competitive?


Actual use. Maybe I'm not looking in the right places, but I
don't see any large scale applications being developed in
Objective-C. It's use seems to be limited to small "apps" for
one particular system.

The fields I know best are network management and investment
banking. In both cases, the engines which actually do the work
are written almost exclusively in C++. In the case of
investment banking, the absense of Objective-C is very
significant, because ten or fifteen years ago, there was a large
body of code in Smalltalk, and one would think that Objective-C
would be the natural evolution from there, much more so than
C++. And there was a significant body of code in Objective-C.
It turned out (at least in the one case where I know something
of the history) that as the individual programs became more and
more complex, Objective-C became less and less adapt.
Objective-C is (probably---I don't have any actual experience
with it) better than C++ for creating totally new, experimental
implementations of small, interactive software. C++ is superior
for large, stable applications which need to be maintained over
time.

> > If something new does come along, that is to C++ what Python is
> > to Perl, I'd jump on it, but I don't see it happening.


> That is too high requirement perhaps. If something is to C that
> Python is to Perl then that would be enough to win C++ (that is
> about equally popular with C).


I see very few significant *new* applications written in C.
About the only exception is the Linux kernel, which I'm not sure
I'd consider a good example. (The Python interpreter would
perhaps be better. It's 100% C, and it does prove that you can
write clean and maintainable code in C. But it's really pretty
small, compared to most applications I work on.)

> > In the case of C++, the total is simply too large:
> > in the time it would take to redesign a new language with all of
> > the expressivity of C++, but clean, simple and elegant, C++ will
> > have added new functionality that are missing in the new
> > language.


> I still hope that C++ could be simplified. For example introduce
> modules, deprecate '#include'. Deprecate 'inline' too ("exported"
> definitions are "inline"). Make it optionally possible to acquire
> equivalents of '__FILE__' , '__LINE__' and '__FUNCTION__' of
> caller (like class type return value currently already is such
> optional hidden parameter in most implementations). Deprecate
> #define. As result ... most sane usages for preprocessor and
> 'inline' removed.


Now that we have threading, modules and garbage collection are
the two things missing in the language itself. Which is
surprising if you realize that both were present and working in
Modula 3, 15 or more years ago. It's not as if the solutions
aren't known. (Although the way C++ uses pointers, inherited
from C, makes garbage collection more difficult than in other
langauges.)

--
James
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      04-14-2013
James Kanze <(E-Mail Removed)> writes:
>in a large project, you definitely want to keep the public
>interface definition (the class definition) is a separate
>file from the implementation code.

....
>Java's answer wasn't to create a better solution; it was to
>totally forbid the practice


file »Interface.java«:

public interface Interface { void f(); }

file »Implementation.java«:

public class Implementation implements Interface { public void f(){} }

In a large project, you definitely want to have a
doumentation for each interface and each abstract method.
C++'s answer was to totally ignore the problem, while Java
has JavaDoc, so a real Java interface file looks more like:

Interface.java

/** This interface ... */
public interface Interface
{
/** This method ... */
void f(); }

The Java standard library even defines standard interfaces.

 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      04-14-2013
On Sunday, April 14, 2013 6:46:20 AM UTC-5, James Kanze wrote:
> On Wednesday, April 10, 2013 2:46:39 PM UTC+1, Scott Lurndal wrote:
>
>
> > One could argue that Java is the "python to perl" for C++. It is much

>
> > cleaner (or was prior to java 7) than C++, more maintainable and more

>
> > readable.

>
>
>
> Java's "cleaner" because it doesn't try to address many of the
>
> issues C++ addresses. It's actually an interesting case: where
>
> C++ has a less than optimal solution to a problem, Java solves
>
> it by pretending that the problem doesn't exist, and banishing
>
> all solutions to it. Thus, for example, in a large project, you
>
> definitely want to keep the public interface definition (the
>
> class definition) is a separate file from the implementation
>
> code. The C++ solution is probably about the worst one could
>
> conceive of: textual inclusion of the class definition, the
>
> requirement that private data members be defined, etc. But
>
> Java's answer wasn't to create a better solution; it was to
>
> totally forbid the practice, even though it is clearly
>
> desirable.


What I think was even more desirable to the Java guys
was control and money. Their approach made it more
difficult for small companies with good ideas to be
able to put their ideas out there and compete with Sun.
C++ allows more flexibility in that regard.


Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-14-2013
On Thursday, April 11, 2013 8:11:46 AM UTC+1, Öö Tiib wrote:
> On Wednesday, 10 April 2013 23:02:24 UTC+3, Stefan Ram wrote:
> > Ian Collins <(E-Mail Removed)> writes:
> > >Until you want a generic object....


> > Objects are run-time entities.


> > Generics are handled by the compiler, they do not exist at run time.


> > So, there are no »generic objects«.


> The term "generic object" usually comes up with type erasure. C++ lacks
> something there; the "concepts" proposal was too complex.
> Currently only few things like std::function are sort of generic objects
> (you do not know if it is function, custom functor class, lambda or
> the thing returned by std::bind so it is pretty generic). Ian probably
> meant just handling pile of object in generic way, without such type
> erasure.


The term "generic object" is considerably older than type
erasure. Type erasure is only one means of implementing generic
objects. Not really one of the best, either.

--
James

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-14-2013
On Thursday, April 11, 2013 12:48:13 PM UTC+1, Martin Shobe wrote:
> On 4/11/2013 2:29 AM, Rui Maciel wrote:
> [snip]
> Which parts of C++ are they [Microsoft] not intending to implement?


Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

Earlier, they refused to implement export, and pushed for its
removal (which they obtained).

Compared to, say, 10 years ago, they've definitely improved.
But they've still got a way to go.

--
James
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      04-15-2013
On Sunday, 14 April 2013 15:07:24 UTC+3, James Kanze wrote:
> On Wednesday, April 10, 2013 6:57:55 PM UTC+1, Öö Tiib wrote:
> > On Wednesday, 10 April 2013 13:36:24 UTC+3, James Kanze wrote:
> > > On Tuesday, April 9, 2013 2:50:59 PM UTC+1, Öö Tiib wrote:
> > > > On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:
> > > > > On Tue, 09 Apr 2013 01:27:09 -0700, Öö Tiib wrote:
> > > > > > If C++ wants to stay alive then it needs to have its own libraries
> > > > > > and not to rely on libraries made for other languages.

>
> > > > > This statement is nonsensical on its face. If it was even remotely
> > > > > close to the truth, C and C++ would never have achieved their
> > > > > dominant positions.

>
> > > > Nonsense or not but those dominant positions feel right now about
> > > > as dominant as those of Objective-C, Shell script and Perl.

>
> > > With the major difference that there doesn't seem to be any new
> > > competition. C++ seems to have beat out Ada-95, and in a more
> > > distant past, Objective-C and Modula-3, but since then, there's
> > > not really been any new language which realistically attempts to
> > > replace it.

>
> > With Objective-C the competition is still quite close. Some like
> > one some other. What are your criteria for competitive?

>
> Actual use. Maybe I'm not looking in the right places, but I
> don't see any large scale applications being developed in
> Objective-C. It's use seems to be limited to small "apps" for
> one particular system.
>
> The fields I know best are network management and investment
> banking. In both cases, the engines which actually do the work
> are written almost exclusively in C++. In the case of
> investment banking, the absense of Objective-C is very
> significant, because ten or fifteen years ago, there was a large
> body of code in Smalltalk, and one would think that Objective-C
> would be the natural evolution from there, much more so than
> C++. And there was a significant body of code in Objective-C.
> It turned out (at least in the one case where I know something
> of the history) that as the individual programs became more and
> more complex, Objective-C became less and less adapt.
> Objective-C is (probably---I don't have any actual experience
> with it) better than C++ for creating totally new, experimental
> implementations of small, interactive software. C++ is superior
> for large, stable applications which need to be maintained over
> time.


Yes, seems that Objective-C is not used for making such network/web
servers. May be it lacks suitable libraries. Its original design goals
seemed quite similar to C++ only that it was closer to Smalltalk.

> > > If something new does come along, that is to C++ what Python is
> > > to Perl, I'd jump on it, but I don't see it happening.

>
> > That is too high requirement perhaps. If something is to C that
> > Python is to Perl then that would be enough to win C++ (that is
> > about equally popular with C).

>
> I see very few significant *new* applications written in C.
> About the only exception is the Linux kernel, which I'm not sure
> I'd consider a good example. (The Python interpreter would
> perhaps be better. It's 100% C, and it does prove that you can
> write clean and maintainable code in C. But it's really pretty
> small, compared to most applications I work on.)


What you mean by *new*? C has been used as major tool for writing
quite fresh things. For example git and SQLite are both written in C
are very popular and were both first published this century if I'm
not mistaken. You can indeed say that both revision control and SQL
are ideas from 1970 so "not new".

> > > In the case of C++, the total is simply too large:
> > > in the time it would take to redesign a new language with all of
> > > the expressivity of C++, but clean, simple and elegant, C++ will
> > > have added new functionality that are missing in the new
> > > language.

>
> > I still hope that C++ could be simplified. For example introduce
> > modules, deprecate '#include'. Deprecate 'inline' too ("exported"
> > definitions are "inline"). Make it optionally possible to acquire
> > equivalents of '__FILE__' , '__LINE__' and '__FUNCTION__' of
> > caller (like class type return value currently already is such
> > optional hidden parameter in most implementations). Deprecate
> > #define. As result ... most sane usages for preprocessor and
> > 'inline' removed.

>
> Now that we have threading, modules and garbage collection are
> the two things missing in the language itself. Which is
> surprising if you realize that both were present and working in
> Modula 3, 15 or more years ago. It's not as if the solutions
> aren't known. (Although the way C++ uses pointers, inherited
> from C, makes garbage collection more difficult than in other
> langauges.)


That was what was surprising about OP, few small cosmetics and
fixes were called whole "sanitary network". With C++ I would like even
bigger steps. Python for example seems to use a symbiosis of reference
counting and garbage collection behind scenes and also feels sometimes
better integrated with popular C and C++ "modules" than C++ itself is.
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      04-15-2013
Öö Tiib wrote:

> That was what was surprising about OP, few small cosmetics and
> fixes were called whole "sanitary network".


By your comment, you clearly haven't even browsed through the proposals.
Here's a bit of information to try to dispel your misconceptions.

C++14 was announced as a bug fix release, similar to C++03. In spite of
that, you can find among the proposals listed so far submittions to:

- boost:ptional
- support for an unstandardized API (OpenMP) to the standard
- yet another array container (DynArray) to the standard
- pipelines
- a brand new operator to be used to swap values, as an alternative to
simply using std::swap() or writing a function that does that.
- SIMD support.
- concepts lite
- add support for exit strategies in for loops
- add an algorithm to split strings
- add a database interface


This is a small subset of all the proposals which have been announced,
proposed to a process intended to fix problems found in a previous release.

Bearing this in mind, does any of these proposals fit your description of
being "few small cosmetics and fixes"?

At least try to glance at the stuff you are commenting on.


Rui Maciel
 
Reply With Quote
 
Martin Ba
Guest
Posts: n/a
 
      04-16-2013
On 14.04.2013 17:34, James Kanze wrote:
> On Thursday, April 11, 2013 12:48:13 PM UTC+1, Martin Shobe wrote:
>> On 4/11/2013 2:29 AM, Rui Maciel wrote:
>> [snip]
>> Which parts of C++ are they [Microsoft] not intending to implement?

>
> Templates? For the moment, they've implemented something sort
> of similar, but they haven't implemented C++ templates, as
> defined in C++98 (and C++03 and C++11).
>


I didn't notice anything missing from VC++ when using templates. Most of
Boost seems to manage to compile fine too. (yes, not everything C++11 is
in there yet.)

> Earlier, they refused to implement export, and pushed for its
> removal (which they obtained).
>


I dunno if MS pushed, but Herb Sutter (of MS) repeatedly claimed in
public that EDG -- AFAIK the only company to fully implement export --
was also in favor of removing it from the standard.

cheers,
Martin

 
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