C++14: Papers

[Rui Maciel]

Here are three links which showcase which features are being proposed for
C++14:

http://www.meetingcpp.com/index.php/br/items/a-look-at-cpp14-papers-
part-1.html
http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-
part-2.html
http://meetingcpp.com/index.php/br/items/a-look-at-c14-and-beyond-papers-
part-3.html

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.

Any thoughts?


Rui Maciel

[Leigh Johnston]

boost.asio would be a great addition to C++.

/Leigh

[Öö Tiib]

On Sunday, 7 April 2013 02:44:59 UTC+3, Leigh Johnston wrote:
> On 05/04/2013 21:40, Rui Maciel wrote:
> boost.asio would be a great addition to C++.

Yes, but currently it works only on POSIX or Windows AFAIK.

[Juha Nieminen]

Rui Maciel <rui.m...@gmail.com> 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.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Alain Ketterlin]

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.

-- Alain.

[Rui Maciel]

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.


Rui Maciel

[Rui Maciel]

Juha Nieminen wrote:

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

It's as if it wasn't possible to use third-party components with C++.

Don't be an idiot.


Rui Maciel

[88888 Dihedral]

Rui Maciel於 2013年4月6日星期六UTC+8上午4時40分31秒寫道：

Well, the objective C got all the sanitary GC part built-in.
This will drive the C++ to evolve definitely.

[Juha Nieminen]

How exactly do you expand the syntax of the language with third-party
components, idiot?

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Rui Maciel <rui.m...@gmail.com> wrote:
>>> 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.
>>
>> It's as if it wasn't possible to use third-party components with C++.
>>
>> Don't be an idiot.
>
>How exactly do you expand the syntax of the language with third-party
>components, idiot?

Seems OpenMP has done so for vectorization, and pthreads for multithreading. Why
does it have to be in the language syntax?

scott

[Alexander Terekhov]

Scott Lurndal wrote:
[...]

> Seems OpenMP has done so for vectorization, and pthreads for multithreading. Why
> does it have to be in the language syntax?

Both OpenMP and pthreads are good examples that it can not be really
done "as a library" without support on the language level (memory
model), see e.g.:

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
http://www.ccs.tsukuba.ac.jp/workshop/IWOMP2010/slides/Boehm-iwomp10.pdf

regards,
alexander.

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> Seems OpenMP has done so for vectorization, and pthreads for multithreading.

OpenMP is not a third-party component. It's a non-standard language
extension that has to be explicitly supported by the compiler.

If you are going to use OpenMP, your code will simply not compile with
compilers that have no support for it. You can't simply provide a
third-party library alongside your project and have it compile.

If, however, something akin to OpenMP is part of the language standard,
then there's a much higher chance that your program will be portable and
compilable with any modern compiler.

> Why does it have to be in the language syntax?

OpenMP *is* language syntax. It's not just a library that you can add
to your project and call it with standard C++.

[Christian Gollwitzer]

Am 08.04.13 17:25, schrieb Juha Nieminen:

> Scott Lurndal <sc...@slp53.sl.home> wrote:
>> Seems OpenMP has done so for vectorization, and pthreads for multithreading.
>
> OpenMP is not a third-party component. It's a non-standard language
> extension that has to be explicitly supported by the compiler.

True.

> If you are going to use OpenMP, your code will simply not compile with
> compilers that have no support for it. You can't simply provide a
> third-party library alongside your project and have it compile.

Not entirely true. OpenMP is integrated into the language very cleverly
using #pragmas. If only those are used, and not the accompanying library
with headers in omp.h, the program does compile on a non-OpenMP compiler
with just some "unknown pragma" warnings. Moreover, it should run
correctly, only, of course, single-threaded. To provide some mock
library as a replacement to omp.h would be very easy - most operations
are simple no-ops in the serial case.

OpenMP does show, that it is possible to extend the language while
maintaining backwards compatibility with older compilers. However that
is a very special case, because parallelization doesn't change program
semantics in the ideal case. It is impossible to extend, say, a C++98
compiler to support range based for loops such that other C++98
compilers can compile a correct program.

Christian

[Nobody]

On Sun, 07 Apr 2013 09:38:06 +0000, Juha Nieminen wrote:

> Rui Maciel <rui.m...@gmail.com> 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.

It isn't just a question of desirability. There's also the question of
whether the end result is something which can only be implemented on
full-featured desktop/server platforms and only then by a team of a
hundred experienced, full-time developers.

[Rui Maciel]

Juha Nieminen wrote:

> How exactly do you expand the syntax of the language with third-party
> components, idiot?

If you had read what I wrote, you would understand why your comment is
silly.

Again, don't be an idiot.


Rui Maciel

[Rui Maciel]

Alexander Terekhov wrote:

> Both OpenMP and pthreads are good examples that it can not be really
> done "as a library" without support on the language level (memory
> model), see e.g.:
>
> http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
> http://www.ccs.tsukuba.ac.jp/workshop/IWOMP2010/slides/Boehm-iwomp10.pdf

Not true. Those papers make a case that compilers should not be "designed
independently of threading issues". That isn't the same thing as claiming
that threading and other forms of parallism can't be done "as a library".
Because that's what essentially has been done for over a decade.

Moreover, that also does not justify including a specific API for threading
in the standard.


Rui Maciel

[Öö Tiib]

On Tuesday, 9 April 2013 00:57:38 UTC+3, Rui Maciel wrote:
> Alexander Terekhov wrote:
>
> > Both OpenMP and pthreads are good examples that it can not be really
> > done "as a library" without support on the language level (memory
> > model), see e.g.:
> >
> > http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
> > http://www.ccs.tsukuba.ac.jp/workshop/IWOMP2010/slides/Boehm-iwomp10.pdf
>
> Not true. Those papers make a case that compilers should not be "designed
> independently of threading issues".

Yes and if to remove the quadruple negation weasel-wording from the sentence
then that means "have to support threading".

> That isn't the same thing as claiming that threading and other forms
> of parallism can't be done "as a library".
> Because that's what essentially has been done for over a decade.

With non-standard compiler extensions and platform-dependent libraries.
What was so good about it?

> Moreover, that also does not justify including a specific API for threading
> in the standard.

Do you propose to remove threads and atomic operations from C++ standard
library now because you are happy with POSIX and Win32 C API and those
OpenMP pragmas?

[Rui Maciel]

Öö Tiib wrote:

> On Tuesday, 9 April 2013 00:57:38 UTC+3, Rui Maciel wrote:
>> Alexander Terekhov wrote:
>>
>> > Both OpenMP and pthreads are good examples that it can not be really
>> > done "as a library" without support on the language level (memory
>> > model), see e.g.:
>> >
>> > http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
>> > http://www.ccs.tsukuba.ac.jp/workshop/IWOMP2010/slides/Boehm-
iwomp10.pdf
>>
>> Not true. Those papers make a case that compilers should not be
>> "designed independently of threading issues".
>
> Yes and if to remove the quadruple negation weasel-wording from the
> sentence then that means "have to support threading".

You only miss the point if you really really want to.

>> That isn't the same thing as claiming that threading and other forms
>> of parallism can't be done "as a library".
>> Because that's what essentially has been done for over a decade.
>
> With non-standard compiler extensions and platform-dependent libraries.
> What was so good about it?

What you refer to as "non-standard compiler extensions" in reality means
"features which aren't included in a specific release of ISO/IEC 14882".
The computing world is built from features which aren't included in a
specific release of ISO/IEC 14882, and yet it manages to work.

Everyone is free to implement and use features which aren't defined through
an ISO standard. For example, OpenGL is a popular API, which happens to
require platform-dependent features. Do you believe OpenGL should also be
shoved onto the next C++ standard in order for C++ programmers to be able to
use it?

>> Moreover, that also does not justify including a specific API for
>> threading in the standard.
>
> Do you propose to remove threads and atomic operations from C++ standard
> library now because you are happy with POSIX and Win32 C API and those
> OpenMP pragmas?

Don't put words in other people's mouths. Stick to what people actually
say, and try not to invent imaginary claims.


Rui Maciel

[Öö Tiib]

On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:

> Öö Tiib wrote:
> > Yes and if to remove the quadruple negation weasel-wording from the
> > sentence then that means "have to support threading".
>
> You only miss the point if you really really want to.

What point? That pthreads will work without -pthread compiler option?
No they won't. The support has to be built into compiler.

> What you refer to as "non-standard compiler extensions" in reality means
> "features which aren't included in a specific release of ISO/IEC 14882".

Having a pile of standards just does not work. There will be often
some contradiction because of defect even in one standard. Synchonizing
several seems to be impossible.

If C++ wants to stay alive then it needs to have its own libraries and not
to rely on libraries made for other languages.

> The computing world is built from features which aren't included in a
> specific release of ISO/IEC 14882, and yet it manages to work.

The computing world will manage to work without C++. Is that your point?

> Everyone is free to implement and use features which aren't defined through
> an ISO standard. For example, OpenGL is a popular API, which happens to
> require platform-dependent features.

Yet another C API.

> Do you believe OpenGL should also be shoved onto the next C++ standard
> in order for C++ programmers to be able to use it?

No, but indeed I would like C++ API for rendering. I am not against to
extend C++ standard library if there are no other ways to have stable
and well-specified C++ library otherwise.

> > Do you propose to remove threads and atomic operations from C++ standard
> > library now because you are happy with POSIX and Win32 C API and those
> > OpenMP pragmas?
>
> Don't put words in other people's mouths. Stick to what people actually
> say, and try not to invent imaginary claims.

I did not shove anything in your mouth. I did ask a question.

Sorry, it is hard to understand what you mean. You say "municipal
sanitary network" about thing that certainly is not one and "idiot"
about person who certainly is not one.

[Nobody]

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.

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:

>
>With non-standard compiler extensions and platform-dependent libraries.
>What was so good about it?

Hmm. I've been using pthreads (or prior to that, SVR4.2MP M-N threads) since
1990. On multiple unix and linux systems. That's over two decades
of threaded C++ code. I'd call that good.

>
>> Moreover, that also does not justify including a specific API for threading
>> in the standard.
>
>Do you propose to remove threads and atomic operations from C++ standard
>library now because you are happy with POSIX and Win32 C API and those
>OpenMP pragmas?

That would be pretty silly, wouldn't it?

As it happens, none of the compilers
that we have available to us at CPOE are C++11, so I couldn't use the language features
anyway, so we'll continue to use pthreads in our code.

I'd argue that C++ is feature-rich enough already for 99.99% of all applications
and the added cruft in C++11 (e.g. lambdas) and the stuff proposed for C++14 are unnececessary
features that complicate the language and make code maintenance more demanding
(actually the introduction of templates in C++ 3.0 was the beginning of the downfall
of C++, in my opinion, which I'll admit is hardly universal).

scott

[Öö Tiib]

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

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:

>> =D6=F6 Tiib wrote:
>> > Yes and if to remove the quadruple negation weasel-wording from the
>> > sentence then that means "have to support threading".

>>=20

>> You only miss the point if you really really want to.
>
>What point? That pthreads will work without -pthread compiler option?
>No they won't. The support has to be built into compiler.

And all compilers have it built in, and have for two decades. I would
argue that makes pthreads an incredibly effective tool for multitheading
C++ code.

>
>> What you refer to as "non-standard compiler extensions" in reality means=
>=20

>> "features which aren't included in a specific release of ISO/IEC 14882".
>
>Having a pile of standards just does not work. There will be often
>some contradiction because of defect even in one standard. Synchonizing

>several seems to be impossible.=20

Extrinsic evidence would conflict with your statement. Piles of standards
have gotten us to where we are today (I've personally spent hundreds of hours
in standards committee work, including TOG nee X/open); which is a wide-open
internet with a great deal of free and/or open-source code.

>
>If C++ wants to stay alive then it needs to have its own libraries and not
>to rely on libraries made for other languages.

Bologna.

> =20
>> The computing world is built from features which aren't included in a=20

>> specific release of ISO/IEC 14882, and yet it manages to work.
>
>The computing world will manage to work without C++. Is that your point?

No, it works _with_ C++. Without all the fancy C++11 features. Today. Quite well.


>
>> Everyone is free to implement and use features which aren't defined throu=
>gh=20
>> an ISO standard. For example, OpenGL is a popular API, which happens to=
>=20

>> require platform-dependent features.
>
>Yet another C API.
>
>> Do you believe OpenGL should also be shoved onto the next C++ standard
>> in order for C++ programmers to be able to use it?
>

>No, but indeed I would like C++ API for rendering. I am not against to=20
>extend C++ standard library if there are no other ways to have stable=20

>and well-specified C++ library otherwise.
>

>> > Do you propose to remove threads and atomic operations from C++ standar=

>d
>> > library now because you are happy with POSIX and Win32 C API and those
>> > OpenMP pragmas?

>>=20
>> Don't put words in other people's mouths. Stick to what people actually=
>=20

>> say, and try not to invent imaginary claims.
>
>I did not shove anything in your mouth. I did ask a question.

A very loaded question, that anticipated the answer. A silly question,
really. Removing threads from C++ standard? A non-starter obviously.

[Scott Lurndal]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> writes:
>On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:

>> On Tue, 09 Apr 2013 01:27:09 -0700, =D6=F6 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.

>>=20

>> 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 position=
>s.
>
>Nonsense or not but those dominant positions feel right now about as domina=

>nt
>as those of Objective-C, Shell script and Perl.

What's your point? COBOL is still alive. C++ will still be alive in 30 years.

[Öö Tiib]

Drop of COBOL's popularity is profitable for experienced users ... less competition to available positions and less likelihood that some new
project will be started in it ... safe maintenance-mushrooming.

I do not want it. I do not have desire to become gradually such
grumpy experienced user of dying language who maintains some corporate
legacy code-base somewhere in corner. I like to do new things, have
teams ... etc. Such perspective is unlikely with language that long
term user (you) classifies like "still alive" in its forum.

I understand very well that some other people have other goals and
desires here and some may want to be specialists of such dying
legacy language.

[Rui Maciel]

Öö Tiib wrote:

> On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
>> Öö Tiib wrote:
>> > Yes and if to remove the quadruple negation weasel-wording from the
>> > sentence then that means "have to support threading".
>>
>> You only miss the point if you really really want to.
>
> What point? That pthreads will work without -pthread compiler option?
> No they won't. The support has to be built into compiler.

Read what I wrote. Stick to what people actually say, not to what you
imagine in its place.

>> What you refer to as "non-standard compiler extensions" in reality means
>> "features which aren't included in a specific release of ISO/IEC 14882".
>
> Having a pile of standards just does not work.

That is a public declaration that you don't know anything about what you are
talking about. Here's a hint: eurocodes.

> If C++ wants to stay alive then it needs to have its own libraries and not
> to rely on libraries made for other languages.

Bullshit.

Here's another hint: "going the way of C++" has become a derogatory
expression.

>> The computing world is built from features which aren't included in a
>> specific release of ISO/IEC 14882, and yet it manages to work.
>
> The computing world will manage to work without C++. Is that your point?

You either have a hard time reading or dealing with what others actually
say. Either way, read what people actually say, not what you invent in its
place.

>> Everyone is free to implement and use features which aren't defined
>> through
>> an ISO standard. For example, OpenGL is a popular API, which happens to
>> require platform-dependent features.
>
> Yet another C API.

Irrelevant.

>> Do you believe OpenGL should also be shoved onto the next C++ standard
>> in order for C++ programmers to be able to use it?
>
> No

See? Was that hard? The same applies to essentially any component.

> , but indeed I would like C++ API for rendering.

Go ahead, pick any API or toolkit that fits your needs, or even write your
own. There's no need to wait for a committee to hogtie you to a specific
solution to be able to do what people have already been doing for decades.

> I am not against to
> extend C++ standard library if there are no other ways to have stable
> and well-specified C++ library otherwise.

Specifications only help with guaranteeing interoperability between
components created by multiple independent vendors. If, instead, a
component is freely distributed then it's quite possible to simply download
the component and use it as you wish. Have you heard of, for example,
Boost?

Another aspect that you've missed is the fact that once a component finds
its way to a standard, it stays there, and stays there no matter how buggy,
inept, unsafe and insecure it might end up being. Read up on C's standard
library to get an idea of the problems originated in bloating a standard
with all sorts of components.

>> > Do you propose to remove threads and atomic operations from C++
>> > standard library now because you are happy with POSIX and Win32 C API
>> > and those OpenMP pragmas?
>>
>> Don't put words in other people's mouths. Stick to what people actually
>> say, and try not to invent imaginary claims.
>
> I did not shove anything in your mouth. I did ask a question.

Don't play dumb.

> Sorry, it is hard to understand what you mean. You say "municipal
> sanitary network" about thing that certainly is not one and "idiot"
> about person who certainly is not one.

You clearly failed to read the proposals and the thread.


Rui Maciel

[Rui Maciel]

Öö Tiib wrote:

> Nonsense or not but those dominant positions feel

Feel?

Meanwhile, in spite of your feelings, people keep writing software, some of
which using C++. Among those, some without having even migrated to C++11.


Rui Maciel

[Andy Champ]

On 09/04/2013 14:46, Scott Lurndal wrote:
> I'd argue that C++ is feature-rich enough already for 99.99% of all applications
> and the added cruft in C++11 (e.g. lambdas) and the stuff proposed for C++14 are unnececessary
> features that complicate the language and make code maintenance more demanding

IMHO Lambdas were the feature that make such STL algorithms as find_if
make sense. Before that you had to move your check off somewhere else
nowhere near the code in question.

I won't comment on the thread stuff though, it's not supported in my
compiler.

Andy

[Ian Collins]

�� Tiib wrote:
> On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
>
>> What you refer to as "non-standard compiler extensions" in reality means
>> "features which aren't included in a specific release of ISO/IEC 14882".
>
> Having a pile of standards just does not work. There will be often
> some contradiction because of defect even in one standard. Synchonizing
> several seems to be impossible.
>
> If C++ wants to stay alive then it needs to have its own libraries and not
> to rely on libraries made for other languages.

Where "other languages" == C?

C libraries are the glue that holds most of today's computing together.
Do you hear Python or PHP programmers complaining about their
languages incorporating C libraries? No.

C++ has done very well building on its C foundations, what is to be
gained by throwing them away and building a new set of wheels?

--
Ian Collins

[Juha Nieminen]

Scott Lurndal <sc...@slp53.sl.home> wrote:
> I'd argue that C++ is feature-rich enough already for 99.99% of all applications
> and the added cruft in C++11 (e.g. lambdas) and the stuff proposed for C++14 are unnececessary
> features that complicate the language and make code maintenance more demanding

You could make the exact same argument to promote C.

If you want to use C, nobody's stopping you.

> (actually the introduction of templates in C++ 3.0 was the beginning of the downfall
> of C++

And you lost all your credibility with that.

It's precisely templates that make C++ vastly, vastly superior to C and
is single-handedly one of the features that's superior to almost any
other programming languages.

[James Kanze]

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.

--
James

[Alexander Terekhov]

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

Just wait till Apple comes up with cool
watch/glasses/TV/fridge/microwave/toaster/whatnot with apps programmed
in Objective-C and it will become number one for sure... see charts at

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

;-)

Not so long ago:

http://www.infoworld.com/d/application-development/apples-popularity-boosts-objective-c-language-past-c-197083

"Apple's popularity boosts Objective-C language past C++

Used for building iPad and iPhone apps, Objective-C takes over third
place in Tiobe language survey, knocking C++ to fourth"

regards,
alexander.

[osmium]

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. I remember the
elation I felt as a Fortran programmer when I first used Algol 60. So THIS
is the way the grown ups do it; it was such a rush! C++ is so obviously a
group effort, with no discernable philosophy, the damned thing just grew and
grew and it is still growing. We have ridiculous brevity, '%' means modulo?
Give me a break. And that is mixed with monstrously long identifiers in STL
that would be very much at home in COBOL 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.

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

[Öö Tiib]

On Wednesday, 10 April 2013 00:03:09 UTC+3, Ian Collins wrote:

> �� Tiib wrote:
> > On Tuesday, 9 April 2013 09:52:30 UTC+3, Rui Maciel wrote:
> >
> >> What you refer to as "non-standard compiler extensions" in reality means
> >> "features which aren't included in a specific release of ISO/IEC 14882".
> >
> > Having a pile of standards just does not work. There will be often
> > some contradiction because of defect even in one standard. Synchonizing
> > several seems to be impossible.
> >
> > If C++ wants to stay alive then it needs to have its own libraries and not
> > to rely on libraries made for other languages.
>
> Where "other languages" == C?

No difference actually if it is C or not. C interface is just often used
as "language neutral" interface.

> C libraries are the glue that holds most of today's computing together.
> Do you hear Python or PHP programmers complaining about their
> languages incorporating C libraries? No.

Other languages do provide their binding layer to the underlying C (also
often C++) libraries. C++ is somehow too proud that C program "almost
compiles" as C++ so no need for special interfaces. "Write one yourself"
is standard answer. I won't go into depth here about such googled out
codeguru broken joints that one can nothing to do with but to weed out.

> C++ has done very well building on its C foundations, what is to be
> gained by throwing them away and building a new set of wheels?

No! Do not reinvent wheels constantly. Do not even reinvent the ball
bearings with no end. That is what I mean. I would like if C++ would
officially decide that those wheels are good enough by describing
fitting ball-bearings.

I am generally against such mentality that whatever change is bad;
that C++ is monster; that it has to die and let it to die.
I really like C++11, my impression is that it made so lot of things
simpler and more complete. There are only few things that feel wrong
(like confusingly loose list-initialization). The C++14 proposals
seemed partly fixing the shortcomings of C++11, and partly introducing
base for such new joints.

[Scott Lurndal]

Some of them without having even migrated to C++03.

[Scott Lurndal]

Juha Nieminen <nos...@thanks.invalid> writes:
>Scott Lurndal <sc...@slp53.sl.home> wrote:
>> I'd argue that C++ is feature-rich enough already for 99.99% of all applications
>> and the added cruft in C++11 (e.g. lambdas) and the stuff proposed for C++14 are unnececessary
>> features that complicate the language and make code maintenance more demanding
>
>You could make the exact same argument to promote C.
>
>If you want to use C, nobody's stopping you.

I want to use C with classes, so I use C++ (and I've even used STL in a couple of
projects, where it made sense). However, since I write operating system and hypervisor
code, STL is not available.

>
>> (actually the introduction of templates in C++ 3.0 was the beginning of the downfall
>> of C++
>
>And you lost all your credibility with that.
>
>It's precisely templates that make C++ vastly, vastly superior to C and
>is single-handedly one of the features that's superior to almost any
>other programming languages.

IMO, it is data-encapsulation and objects (classes) that make C++ superior
to C. Neither of which require templates.

[Scott Lurndal]

James Kanze <james...@gmail.com> writes:

>On Tuesday, April 9, 2013 2:50:59 PM UTC+1, =D6=F6 Tiib wrote:
>> On Tuesday, 9 April 2013 15:12:49 UTC+3, Nobody wrote:

>> > On Tue, 09 Apr 2013 01:27:09 -0700, =D6=F6 Tiib wrote:
>> > > If C++ wants to stay alive then it needs to have its own libraries an=

>d not
>> > > to rely on libraries made for other languages.
>

>> > This statement is nonsensical on its face. If it was even remotely clos=
>e
>> > to the truth, C and C++ would never have achieved their dominant positi=
>ons.
>
>> Nonsense or not but those dominant positions feel right now about as domi=

>nant
>> 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. 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. The obvious downsides are bytecode and non-determinism which
are antithetical to many classes of problems that are solved by C++.

scott

[Martin Ba]

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.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

just a thought.

- Martin

[Miquel van Smoorenburg]

In article <ec091644-db79-4585...@googlegroups.com>,

James Kanze <james...@gmail.com> 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.

Perhaps http://rust-lang.org/

Mike.

[Thomas Richter]

Am 10.04.2013 16:00, schrieb Martin Ba:

> 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.
>
> The bigger and more complex the std-library gets, the more likely it
> gets that different vendor implementations would have subtle differences
> that would break portability vs. having a single-source library (like
> Boost) that uses at least the "same" source code on all platforms.

While I kind of agree, you also hear the opposite here in this forum
from time to time - from people complaining why C++ does not include a
GUI library as part of its standard, for example.

[Cholo Lennon]

On 04/10/2013 08:14 AM, Alexander Terekhov wrote:
>
> Just wait till Apple comes up with cool
> watch/glasses/TV/fridge/microwave/toaster/whatnot with apps programmed
> in Objective-C and it will become number one for sure... see charts at
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>
> ;-)
>
> Not so long ago:
>
> http://www.infoworld.com/d/application-development/apples-popularity-boosts-objective-c-language-past-c-197083
>
> "Apple's popularity boosts Objective-C language past C++
>
> Used for building iPad and iPhone apps, Objective-C takes over third
> place in Tiobe language survey, knocking C++ to fourth"
>

I completely agree with someone who posted the following in response to
the article you mentioned:


"Rankings are determined by activity in search engines and other 'buzz'.
So an established language that is well known will have little activity
and have a low ranking by this method. I'm taking this story with a big
grain of salt."


Tiobe is just a partial point of view...

Regards

--
Cholo Lennon
Bs.As.
ARG

[Victor Bazarov]

On 4/10/2013 10:00 AM, Martin Ba wrote:
>[..]

> 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.
>
> The bigger and more complex the std-library gets, the more likely it
> gets that different vendor implementations would have subtle differences
> that would break portability vs. having a single-source library (like
> Boost) that uses at least the "same" source code on all platforms.
>
> just a thought.

By definition, if something in the Standard and *specified*, it can't be
non-portable. Every implementation of the library shall behave in the
expected way, otherwise it can't be called "standard-compliant". And
that's the Committee's task to ensure that whatever is *specified* is
/not/ *under*-specified, which usually means "left to the
implementation", and thus breeds incompatibility. So, banish the
thought, it doesn't do you (or anybody else) any good to worry about
things that don't yet exist.

Subtle difference do exist, and it's OK, as long as they are in respect
to the portions of the behaviour that are actually left un- or
under-specified.

The old (and still true, AFAICT) example of this is virtual functions or
references. How they are implemented (vtbl, readonly pointers) is of no
concern of the Standard. However, if *you* start relying on some
particular implementation of the feature that in the language or library
is left to the implementation, it's not the Standard's fault when you
find your code non-portable...

V
--
I do not respond to top-posted replies, please don't ask

[osmium]

One of the reasons often cited for the failure of Algol 60, was the failure
to include I/O in the standard. (I got exposed to it by my boss, who had
recently returned from Europe, where Algol did have a certain amount of
success.)

ISTM that C++ has only a very constrained I/O without GUI. In a post I made
in another thread, it was meant to be implicit that the three guys who could
leave the meeting, had no background in the "whatchamcallit" GUI.

[Jorgen Grahn]

On Wed, 2013-04-10, 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. 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.

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

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.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Nobody]

On Wed, 10 Apr 2013 16:29:50 +0000, Stefan Ram wrote:

> Cholo Lennon <cholo...@hotmail.com> writes:
>>Tiobe is just a partial point of view...
>

> Then show me the other points of view that are based on
> such a wide variety of sources observed for so many years.

The issue isn't the number of sources, but their quality.

Tiobe doesn't represent the actual usage of a language so much as the
derivative of usage with respect to time.

If a language obtains a sudden spike in popularity (e.g. because Apple's
latest iGimmick requires Objective-C and everyone wants in on the
bandwagon), you'll see a spike in "internet buzz" for that language.

The spike will disappear either:
a) when people have actually become familiar enough with the language that
they no longer need to ask about it or evangelise it, and are just
using it regularly, or:
b) when everyone forgets about it and chases a different bandwagon.

Once the spike disappears, it's impossible to tell whether it's because of
a) or b).

[Öö Tiib]

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?

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

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

[Nobody]

On Wed, 10 Apr 2013 16:00:19 +0200, Martin Ba wrote:

> 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.
>
> The bigger and more complex the std-library gets, the more likely it
> gets that different vendor implementations would have subtle differences
> that would break portability vs. having a single-source library (like
> Boost) that uses at least the "same" source code on all platforms.

If the behaviour is left as "implementation-defined", then it's almost
inevitable that it will differ between platforms.

If the standard dictates the behaviour down to the smallest detail, any
conforming implementation would need to include an OS kernel and
virtualisation layer, because using the platform's native facilities
directly will result in non-conforming behaviour.

Of course, the end result of the latter approach would be that no-one
bothers implementing a conforming implementation, because no-one would use
it. Instead, you'd have a variety of almost-conforming implementations,
each with different conformance/practicality trade-offs.

[Martin Ba]

On 10.04.2013 17:11, Victor Bazarov wrote:
> On 4/10/2013 10:00 AM, Martin Ba wrote:
>> [..]
>> 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.
>>
>> The bigger and more complex the std-library gets, the more likely it
>> gets that different vendor implementations would have subtle differences
>> that would break portability vs. having a single-source library (like
>> Boost) that uses at least the "same" source code on all platforms.
>>
>> just a thought.
>
> By definition, if something in the Standard and *specified*, it can't be
> non-portable. Every implementation of the library shall behave in the
> expected way, otherwise it can't be called "standard-compliant". And

And who of the implementers cares enough? It's not like anyone can force
them to be fully standard-compliant.

And, anyway, I was more thinking of bugs in the implementations vs. the
standard-defined-behavior. It doesn't do you any good when the standard
mandates something, but your implementations have not implemented it
correctly and you cannot switch the implementation on a platform on a whim.

I was more thinking of practical portability-problems-count: What is
better? std-defined-behavior and independent implementations, or "one"
open source like implementation that you can use across platforms. I
guess all I can do is lean back and see, and that's what I plan to do.

> that's the Committee's task to ensure that whatever is *specified* is
> /not/ *under*-specified, which usually means "left to the
> implementation", and thus breeds incompatibility. So, banish the
> thought, it doesn't do you (or anybody else) any good to worry about
> things that don't yet exist.
>

Once they do exists, it will be too late, won't it? :-)

[Rui Maciel]

Stefan Ram wrote:

> Cholo Lennon <cholo...@hotmail.com> writes:

>>Tiobe is just a partial point of view...
>

> Then show me the other points of view that are based on
> such a wide variety of sources observed for so many years.

The tiobe index is fundamentally meaningless. It builds its rating by
counting search hits on sites such as youtube and amazon.

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm


It would be silly if someone picked which language would be the foundation
of his programming career by checking which had more hits on youtube.


Rui Maciel

[Rui Maciel]

Stefan Ram wrote:

>>Tiobe doesn't represent the actual usage of a language
>

> What is »the actual usage of a language« (in terms
> of a number that fits in a table)?
>
> How can one measure it?

Searching through the repositories of some software hosting services, such
as sourceforge, google code or github, would be a start.

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities


Some services even compile some interesting statistics, such as:

https://github.com/languages


Rui Maciel

[Bo Persson]

Boost is definitely NOT using the same source code on all platforms. It
uses tons of configuration macros and workarounds to make the
implementation compile on all supported compilers.

In some of the Boost libraries it is actually hard to find any code at
all without first going through 10 layers of macros and system specific
include files.


Bo Persson

[Ian Collins]

Until you want a generic object....

--
Ian Collins

[Ian Collins]

Stefan Ram wrote:

> Ian Collins <ian-...@hotmail.com> 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.

Boost.Any?

> So, there are no �generic objects�.

I'm sure you know what I mean.

Even simple class templates like the humble auto_ptr are very useful in
kernel land. If you look at all the spaghetti clean up code often found
in C kernel code, you'll see why.

--
Ian Collins

[Jorgen Grahn]

On Wed, 2013-04-10, Stefan Ram wrote:

> Jorgen Grahn <grahn...@snipabacken.se> 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". 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.

[Scott Lurndal]

_want_ and _need_ are two different things.

One can certainly write object-oriented code without a generic object.

[Scott Lurndal]

r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Distribution through any means other than regular usenet
>
> channels is forbidden. It is forbidden to publish this
>
> article in the world wide web. It is forbidden to change
>
> URIs of this article into links. It is forbidden to remove
>
> this notice or to transfer the body without this notice.
>X-No-Archive: Yes
>Archive: no
>X-No-Archive-Readme: "X-No-Archive" is only set, because this prevents some
>
> services to mirror the article via the web (HTTP). But Stefan Ram
>
> hereby allows to keep this article within a Usenet archive server
>
> with only NNTP access without any time limitation.
>X-No-Html: yes
>Content-Language: en
>X-Received-Bytes: 2180
>Xref: news.usenetserver.com comp.lang.c++:401148

>
>Ian Collins <ian-...@hotmail.com> 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�.
>

>>Scott Lurndal wrote:
>>>IMO, it is data-encapsulation and objects (classes) that make C++ superior
>>>to C. Neither of which require templates.
>

> C has objects. And types like �FILE� encapsulate.

C doesn't enforce data encapsulation (public/private/protected). C doesn't have
virtual functions (polymorphism).

scott

[Ian Collins]

One can also apply the same argument to data encapsulation and objects.

In my experience with drivers and other kernel modules, heterogeneous
resource management is more of an issue than it is in user space. One
significant benefit C++ can bring in this area is removal of all the "if
(some error) goto end" spaghetti. Yes you could write a small class for
each resource type, but why bother when we have templates?

--
Ian Collins

[Rui Maciel]

Scott Lurndal wrote:

> C doesn't enforce data encapsulation (public/private/protected). C
> doesn't have virtual functions (polymorphism).

C doesn't have explicit support for virtual functions in its core language.

Having said that, if anyone is willing to put in the legwork, function
pointers are all that is needed to simulate virtual functions.


Rui Maciel

[88888 Dihedral]

Rui Maciel於 2013年4月11日星期四UTC+8上午5時38分49秒寫道：

> Scott Lurndal wrote:
>
>
>
> > C doesn't enforce data encapsulation (public/private/protected). C
>
> > doesn't have virtual functions (polymorphism).
>
>
>
> C doesn't have explicit support for virtual functions in its core language.
>

Don't you use hookers or so called functors to wrap your
platform dependent part in C?

>
> Having said that, if anyone is willing to put in the legwork, function
>
> pointers are all that is needed to simulate virtual functions.
>

I'll give an example as follows:
If the information about the platform is well collected
first, then a well behavior functor can be set
before entering the inner loop of a time critical task.

Don't you get the notion about the run-time behaviors?

[Robert Wessel]

On 10 Apr 2013 17:57:40 GMT, r...@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Nobody <nob...@nowhere.com> writes:
>>>Cholo Lennon <cholo...@hotmail.com> writes:
>>>>Tiobe is just a partial point of view...
>>>Then show me the other points of view that are based on
>>>such a wide variety of sources observed for so many years.
>>The issue isn't the number of sources, but their quality.
>

> �Wide variety� does not mean �large number�.
>
> �Quality� is entirely subject/undefined, unless you give an
> operational definition of more specific means how to measure
> the quality. Maybe you like to blur things up to the point
> where you cannot be proven false anymore.

>
>>Tiobe doesn't represent the actual usage of a language
>

> What is �the actual usage of a language� (in terms

> of a number that fits in a table)?
>
> How can one measure it?

From the point of view of someone looking for employment, the number
of hours spent per year programming* in that language would be a good
metric. A statistically valid sample of programmers documenting what
they spent their time doing in the past month could lead to such an
estimate (although it would obviously be much more work than counting
Facebook mentions).


*Which needs a suitable definition, of course - looking at old code,
writing new code, modifying existing code, testing, debugging, etc.
would need to be included, while many of the other "programming" tasks
would not (fighting with the SCM, working on your build processes,
scripting the Q/A stuff, etc.).

[Paavo Helde]

Martin Ba <0xcdc...@gmx.at> wrote in news:kk4al2$e0$1...@dont-email.me:

>>> The bigger and more complex the std-library gets, the more likely it
>>> gets that different vendor implementations would have subtle
>>> differences that would break portability vs. having a single-source
>>> library (like Boost) that uses at least the "same" source code on
>>> all platforms.

[...]

>
> And, anyway, I was more thinking of bugs in the implementations vs.
> the standard-defined-behavior. It doesn't do you any good when the
> standard mandates something, but your implementations have not
> implemented it correctly and you cannot switch the implementation on a
> platform on a whim.

Why do you think that there can't be bugs in e.g. in a Boost library
implementation on different platforms? Parts of Boost code seem to
consist only of feature test macros and various workarounds for different
platforms. Even if the source code is the same for different platforms
there may be subtle differences in how it functions (e.g. return code of
vsnprintf()). If you look at the Boost bugtracker you see that many bugs
are present only on specific platforms.

How is a group of volunteers supposed to guarantee that their library
always works correctly on an open-ended and constantly changing set of
proprietary implementations? They can't. When a new version of some C++
compiler suite comes out (not to speak about a new C++ implementation!),
the existing Boost libraries often cease to compile or work with it, and
there is some time window before the issues (hopefully) get fixed in the
next Boost versions. This is something the standardization is supposed to
get rid of.

If the vendors are not able or willing to follow the standards (like MS
in the past), then a third-party library or something is needed for
leveraging the differences. However, this is not an ideal solution.

Cheers
Paavo

[Öö Tiib]

On Wednesday, 10 April 2013 23:02:24 UTC+3, Stefan Ram wrote:
> Ian Collins <ian-...@hotmail.com> 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.

[Rui Maciel]

Paavo Helde wrote:

> When a new version of some C++
> compiler suite comes out (not to speak about a new C++ implementation!),
> the existing Boost libraries often cease to compile or work with it, and
> there is some time window before the issues (hopefully) get fixed in the
> next Boost versions. This is something the standardization is supposed to
> get rid of.

A standard doesn't help here, as well.

Look at how the people at Microsoft decided to develop their "learn to
program for windows in C++" bit[1]. C++'s fundamental types aren't used,
and in alternative Microsoft decided to define new types which share their
name with C++'s fundamental types, minnus the capitalization, and explicitly
tell the users that they are not interchangeable.

This doesn't stop on fundamental types: it only starts from there. For
example, instead of using std::string, let alone the STL, they've repeatedly
chose to use anything else.

This is being done in the same organization and maybe even by the same
people who work with C++'s standard committee to open the door to an
avalange of bloat which apparently they have no intention to implement.


Rui Maciel

[1] http://msdn.microsoft.com/en-
us/library/windows/desktop/ff381399%28v=vs.85%29.aspx

[guinne...@gmail.com]

On Wednesday, 10 April 2013 19:36:01 UTC+1, Stefan Ram wrote:

> Martin Ba <0xcdc...@gmx.at> writes:
>
> >And who of the implementers cares enough?
>
>
>

> Comeau cared enough to implement »export«. And how did they
>
> honour this? By removing »export« from the standard!
>
>
>
> I also have not heard about Comeau products for some months.

comeaucomputing.com has been down for some months.

Greg tweeted some status updates here:

https://twitter.com/comeaucomputing

[Spike]

On 11/04/2013 09:29, Rui Maciel wrote:
>
> Look at how the people at Microsoft decided to develop their "learn to
> program for windows in C++" bit[1]. C++'s fundamental types aren't used,
> and in alternative Microsoft decided to define new types which share their
> name with C++'s fundamental types, minnus the capitalization, and explicitly
> tell the users that they are not interchangeable.
>
> This doesn't stop on fundamental types: it only starts from there. For
> example, instead of using std::string, let alone the STL, they've repeatedly
> chose to use anything else.

The title can be deceiving, I know, but that series basically hasn't
anything to do with C++, it is about a "C" API, born two decades ago and
not really changed ever since.

S.

[Martin Shobe]

On 4/11/2013 2:29 AM, Rui Maciel wrote:
[snip]

> Look at how the people at Microsoft decided to develop their "learn to
> program for windows in C++" bit[1]. C++'s fundamental types aren't used,
> and in alternative Microsoft decided to define new types which share their
> name with C++'s fundamental types, minnus the capitalization, and explicitly
> tell the users that they are not interchangeable.
>
> This doesn't stop on fundamental types: it only starts from there. For
> example, instead of using std::string, let alone the STL, they've repeatedly
> chose to use anything else.

That's a windows API tutorial, not a C++ one. So, considering that those
interfaces (and the types they use) predate C++, and also the need for
them to work in C (and a host of other languages), is it really that
surprising?

>
> This is being done in the same organization and maybe even by the same
> people who work with C++'s standard committee to open the door to an
> avalange of bloat which apparently they have no intention to implement.
>

Which parts of C++ are they not intending to implement?

Martin Shobe


>[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ff381399%28v=vs.85%29.aspx

[Victor Bazarov]

On 4/10/2013 2:25 PM, Martin Ba wrote:
> On 10.04.2013 17:11, Victor Bazarov wrote:
>> On 4/10/2013 10:00 AM, Martin Ba wrote:
>>> [..]

> [..]

>> that's the Committee's task to ensure that whatever is *specified* is
>> /not/ *under*-specified, which usually means "left to the
>> implementation", and thus breeds incompatibility. So, banish the
>> thought, it doesn't do you (or anybody else) any good to worry about
>> things that don't yet exist.
>>
>
> Once they do exists, it will be too late, won't it? :-)

Not really.

First off, the Standard is not set in stone, it's a document that can
and does change. If something in it is not to your liking, convince
enough people and a change can and will be made.

Second, the life is full of trade-offs (surprise!), so if something is
not up to your [personal] liking, you don't have to use it. If it is
your employer that insists on your using something you don't like,
change the employer, et cetera.

Third, let's take some alternatives that are still open to us in some
cases. Let's suppose nothing is standardized. Everything is specific
to the implementation or to the platform. No code is then portable
(unless by accident). Is that viable? I don't think so. Let's now
suppose everything is standardized to a minute detail. The code *you*
write is portable to no exception. You "write once, compile anywhere"
regardless of what you're programming (and I do mean *anywhere* where it
is *already, as of now*, not just on a few choice platforms, fewer every
year). Is it attainable? Probably not. Implementors will have really
hard time with it (harder and harder as we go along). Now, using the
mean value theorem essentially gives us that, if on both ends of the
continuum the values (in this case usability) are 0 (either from
uselessness from our POV or inability to implement a compiler/library
satisfactorily), then either the entire range is useless (no sense to
even attempt specifying anything), or there has to be at least *one
point* in the middle where the value (usability) is *maximized*. And
that is what the efforts are expended to attain. We're trying to find
the best of both worlds, so to speak; not too hard to implement, and not
impossible to use.

Now, with the changing technologies, with some elements of the computer
capabilities becoming more widespread, the target point keeps moving.
And that's why new elements come into view, and admitted to being
discussed. Dismissing them *before ever trying to specify them*, just
based on a notion that, if mistakes are made in the implementation (some
time after the specification has been created), or if when using the
implementations we (even later than the Standard) discover that
something still is not to our liking, is IMNSHO meritless. It's the
same as saying that we shouldn't start on a journey just because there
is a possibility the journey can lead us to our death! What kind of
philosophy is that?

V
--
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

On 4/11/2013 10:20 AM, Stefan Ram wrote:

> Victor Bazarov <v.ba...@comcast.invalid> writes:
>> Is it attainable? Probably not. Implementors will have
>> really hard time with it (harder and harder as we go along).
>

> People took former implementations, like Pet 2001, Amiga, or
> HP 48 as standards and wrote emulators for it, exactly to
> that minute detail: emulating special hardware, video-
> timing, sound-hardware, device interfaces, and everything.
>
> Thanks to those emulators, software for the Pet 2001, Amiga,
> or HP 48 is now most portable, because those emulators exist
> for most operating systems. Ironically, this code, which was
> written not at all with portability in mind, nowadays is
> more portable that code written in today's �portable� languages.

It's interesting. So, your suggestion, then, is to abandon the
standardization efforts, write non-portable code, all in hopes that one
day there will be emulators to run all that non-portable code on all
systems where the emulators have been implemented... :-)

[Paavo Helde]

Rui Maciel <rui.m...@gmail.com> wrote in
news:kk5okl$ioc$1...@dont-email.me:

> Look at how the people at Microsoft decided to develop their "learn to
> program for windows in C++" bit[1]. C++'s fundamental types aren't
> used, and in alternative Microsoft decided to define new types which
> share their name with C++'s fundamental types, minnus the
> capitalization, and explicitly tell the users that they are not
> interchangeable.
>
> This doesn't stop on fundamental types: it only starts from there.
> For example, instead of using std::string, let alone the STL, they've
> repeatedly chose to use anything else.

This is more from earlier times, like last century or so. Nowadays it
seems they have too much developers who have nothing better to do, so
they prefer to develop whole new languages in order to lock people on
their platform.

> This is being done in the same organization and maybe even by the same
> people who work with C++'s standard committee to open the door to an
> avalange of bloat which apparently they have no intention to
> implement.

MS has been quite good in implementing C++0x features recently, I do not
see much need to worry. See
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

And yes, I do not think C++0x is too bloated. Implementing the library
parts should be relatively easy as one has Boost as a good reference
implementation.

Cheers
Paavo

[Martin Ba]

On 11.04.2013 16:00, Victor Bazarov wrote:
> On 4/10/2013 2:25 PM, Martin Ba wrote:
>> On 10.04.2013 17:11, Victor Bazarov wrote:
>>> On 4/10/2013 10:00 AM, Martin Ba wrote:
>>>> [..]
>> [..]
>>> that's the Committee's task to ensure that whatever is *specified* is
>>> /not/ *under*-specified, which usually means "left to the
>>> implementation", and thus breeds incompatibility. So, banish the
>>> thought, it doesn't do you (or anybody else) any good to worry about
>>> things that don't yet exist.
>>>
>>
>> Once they do exists, it will be too late, won't it? :-)
>
> Not really.

> ...

> Third, let's take some alternatives that are still open to us in some

> cases. Let's suppose nothing is standardized. ... Let's now
> suppose everything is standardized to a minute detail. ... We're trying to find

> the best of both worlds, so to speak; not too hard to implement, and not
> impossible to use.
>

> ... Dismissing them *before ever trying to specify them*, just

> based on a notion that, if mistakes are made in the implementation (some
> time after the specification has been created), or if when using the
> implementations we (even later than the Standard) discover that
> something still is not to our liking, is IMNSHO meritless.

FWIW, I found the very original post (C++14 papers -- "kitchen sink ...
sanitary network ...") rather stupid.

I *don't* think that C++11 contains too much by *any* account, and
already it seems that implementors are struggling to get everything in
it implemented in a decent time frame.

I really do look forward to more useful stuff in C++ "out of the box",
but let's just hope the the quality doesn't suffer from too much in too
little time.

cheers,
Martin

[James Kanze]

On Wednesday, April 10, 2013 6:57:40 PM UTC+1, Stefan Ram wrote:
> Nobody <nob...@nowhere.com> writes:

[...]

> What is »the actual usage of a language« (in terms
> of a number that fits in a table)?

That is, I think, the real question. Until it has been
answered, all of the sites which pretend to measure which
language is most used are just showing their incompetence (or
dishonesty, perhaps, in some cases).

All I claim is that there is a large class of applications for
C++ is more or less the only solution. Today (and I often
wonder why Ada 95 didn't get more consideration). It wasn't
necessarily true in the past, and perhaps it won't be true in
the future, although I don't see any potential concurrent being
developped at the moment.

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.

--
James

[James Kanze]

On Wednesday, April 10, 2013 12:59:53 PM UTC+1, osmium wrote:
> 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.

I can sympathize with most of your complaints. However:

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

Very few programs actually interface directly with humans. And
C++ is probably not the best choice for a light weight GUI
client.

(Actually, I'm not really sure what I mean by "very few
programs". People are constantly recreating new GUI interfaces
to conform to the look of the day. The real work will still be
done by the C++ program behind them, but that's one program,
probably originally written some years ago, but still evolving,
versus five or ten different programs, each written in maybe
three months, then thrown out when the next one comes along.)

--
James

[James Kanze]

On Wednesday, April 10, 2013 2:46:39 PM UTC+1, Scott Lurndal wrote:

> James Kanze <james...@gmail.com> 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

[James Kanze]

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

[James Kanze]

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

[woodb...@gmail.com]

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

[James Kanze]

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

[James Kanze]

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

[Öö Tiib]

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.

[Rui Maciel]

Öö 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::optional
- 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

[Martin Ba]

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

[Öö Tiib]

On Sunday, 14 April 2013 18:26:48 UTC+3, James Kanze wrote:
> 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 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.

What are the better ways? Some sort of "variant", "any" or 'union'?

[James Kanze]

I think I missed the second word in "generic object". Generics
have been around for years, and don't need type erasure.
"Generic objects", on the other hand, are something to be
avoided, at least in languages with some sort of static typing.
(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.)

--
James

[James Kanze]

On Tuesday, 16 April 2013 09:14:11 UTC+1, Martin T. wrote:
> 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.

You mean, except the fact that they don't implement them as they
are defined in the standard. They don't understand dependent
names, for example, which is a fundamental aspect of standard

templates.

> Most of Boost seems to manage to compile fine too.

You *can* work around the differences, and Boost does a lot of
working around. It does make writing portable code extremely
difficult.

[...]

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

I think you missed most of the history. Herb Sutter was the one
who started the movement against export, writing that it
couldn't be implemented (when EDG was well along the way to
implementing it). EDG finally accepted the removal, mainly,
I suspect, because they wanted unity in the C++ community, and
Microsoft wasn't going to let up until they got what they
wanted. (On this issue---since Herb Sutter has been at
Microsoft, they've generally been quite understanding with
regards to building concensus, and willing to adapt to the
prevailing consensus, rather than force issues. Why they felt
so strongly with regards to export, I don't know.)

--
James

[Andy Champ]

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.

Andy

[Sam]

I don't think there's anything inherently wrong with "most classes derive
from object". Having an object superclass does have many advantages.

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.

[Jorgen Grahn]

On Sun, 2013-04-14, Stefan Ram wrote:
> James Kanze <james...@gmail.com> 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

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

Not really. C++ supports comments, which solves the problem.
It doesn't standardize extraction of documentation, but that
problem is not as urgent in a language with header files.

(Based on my experience not with Java but with Python. In C and C++ I
rarely spend time extracting the (Doxygen) documentation; in Python I
do 'pydoc Foo' all the time because I can't get that overview in any
other easy way.)

> while Java
> has JavaDoc, so a real Java interface file looks more like:

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Balog Pal]

On 4/14/2013 5:34 PM, James Kanze wrote:
>> 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).

Err, do you mean their reluctance to implement two-phase lookup, and use
single lookup in the instantiation context? Which is WAYS more intuitive
in the (actually pretty rare) cases that it creates a difference?

2PhL is something I ask as a joke, or is someone claims mastery in C++
-- would not hold my breath to get a precise answer except from a
handful of people.

> Earlier, they refused to implement export

Just as the whole world except a single group, that eventually also
asked for its pull from the standard.

>, and pushed for its
> removal (which they obtained).

*Everyone* pushed for that actually.

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

I just talked with Herb hours ago, he strictly refused to disclose
anything about plans, but I had the impression they are taking up
serious speed, and might release C++14 features and the concepts lite TS
about same time as others.

My practical problem with MS is not their new feature release speed but
that they are routinely closing admitted code generation bugs with NOFIX
and the race condition-ridden unstable IDE.

[Balog Pal]

On 4/15/2013 8:39 PM, Rui Maciel wrote:
> 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:

As I understand it C++14 will be a MINOR (rather than bugfix as '03) and
'17 a MAJOR, followed by a similar 3-3 year cycles.

As it looks now chances are good we'll see a ton of cool new stuff
around '14. Stay tuned this Friday and Saturday.

[Balog Pal]

On 4/16/2013 1:28 PM, James Kanze wrote:
> On Tuesday, 16 April 2013 09:14:11 UTC+1, Martin T. wrote:
>> 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.
>
> You mean, except the fact that they don't implement them as they
> are defined in the standard. They don't understand dependent
> names, for example, which is a fundamental aspect of standard
> templates.

You mean the *in*dependent names, and not *bind* them early?

I think it would help a lot if you showed an example on the difference
of behavior so everyone could see it exposed for good.

>> Most of Boost seems to manage to compile fine too.
>
> You *can* work around the differences, and Boost does a lot of
> working around. It does make writing portable code extremely
> difficult.

As I looked at boost code most workarounds belong to other compilers.

The more realistic differences I'd expect related to SFINAE, but I'd bet
it's not realy common to get it right all the way. ;-o

> [...]
>>> 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.
>
> I think you missed most of the history. Herb Sutter was the one
> who started the movement against export, writing that it
> couldn't be implemented (when EDG was well along the way to
> implementing it).

For cartain definition of "started". I doubt you can find anyone
involved with the C++ standard to call export other then "catastrophic
failure".

> EDG finally accepted the removal, mainly,
> I suspect, because they wanted unity in the C++ community,

Yeah, pretty close. As the committee considered waiting for them to ask
as the only politically correct thing (using the original meaning) [that
is what FG. told me a few days ago.]

[Martin Shobe]

On 4/16/2013 9:05 PM, Balog Pal wrote:
> On 4/16/2013 1:28 PM, James Kanze wrote:
>> On Tuesday, 16 April 2013 09:14:11 UTC+1, Martin T. wrote:
>>> 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.
>>
>> You mean, except the fact that they don't implement them as they
>> are defined in the standard. They don't understand dependent
>> names, for example, which is a fundamental aspect of standard
>> templates.
>
> You mean the *in*dependent names, and not *bind* them early?
>
> I think it would help a lot if you showed an example on the difference
> of behavior so everyone could see it exposed for good.

See

http://www.codeproject.com/Articles/229460/Dependant-Name-Hell

I didn't verify with the standard that those situations require
diagnostics, but I suspect they do. (They also fixed the fourth one in
2010 and Microsoft says (but I haven't verified) that the third one was
fixed in 2012.

[snip]

Martin Shobe