Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

C++14: Papers

 
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <kjrepu$i2p$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)d says...
>
> Rui Maciel <(E-Mail Removed)> wrote:
> > I don't know which features will make their way into C++14, but after
> > browsing through those papers it looks like some people weren't satisfied
> > C++11 included the kitchen sink, they also want to add the rest of the
> > municipal sanitary network as well.

>
> Yeah, how dare they try to add even more utility features to the
> language! Who needs things like multithreading or vectorization?
> In the good old days we coded directly in asm. Using pencil and paper.
>


Is there agreement now to how to do multithreaded software? Are the language
constructs in C++ for such adequate to cover all bases? Does C++ embrace just
one paradigm (locking)?
 
Reply With Quote
 
 
 
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <kk3r4l$754$(E-Mail Removed)>, (E-Mail Removed) says...
>
> On 07.04.2013 13:09, Rui Maciel wrote:
> > Alain Ketterlin wrote:
> >
> >> Many items on this list are library issues/proposals, and many of them
> >> are orthogonal to each other.
> >>
> >> I'm no language lawyer, but I really think we should split the standard
> >> into two parts: one for the core language itself, another (or more) for
> >> the libraries. This would make the standardization of libraries faster
> >> (I guess), which would also provide more feedback to those in charge of
> >> the core.

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

>
> What I have been wondering on occasion is whether including all these
> great features in the standard will make C++ code *less* portable in the
> end.
>


Please do the following this weekend: port C++ to some platform (any platform
you wish--pick the easiest if you wish). Then, post here about how portable or
unportable C++ is. Are you still worried more being added to the C++ standard?
 
Reply With Quote
 
 
 
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <kk3ufh$73f$(E-Mail Removed)-stuttgart.de>, (E-Mail Removed)-
berlin.de says...

Are you THE Thomas Richter, author of Windows programming books?
 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>, (E-Mail Removed) says...

> One of the reasons often cited for the failure of Algol 60, was the failure
> to include I/O in the standard.


No, that wasn't it. The reason was because of its Pascal-like syntax. Any
lexically-scoped programming language not adopting curly braces to designate
scope for blocks and functions is doomed.
 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
(E-Mail Removed) says...
>
> 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.


Go? Rust? D?

> C++ seems to have beat out Ada-95,


Because Ada syntax is Pascal-like (no curly braces) and their encapsulation
constructs are much to confus(ing)/(ed).

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


Go? Rust? D?

> If something new does come along, that is to C++
> what Python is to Perl,


Go? Rust? D?

> I'd jump on it,


Meaning what? That you'd try it? Use it on a project or product? Are you a
programmer or a software developer? Would you sign a non-disclosure agreement?

> but I don't see it
> happening.


I don't see it NOT happening, but C++ does seem to be clearing-up enough of its
warts to keep it viable for some time to come. Is C++ now too far ahead and it's
too late to play catch-up? Google doesn't think so. Walter Bright doesn't think
so. More so, they don't even think that way. C++ is definitely improving (even
I'm chomping for VC++ to introduce more C++ 11 features).

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


It goes both ways though. Freed from the complexity of C++, the programming
language design space is not limited and that enables what cannot be had in C++,
at least not simply and elegantly. So, given the exact same functionality as in
C++ (not that that is the goal), AND the elusive "simplicity and elegance", the
"only" things C++ has going for it is the existing code base (no small potatoes)
and existing (expensive) programmers. New development not requiring a link to
the existing and the past may indeed be better off with the simple and elegant
offering.

You brought up a very good point: What is called for, C++, or something simple
and elegant? With the growing number of languages positioning themselves as C++
alternatives (at least eventually), is there any doubt that C++'s dominance is
not a matter of "if", but rather of "when"?


 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
(E-Mail Removed) says...
>
> 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.


So do you feel, then, that C++'s primary domain is large-scale development and
that is the litmus test upon which to judge competitive-with-C++ness? If not,
what other criteria is relevant, in your opinion?

You say "actual use", but in the short term, a new language is going to be
behind because of the existing base of C/C++ code and developers. I think a more
strategic approach to thinking about it is necessary. That is, one should be
capable of assessing the viability of a language offering given what it is
feature-wise and how use of a particular language can be exploited going forward
(aka, "forward-thinking"). By "feature-wise", I don't mean just thinks like "has
move constructors", but also things like "is simple and elegant".

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


Not insignificant is that your "position" (for lack of a better word that I
can't think of right now) seems to lay down the criteria where C++ CAN compete:
big budget software, where it can be afforded. There's no doubt about it, C++
development is expensive. That is an "attack surface": a major, major problem
inherent of C++, in that it is expensive to use. This may be somewhat offset by
the availability of libraries, but largely not so because C++ is not amenable to
mixing libraries from multiple developers. Integration of libraries may be more
expensive than reinventing the wheel, and many accomplished developers do
exactly that, but it is definitely not for the faint of heart either. Hence
another major problem.

I don't think C++ can change enough to keep it "good enough". At some point the
gas-guzzler will be a museum piece rather than a daily driver. Cadillac
Escalade? What if people (finally) "get a clue" and figure out that driving all
over the place like little ants is a waste of time and money and is dangerous
(not only accidents, but snipers!)? (I digress).

> C++ is superior
> for large, stable applications which need to be maintained over
> time.


Superior to inferior existing languages, you mean, and not the languages under
development currently (and perhaps I'm just starting on it today ) and yet to
find success. (I'm not agreeing with you). YOU can say that, but you have many
years of C++ use and knowledge, etc. YOU, though, are too expensive, and you
know it. A better language would be one that makes you obsolete (I mean the two
or three or more decade learning curve). Yes, YOU can create and maintain those
very complex systems, some (perhaps much) of the complexity arising from the use
of C++, but YOU and others like you are a small group. That is a problem
awaiting solution. Agree?

> Now that we have threading, modules and garbage collection are
> the two things missing in the language itself.


Can C++ even have "modules"? Doesn't that make it something else? Heck, add GC
and don't you then have D? It's one thing to say C++ will still be here for many
years, but isn't that like the George Washington ax?

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


Having separate headers and implementation files were not considered by Bjarne
to be a worthwhile improvement apparently or there maybe was not enough budget
or maybe C++ is Bjarne's quick-hack gone awry, who knows (Bjarne knows! Time for
another book Bjarne!). I wonder what kinds of major faux paus I will make that
won't be readily seen until looking back historically. Bjarne has a valid excuse
(backward compatibility), I on the other hand, do not have such a crutch, for I
am starting with a clean slate--the design space is wide open. (I promise not to
name my language "the james kanze eliminator" . Remember, you said you'd use
it! Then again, you'll be retired by then. ).



 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
(E-Mail Removed) says...

(I'm not singling-out you by following-up on YOUR posts, but you write things
that make me feel the need to do so. I think this post will shed some light on
that. I think you are either trying to artificially bolster-up the "superiority
of C++" or you don't even realize that you may be doing that.)

> All I claim is that there is a large class of applications for
> C++ is more or less the only solution.


That could be akin to "self-fulfilling prophecy" or such. Consider, the
"interface" of C++ is so broad, complex, esoteric, that once some large amount
of C++ code is in place it is hard to get away from it, given that the
investment in time and money is so great. Consider a hypothetical successful
application which cost a billion dollars to produce, and then someone creating
the same thing for a fraction of the cost by changing the approach, say, using
another, perhaps *new* language. What's to keep the manager of the the billion
dollar project from getting a pink slip?

Then again, I AM being very hypothetical because there is not that simple and
elegant language you referred to earlier (that you'd try, mind you). I know it
can be had, though, and I know I can make it (really I can). I just don't know
how long it will take to be liked by other people. That is, how long it's going
to take to get to feature-"complete" 1.0 state. I wouldn't want to rush it at
all. I want to get it right before "freezing" features. At some point when the
synthesis is has become relatively flat it could be considered pretty much
"done". It's not like I want to spend the rest of my life creating a language--I
want to build software with it (and I have lots of things I want to build, or
seen built or have built or something)!


> Today (and I often
> wonder why Ada 95 didn't get more consideration).


Stop wondering: Pascal-like syntax and ugly constructs (one reason). Too
unevolved. Designed by committee to the extreme. Not that Ada to any degree
achieved simplicity or elegance, but there should be some balance between
achieving that in the usage of the language, and its implementation reflecting
that. If a language designer or wannabe language designer does not get that, I
don't see how good result could be forthcoming. I really don't.

This is seeming, to me, to be less and less of a difficult thing to do. I don't
have to do what has already been done with C++. I mean I don't have to invent
THOSE things. I just have to re-implement them (those that make the cut, that
is). That wouldn't be my starting point, but at some juncture I'd list all the
C++ features select the good ones and nix the bad ones. I've done that a lot
already, informally. Sometimes a bad example is the best example!

> That doesn't mean that it's the only language, or the best
> language for everything. Where I work, we use Excel,
> Mathematica, Python and C# as well, not to mention specialized
> languages like SQL, or individual choices for local tools (e.g.
> I'll often use bash, or even the Bourne shell, with sed and
> awk, and the rest for small, quick tools). All of the real work
> is done in C++, but there's a lot of "glue" as well.


I'll put that on the list: replace all of those and it's golden.


 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>, (E-Mail Removed) says...
>
> James Kanze wrote:
>
> > 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.

>
> That's really sad; I can only hope your analysis is wrong.


He seems to be using weasel words. You can't win against the weaselly "the
expressivity of C++". I don't know if he's being honest (actually knows what he
means) or if he is purposely stating it so that by his criteria it is impossible
to create or even envision a language "on par with the C++ god". I don't know.

> C++ is so obviously a
> group effort, with no discernable philosophy, the damned thing just grew and
> grew and it is still growing.


I does lack coherence, doesn't it. D tried/is-trying to be something else, but
it suffers from the same "lack of philosophy" you mention. That may be over-
stated, what I just said. If esotericism is the philosophy and if that can be a
philosophy, then I think that has been achieved.

> We have ridiculous brevity, '%' means modulo?
> Give me a break.


Is there an actually a modulo operator symbol in mathematics?

> And that is mixed with monstrously long identifiers in STL
> that would be very much at home in COBOL


How about templates at all? Maybe I'm just not evolved enough, but I think I
refuse to succumb to all that and think it is not necessary. Rather than
succumb, I rather envision eliminating the need for all of that (in a new
language).

> All that in one language?? . And
> in an era in which GUI is THE way to interface with humans, an add on
> library is needed to write a real program. Oh, this program is written in
> C++ with the whatchamacallit GUI. You three guys leave the room while we
> discuss this problem.


I think a language could and can drive innovation in that area, but I don't
think that is possible within the context of C++. It would be all templates
probably! I'm not saying a GUI library cannot be made, many have been. I see
that (many have been made, many more will be made) as a problem to be solved.
(Yeah, yeah, I know there are many who love C++ for the very fact that is has
templates and turing complete to boot. Similarly, the Boost guys love the
preprocessor).

>
> Just pathetic, really. This disgusting piece of crap is the best the human
> mind can come up with?


"It is what it is". I wouldn't call it crap. It's useful. I wouldn't call it
*very* useful, but I live in a fantasy world where the NBL (Next Big Language)
already exists. And maybe I don't want that. How will I get paid for all the
years gone by? Maybe I just want the competitive advantage and build software
with it.


 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
(E-Mail Removed) says...

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


Yes, with C++, one can do anything, anywhere, but there is hefty price to be
paid for that. What you just implied is that "one size fits all" is not
appropriate. C++ does try to be that to some degree and then less general
solutions are decidedly better. If you take away all the capabilities of C++
(whatever they are) that make it useful in all the "niche" domains (whatever
they are), maybe that defines the design space from where a language can become
the 80% solution (that is, 80% of projects (whatever that means) and C++ can
then be relegated to the esoteric niches where is is CLEARLY better. Creating
another Frankenstein is not the goal, C++ fills that niche quite nicely. (And of
course D is "bride of Frankenstein" then! )

That said, I can conceive that someone could do no invention/innovation at all,
and just gather the correct parts (features) from existing languages, put them
together correctly, and have a successful language. No one is selecting the
right combination of parts and putting them together correctly and that is why
there is no movement away from C++--there is no reason to move and much reason
to stay (currently). That wouldn't be my approach, but I do think something like
that could be done. I tend to avoid analyzing the existing practice at first, so
as not to be blinded by it. When I encounter a C++ intricacy I that is not
compelling, I avoid it an am happy to know that some day I'll be able to
implement the software properly when that simple and elegant language is
available. As I have been holding my breath for it to arrive for a long time, I
can't wait for it anymore and I guess I'll just have to do it myself!

 
Reply With Quote
 
Tony
Guest
Posts: n/a
 
      04-19-2013
In article <(E-Mail Removed)>,
(E-Mail Removed) says...
>
> On Wed, 2013-04-10, Stefan Ram wrote:
> > Jorgen Grahn <(E-Mail Removed)> writes:
> >>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++".

> >
> > »Within C++, there is a much smaller and cleaner
> > language struggling to get out.«
> >
> > Stroustrup, Bjarne. The Design and Evolution of C++. pp. 207.

>
> He doesn't really explain what he means by that, but right before that
> he writes "I maintain that C++'s type system and semantics are cleaner
> than its syntax".


Well he can "maintain" as he pleases, but he's still wrong about that. C++'s
type system gets a grade F from me (and surely others): it's simply an incorrect
answer. That makes C's type system incorrect also. To base a new language on
that is one thing and wouldn't be so bad for an in-house hack, but for it to get
as popular as it did is quite astounding (if not bizarre or even disheartening).

> My guess is he's thinking of the compromises taken
> while basing the language on C. Well, it was necessary, and I believe
> it still is.
>
> /Jorgen



 
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