Discussion:
Thumbs Up for No Graphics
(too old to reply)
m***@gmail.com
2018-06-01 12:00:48 UTC
Permalink
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>

I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".

Here is why:
- *Impossible* to keep up-to date with modern trends - *both* hardware,
algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms or
implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many other
features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the community)
will waste time considering, probably without even having the expertise for
that!
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org.
Richard Hodges
2018-06-01 14:15:23 UTC
Permalink
Post by m***@gmail.com
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".

While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.

At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.

In my view this is a shame.
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both* hardware,
algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms or
implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the community)
will waste time considering, probably without even having the expertise for
that!
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com.
Corentin
2018-06-01 14:29:36 UTC
Permalink
Post by Richard Hodges
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.

I think most people would agree with that observation.
But what we need is a better way to collecting bits and pieces, not to put
the whole world in the standard to make up for insufficient tooling !
Post by Richard Hodges
Post by m***@gmail.com
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
In my view this is a shame.
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both* hardware,
algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms or
implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the community)
will waste time considering, probably without even having the expertise for
that!
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com.
Richard Hodges
2018-06-01 14:32:50 UTC
Permalink
Post by Corentin
But what we need is a better way to collecting bits and pieces, not to
put the whole world in the standard to make up for insufficient tooling !

A standard way, even?
Post by Corentin
Post by Richard Hodges
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
I think most people would agree with that observation.
But what we need is a better way to collecting bits and pieces, not to put
the whole world in the standard to make up for insufficient tooling !
Post by Richard Hodges
Post by m***@gmail.com
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
In my view this is a shame.
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both*
hardware, algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms
or implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the
community) will waste time considering, probably without even having the
expertise for that!
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbeANpuC-O%3DEWxH206KG%3DWDrFwCiruoxc_02rfDooZcNg%40mail.gmail.com.
Nicol Bolas
2018-06-01 15:06:11 UTC
Permalink
Post by Richard Hodges
Post by Corentin
But what we need is a better way to collecting bits and pieces, not to
put the whole world in the standard to make up for insufficient tooling !
A standard way, even?
If by "standard" you mean "supported in all environments", yes. If by
"standard" you mean "defined in the ISO C++ standard", then no.

While the C++ standard can certainly take tooling into account, and even
make suggestions, it can't *define* how tools work the way it defines how
the object model and so forth work.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/77f5ed53-0673-4382-b579-5d08794c3805%40isocpp.org.
Rene Rivera
2018-06-01 17:28:28 UTC
Permalink
Post by Nicol Bolas
While the C++ standard can certainly take tooling into account, and even
make suggestions, it can't *define* how tools work the way it defines how
the object model and so forth work.
Why "can't [it] define how tools work"? After all it already defines that
there is a source to executable transformation tool.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gje7bTjm-syUtcWP4kg3bxrbrARB6d4%2BcdqGp%3DVWffvpA%40mail.gmail.com.
Nicol Bolas
2018-06-01 18:46:33 UTC
Permalink
Post by Rene Rivera
Post by Nicol Bolas
While the C++ standard can certainly take tooling into account, and even
make suggestions, it can't *define* how tools work the way it defines
how the object model and so forth work.
Why "can't [it] define how tools work"? After all it already defines that
there is a source to executable transformation tool.
No, it does not. Nowhere does the standard talk about an "executable". It
describes the behavior of an implementation, which *could be* an
interpreter for all the standard cares.

Now, the committee could produce some kind of technical report about how to
go about making build systems compatible with each other or some such (and
if it leads to unification, I'm all for it). But this would not be part of
the C++ standard itself.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5e4d757d-b3ef-4ac6-b2d2-4802ce2fbef0%40isocpp.org.
Rene Rivera
2018-06-01 19:08:00 UTC
Permalink
Post by Nicol Bolas
Post by Rene Rivera
Post by Nicol Bolas
While the C++ standard can certainly take tooling into account, and even
make suggestions, it can't *define* how tools work the way it defines
how the object model and so forth work.
Why "can't [it] define how tools work"? After all it already defines that
there is a source to executable transformation tool.
No, it does not. Nowhere does the standard talk about an "executable". It
describes the behavior of an implementation, which *could be* an
interpreter for all the standard cares.
Okay... But it does talk about linking TUs into a program. Which
practically has a limited set of meanings.
Post by Nicol Bolas
Now, the committee could produce some kind of technical report about how
to go about making build systems compatible with each other or some such
(and if it leads to unification, I'm all for it). But this would not be
part of the C++ standard itself.
Right.. But, again, why can't the standard specify behavior of tools? What
prevents such a specification from being adopted, assuming someone proposes
it?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gg46a5wbbE_q0vre9FNicAZZB_Mq5aFVMhmQAK6yWK1yw%40mail.gmail.com.
Thiago Macieira
2018-06-02 01:36:27 UTC
Permalink
Post by Rene Rivera
Right.. But, again, why can't the standard specify behavior of tools? What
prevents such a specification from being adopted, assuming someone proposes
it?
Try and we'll see.

What tools are you talking about anyway?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1743822.X6ygPEYEuq%40tjmaciei-mobl1.
Rene Rivera
2018-06-02 02:00:52 UTC
Permalink
Post by Rene Rivera
Post by Rene Rivera
Right.. But, again, why can't the standard specify behavior of tools?
What
Post by Rene Rivera
prevents such a specification from being adopted, assuming someone
proposes
Post by Rene Rivera
it?
Try and we'll see.
I am going to try (I actually started on such a try last Fall). But I was
really curious as to why people think it's not possible. So as to try and
avoid roadblocks.

What tools are you talking about anyway?
The compiler of course. As it's the first step in being able to define
common aspects for build systems and package managers.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GjqfQeTGVM0dkULGYNzMyOzXDf3aJJdLR6qgvj0peQLOg%40mail.gmail.com.
Jake Arkinstall
2018-06-02 02:17:41 UTC
Permalink
Related: https://xkcd.com/927/

Personally, I don't think the resources are worth the outcome. I look
forward to seeing the results of any efforts towards a proposal, though, in
the hope that it will change my mind.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJqbCNgSt%2Bz9ctBC3HknBecU5kBsfszgVjdbJzFrN3%2Bw%40mail.gmail.com.
Thiago Macieira
2018-06-02 03:15:19 UTC
Permalink
Post by Rene Rivera
The compiler of course. As it's the first step in being able to define
common aspects for build systems and package managers.
Compilers are actually mostly compatible with each other. This goes back to
the early days of "cc", the C compiler that came with Unix. Since almost every
single compiler invented is meant to be a drop-in replacement to an earlier
compiler, almost all of them behave the same way in the core functionality.

Except for MSVC (and ICC on Windows and Clang-cl), which in turn are meant to
be compatible with the older C compilers on DOS, which used options slightly
differently because of limitations of that system. And still they are mostly
compatible with their Unix counterparts, except for one gratuitous change:
naming the object files .obj, instead of .o.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8539420.4ZEJzz54VO%40tjmaciei-mobl1.
Nicol Bolas
2018-06-02 05:02:09 UTC
Permalink
Post by Rene Rivera
Post by Rene Rivera
Post by Rene Rivera
Right.. But, again, why can't the standard specify behavior of tools?
What
Post by Rene Rivera
prevents such a specification from being adopted, assuming someone
proposes
Post by Rene Rivera
it?
Try and we'll see.
I am going to try (I actually started on such a try last Fall). But I was
really curious as to why people think it's not possible. So as to try and
avoid roadblocks.
The kind of tool you need to make it easy to download and build a random
C++ application is some form of build system. A *platform independent*
build system. That requires dealing with a lot of things that the C++
language standard doesn't even come close to.

Basically, think of the analogy like this. The works of Shakespeare, no
matter how interesting or wonderful they may be, are not appropriate for
inclusion in a *dictionary* or a book on grammar. These are two
different-yet-related things that exist in two different-yet-related
domains.

The same goes for the C++ language and a build system. Yes, we would love
to have a platform-independent build system. But that's not part of the
language, because that's not what the language is for.

What tools are you talking about anyway?
Post by Rene Rivera
The compiler of course. As it's the first step in being able to define
common aspects for build systems and package managers.
Where does the standard mandate the presence of a "compiler"? There is
merely the "implementation". Non-normative language may occasionally refer
to a "compiler", but as far as the normative standard is concerned, there
are just "implementations".

Nothing is said about the implementation, save for the fact that it
implements the standard as described.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9bad3834-d0d7-4642-ad8c-b44e0c9b3ce9%40isocpp.org.
Rene Rivera
2018-06-02 13:42:22 UTC
Permalink
Post by Nicol Bolas
Post by Rene Rivera
Post by Rene Rivera
Post by Rene Rivera
Right.. But, again, why can't the standard specify behavior of tools?
What
Post by Rene Rivera
prevents such a specification from being adopted, assuming someone
proposes
Post by Rene Rivera
it?
Try and we'll see.
I am going to try (I actually started on such a try last Fall). But I was
really curious as to why people think it's not possible. So as to try and
avoid roadblocks.
The kind of tool you need to make it easy to download and build a random
C++ application is some form of build system. A *platform independent*
build system. That requires dealing with a lot of things that the C++
language standard doesn't even come close to.
Yes, aware.. I wrote, and maintain, one of those.

Basically, think of the analogy like this. The works of Shakespeare, no
Post by Nicol Bolas
matter how interesting or wonderful they may be, are not appropriate for
inclusion in a *dictionary* or a book on grammar. These are two
different-yet-related things that exist in two different-yet-related
domains.
Interesting analogy.

The same goes for the C++ language and a build system. Yes, we would love
Post by Nicol Bolas
to have a platform-independent build system. But that's not part of the
language, because that's not what the language is for.
I don't disagree.
Post by Nicol Bolas
What tools are you talking about anyway?
Post by Rene Rivera
The compiler of course. As it's the first step in being able to define
common aspects for build systems and package managers.
Where does the standard mandate the presence of a "compiler"? There is
merely the "implementation". Non-normative language may occasionally refer
to a "compiler", but as far as the normative standard is concerned, there
are just "implementations".
Nothing is said about the implementation, save for the fact that it
implements the standard as described.
Are you saying that the reason we can't define X is because X is undefined?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GgjA8jg7Orqn%3D830D5gaK0n5vJMroRbQXkuyFWP3k85OQ%40mail.gmail.com.
Robert Ramey
2018-06-01 16:31:53 UTC
Permalink
Post by Corentin
But what we need is a better way to collecting bits and pieces, not
to put the whole world in the standard to make up for insufficient tooling !
A standard way, even?
Actually this is most valuable insight.

The standard works well for the language and certain core libraries such
as those required to create a common facade for the local operating system.

But it doesn't work well when trying to design library components by
committee. These components are too complex, too large, and the
environment is too dynamic to be done within the standards process.
People do create these components outside of the standards process:
Boost, CGal, Eigen and many, many, many others. And of course there is
GitHub. But these are not standardized - so what is the problem.

The problem is that they are not standardized. That is they are

a) of uneven quality
b) often not documented
c) evolve "too fast"
d) fail to present a single widely accepted interface. That is there
are often competing, different, but similar libraries which are meant to
address the same problem.
f) developers of libraries are not sufficiently funded to invest the
effort required to address the shortcomings above.
e) including packages of different versions from differing sources
creates difficulties in management of larger applications.

Assuming the above is an accurate description of the current and past
situation, what should be done.

I've got some ideas - but I'll leave that for a later post.

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pers9n%248ih%241%40blaine.gmane.org.
Hyman Rosen
2018-06-01 19:43:52 UTC
Permalink
Post by Robert Ramey
The problem is that they are not standardized.
The standardization of [filesystem] contributes 46 pages to the C++
Standard,
incorporates POSIX by reference, and is full of "for POSIX it does this and
for
Windows it does that" statements along with other waffling. (For example,
the
specification of absolute(const path&p) in [fs.op.absolute] contains this:
*Implementations are strongly encouraged to ... not consider !exists(p) an
error.*)

I submit that standardizing file system operation in the C++ Standard hasn't
really standardized much, since the underlying system dependencies are still
showing through and have to be accounted for, and has added complexity and
length to a standard that is already too complex and too long. Adding
graphics
would be a hundred times worse.

Programming language standards should define the programming language.
Functionality not required by the core language should be standardized
separately, if people are moved to do it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYkh1BJe3UHVP_8AtdEspvBBKNK9E2or%2BdFLH83ajgyuA%40mail.gmail.com.
Nicol Bolas
2018-06-01 20:15:53 UTC
Permalink
Post by Hyman Rosen
Post by Robert Ramey
The problem is that they are not standardized.
The standardization of [filesystem] contributes 46 pages to the C++
Standard,
incorporates POSIX by reference, and is full of "for POSIX it does this
and for
Windows it does that" statements along with other waffling.
Not one *normative* statement in the standard has any of this "waffling".
Any platform-specific information are in [notes], and therefore are not
required parts of the actual specification.

(For example, the
Post by Hyman Rosen
*Implementations are strongly encouraged to ... not consider !exists(p) an
error.*)
I submit that standardizing file system operation in the C++ Standard hasn't
really standardized much, since the underlying system dependencies are still
showing through and have to be accounted for, and has added complexity and
length to a standard that is already too complex and too long.
If you can write cross-platform code without a single `#ifdef WINDOWS` or
whatever, then the standard is doing its job. The existence of
implementation-dependent aspects of the standard does not mean that you
cannot write your code such that it works on all platforms.

Consider the statement on `absolute`. All you need to do is handle errors
that happen, to write your code as if you can't call it on a file that
doesn't exist. It's not a problem.

Adding graphics
Post by Hyman Rosen
would be a hundred times worse.
Programming language standards should define the programming language.
By that logic, we shouldn't have file APIs, streams, containers, atomics,
threads, or anything of that nature. Those aren't the "programming
language", so there's no need for any part of the standard library outside
of the language support library.

And what good would that have accomplished? How would that make C++ a
better programming environment?

Functionality not required by the core language should be standardized
Post by Hyman Rosen
separately, if people are moved to do it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2035f76f-5775-44c1-b9cc-e9249d9b8142%40isocpp.org.
Dilip Ranganathan
2018-06-01 20:51:41 UTC
Permalink
Post by Hyman Rosen
Post by Hyman Rosen
Post by Nicol Bolas
Adding graphics
would be a hundred times worse.
Post by Hyman Rosen
Programming language standards should define the programming language.
By that logic, we shouldn't have file APIs, streams, containers, atomics,
threads, or anything of that nature. Those aren't the "programming
language", so there's no need for any part of the standard library outside
of the language support library.
And what good would that have accomplished? How would that make C++ a
better programming environment?

I think you were too quick with that one. He wrote this in the very next
Post by Hyman Rosen
Post by Hyman Rosen
*Functionality not required by the core language should be standardized*
*separately*, if people are moved to do it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfuC%2BAVhdHdiGzFhj85AE-L_Ai_0837tGYCtxr4cMVEetA%40mail.gmail.com.
Nicol Bolas
2018-06-01 21:15:24 UTC
Permalink
Post by Nicol Bolas
Post by Hyman Rosen
Post by Hyman Rosen
Post by Nicol Bolas
Adding graphics
would be a hundred times worse.
Post by Hyman Rosen
Programming language standards should define the programming language.
By that logic, we shouldn't have file APIs, streams, containers, atomics,
threads, or anything of that nature. Those aren't the "programming
language", so there's no need for any part of the standard library outside
of the language support library.
And what good would that have accomplished? How would that make C++ a
better programming environment?
I think you were too quick with that one. He wrote this in the very next
Post by Hyman Rosen
Post by Hyman Rosen
*Functionality not required by the core language should be
standardized*
Post by Hyman Rosen
Post by Hyman Rosen
*separately*, if people are moved to do it.
I still fail to see how that makes C++ a better programming environment.

It's bad enough that we have compiler and standard library implementations
separately declaring "C++17 conformance". We really don't need the C++
language and standard library *standards* advancing at different rates.

Consider the spaceship operator. Adjusting the standard library to properly
take advantage of it is kind of important. Having that be a part of the
same standard release as the operator itself is equally important for
making the feature useful. What good is default generation of comparison
operators if some of your most commonly used types don't use it because
their standard hasn't been updated yet? If I can't even stick an
`optional<T>` in a type and have `operator<=> = default` work, how useful
will that feature be?

Indeed, if you look at the worst, most painful, or generally unpleasant
language features of C++ since C++11, more likely than not, the ones on
that list are the ones that are least used by the standard library.
"Uniform initialization" isn't used by `std::allocator::construct`,
`make_shared`, or similar features. Why? Because it's too broken to be used
in general in template contexts.

C++ needs to eat its own dogfood. The standard library is a way to do that.
Having the standard library directly linked to the language is a positive
thing for the language and for programmers working within that language.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8b16c598-0574-4590-bc7e-01d5429c652a%40isocpp.org.
m***@gmail.com
2018-06-01 21:16:23 UTC
Permalink
Post by Nicol Bolas
Post by Hyman Rosen
Post by Robert Ramey
The problem is that they are not standardized.
The standardization of [filesystem] contributes 46 pages to the C++
Standard,
incorporates POSIX by reference, and is full of "for POSIX it does this
and for
Windows it does that" statements along with other waffling.
Not one *normative* statement in the standard has any of this "waffling".
Any platform-specific information are in [notes], and therefore are not
required parts of the actual specification.
(For example, the
Post by Hyman Rosen
*Implementations are strongly encouraged to ... not consider !exists(p)
an error.*)
I submit that standardizing file system operation in the C++ Standard hasn't
really standardized much, since the underlying system dependencies are still
showing through and have to be accounted for, and has added complexity and
length to a standard that is already too complex and too long.
If you can write cross-platform code without a single `#ifdef WINDOWS` or
whatever, then the standard is doing its job. The existence of
implementation-dependent aspects of the standard does not mean that you
cannot write your code such that it works on all platforms.
Consider the statement on `absolute`. All you need to do is handle errors
that happen, to write your code as if you can't call it on a file that
doesn't exist. It's not a problem.
Adding graphics
Post by Hyman Rosen
would be a hundred times worse.
Programming language standards should define the programming language.
By that logic, we shouldn't have file APIs, streams, containers, atomics,
threads, or anything of that nature. Those aren't the "programming
language", so there's no need for any part of the standard library outside
of the language support library.
And what good would that have accomplished? How would that make C++ a
better programming environment?
I guess it is the ratio of uses vs diversity vs dynamic of the task that is
to be in a library.

Uses must be high, diversity (alternative interpretations of what it is,
different attack vectors, different priorities) low and dynamic (rate of
change) also low

All the things you mentioned fit the criteria ok, well or very well - Many
people use them, there are no grotesque alternative views of they are,
quite low dynamic (new "inventions" of these come rarely)

At higher level libraries things start to lose on these properties.

FS is good example.
It is saved by the fact the use is high (anyone will want to save a file or
list folders contents), but the diversity is also moderate-high (many
different attack vectors), dynamic is moderate-to-high as well (for
instance mac switched to urls around the time the FS got adopted)

As a result FS falls back to a decades old API and if you use the native
APIs you will have order of magnate better, as in
modern/professional/feature rich, file IO. This is true for all major
platforms.
Still, as said FS is fine, because of the high potential use and the fact
not anyone needs feature rich IO.

Things much, much worse for Graphics in any of three criteria and this time
around, in contrast to FS, falling back to "some basic principals" risks
making it useless outside prototyping and teaching.
Post by Nicol Bolas
Functionality not required by the core language should be standardized
Post by Hyman Rosen
separately, if people are moved to do it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/31d6c89e-cbc9-4b25-b9e2-c2f2a98bef0f%40isocpp.org.
Magnus Fromreide
2018-06-02 06:55:43 UTC
Permalink
Post by Robert Ramey
Post by Corentin
But what we need is a better way to collecting bits and pieces, not
to put the whole world in the standard to make up for insufficient tooling !
A standard way, even?
Actually this is most valuable insight.
The standard works well for the language and certain core libraries such as
those required to create a common facade for the local operating system.
But it doesn't work well when trying to design library components by
committee. These components are too complex, too large, and the environment
is too dynamic to be done within the standards process. People do create
these components outside of the standards process: Boost, CGal, Eigen and
many, many, many others. And of course there is GitHub. But these are not
standardized - so what is the problem.
The problem is that they are not standardized. That is they are
a) of uneven quality
b) often not documented
c) evolve "too fast"
d) fail to present a single widely accepted interface. That is there are
often competing, different, but similar libraries which are meant to address
the same problem.
f) developers of libraries are not sufficiently funded to invest the effort
required to address the shortcomings above.
e) including packages of different versions from differing sources creates
difficulties in management of larger applications.
Assuming the above is an accurate description of the current and past
situation, what should be done.
I think you missed one bullet:

g) evolve "too slow"

Both c) and g) can be true at the same time if there is more than one user of
the library.

/MF
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180602065543.GA5176%40noemi.bahnhof.se.
Robert Ramey
2018-06-02 18:09:46 UTC
Permalink
Post by Magnus Fromreide
Post by Robert Ramey
Post by Corentin
But what we need is a better way to collecting bits and pieces, not
to put the whole world in the standard to make up for insufficient tooling !
A standard way, even?
Actually this is most valuable insight.
The standard works well for the language and certain core libraries such as
those required to create a common facade for the local operating system.
But it doesn't work well when trying to design library components by
committee. These components are too complex, too large, and the environment
is too dynamic to be done within the standards process. People do create
these components outside of the standards process: Boost, CGal, Eigen and
many, many, many others. And of course there is GitHub. But these are not
standardized - so what is the problem.
The problem is that they are not standardized. That is they are
a) of uneven quality
b) often not documented
c) evolve "too fast"
d) fail to present a single widely accepted interface. That is there are
often competing, different, but similar libraries which are meant to address
the same problem.
f) developers of libraries are not sufficiently funded to invest the effort
required to address the shortcomings above.
e) including packages of different versions from differing sources creates
difficulties in management of larger applications.
Assuming the above is an accurate description of the current and past
situation, what should be done.
g) evolve "too slow"
Both c) and g) can be true at the same time if there is more than one user of
the library.
/MF
Right.

Some historical perspective. I got my hands on the the source code to a
C compiler in 1980 for a Z80 microprocessor. I saw the merit of the
language right away as I was working with COBOL at the time. I had a
Data General 16 bit processor - high performance machine for it's time.
I crafted a backend for the DG. It came with what would be considered
today a very primitive standard library. I only had to tweak a few
functions written in assembler (fopen, ...) and then use the same
compiler to re-compile the standard library. That was it.

Hundreds of others did the same thing. C was available on a very wide
variety of machines of various architectures.

Today, this is not possible. Aside that the language is too large and
complex, libraries are now provided by the same supplier as the compiler
itself, they end up coupled. So porting the standard library to another
architecture seems like a big job.

Soooo ... I suggest

a) separating the standard library as a separate component with it's own
committee etc. Coordination between the standard library committee and
language would be limited to cases where some new library function
requires compiler support.

b) making the "standard library" much smaller. Limit it to basic
functions such as API to interface with operating environment. Things
like mutex, file io etc.

c) leave "application" level components to the open source market place.

d) Encourage standards for library development. These are things that
everyone agrees we should be doing but almost most no one does.
Documentation, consistent naming, test suite. reviews etc.
Documentation is kind of interesting. The standard actually has a
section named "17.4 Method of Description" which basically supports
documentation similar to the original STL documents. See
http://www.rrsd.com/software_development/stl/index.htm. Interestingly,
almost no one follows or attempts to enforce these "informative"
prescription. Changing this might be considered.

e) Reconsidering the model for compensation of library authors.
Currently there is no such model. If library authors could be paid for
their work it some proportion to it's utility, it might permit us to
raise expectations for independently created "standard libraries"
There might be several ideas for the form such compensation might take:
Some sort of royalty would be great - but perhaps hard to enforce.
There might be an anual prize - The Falco prize (named after my friend
vinnie falco) of significant sum ($100,000). For the best new open
source C++ library. This would sucker in a lot of us to create better
quality libraries.

Perhaps there are other ideas. But just working harder using the
current structure and method is not going to improve things.

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/peumd9%241mt%241%40blaine.gmane.org.
Robert Ramey
2018-06-02 19:59:31 UTC
Permalink
But this isn't going to improve things either.
speculative
Dissociating the standard library from the language doesn't improve the
quality of the standard library.
speculative.
In such a system, the library lag
behind language features even more so than it currently does.
I don't believe this. Many if not most of the standard library
components appeared other places first. Most of boost, type traits,
STL, etc. Very little of the standard library was created by the
standards committee.

When the standards committee gets involved - it hobbles progress.
Ranges, Networking. Very complex components. They been available for
years, while the standards committee versions won't be available for
years to com.
That's not improving things for anyone.
What good would move support in C++11 have been if no standard library
components used it?
What good would "uniform initialization" have been
without containers using it?
What good are forwarding references and
variadic templates without `emplace` and the like? And so on.
If move support exists, only a short time will pass before library
writers take advantage of it. same for the other features.
As for "standards for library development", this idea suggests that the
ISO C++ committee has more power than it actually does. It can no more
enforce "standards for library development" than it can make Microsoft
respect that `class` and `struct` are not supposed to be syntactically
different. And without any genuine enforcement, such a "standard" is
worthless.
Of course I'm aware of this. ButI've never meant to suggest that this
be "enforced". This is why I included other mechanisms to achieve
improvements of higher standards.
People use libraries because they're useful, not because they follow
some "standard for development".
This is my point exactly. Useful libraries have no need to part of some
C++ standard library. Today we have many libraries that are widely
used and are not part of the standard. Eigen, Boost, multiple
serialization libraries, ASIO networking, CGal and many, many, many
more. Being part of the standard wouldn't make these libraries better
and not being part of the standard has not hindered their success.
Furthermore, that ignores the fact that the community has already
fractured with regard to "standards for library development". You're
/not/ going to make Qt rename all of its types to fit some other naming
convention; it isn't gonna happen.
I'm not suggesting that it happen. When I refer to "standards for
library development" I'm not referring to specifics such as naming (OK -
I said naming - I'll take that back). I'm really referring to a higher
expectation of what constitutes a quality library. I could see some
sort of document similar to the Guidelines Support Library which
provides an expectation of what quality work should look like.
The ISO committee also has no power (or money) to award prizes or such
things.
I wouldn't envision the ISO committee doing this. I'm trying to reduce
their workload. I doesn't really matter who does it.
At the end of the day, the C++ ISO committee is simply not the
organization you should be looking to with regard to fixing all of C++'s
problems.
LOL - Right. I'm suggesting that the committee shrink it's area of
responsibility to those things that only such a committee can actually do.

Expecting them to do things other than produce
language/library standards is just unreasonable.
I'm suggesting that they do less - much less. I'm expecting them to
produce language standards. I'm expecting them to retire form the
library standards business.
What C++ needs is a cross-platform build system that's easy to use
(which knocks CMake out of contention), has some way of easily
installing libraries, and possibly has a centralized repository that
anyone can register a project to use. That is not something that the ISO
C++ committee can accomplish. Some /members/ of that committee might be
able to help. But that's simply not their job.
Agreed. The committee would not be a good vehicle for such an effort -
even if it had the time
Again, it's like expecting Webster to start publishing the complete
works of Shakespeare. It's simply not their department.
So we're in agreement.

My proposal is for the committee to reduce it's scope. I'm not sure how
this came across as a proposal to increase that same scope. Sorry if my
proposal wasn't clear.

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/peusr0%24ipd%241%40blaine.gmane.org.
m***@gmail.com
2018-06-02 20:33:47 UTC
Permalink
Robert Ramey, where do you consider is the line b/w library and language
for C++, considering it takes great pride it does most of the stuff as
library?

Also, if the committee develops a library as well (or evaluates one for
standardization), isn't that a good eat-your-own-dog-food for the language
it develops?

Lastly, for C++ 20 and 23, what are the projects You think should be
dropped for good?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fcd58187-fbcd-4ea8-a99e-626dabb2292c%40isocpp.org.
Robert Ramey
2018-06-02 22:45:01 UTC
Permalink
Post by m***@gmail.com
Lastly, for C++ 20 and 23, what are the projects You think should be
dropped for good?
This paper lists most/all of the topics to be considered at the next
standards meeting. There are 43.

All those not marked with * I would consider as library proposals
outside my view of the proper scope for the committee.

Of the remaining 3, I would consider 2 within the scope of the committee.

Of course opinions can and will differ.

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pev6ha%24ugl%241%40blaine.gmane.org.
Nicol Bolas
2018-06-02 21:07:25 UTC
Permalink
Post by Robert Ramey
But this isn't going to improve things either.
speculative
No moreso than yours. I back my speculation up with a detailed explanation
of why it won't help.
Post by Robert Ramey
Dissociating the standard library from the language doesn't improve the
quality of the standard library.
speculative.
In such a system, the library lag
behind language features even more so than it currently does.
I don't believe this. Many if not most of the standard library
components appeared other places first. Most of boost, type traits,
STL, etc. Very little of the standard library was created by the
standards committee.
What does that have to do with anything I was talking about?

STL's `vector` type didn't have move support because move support *didn't
exist* when STL was created. It didn't have `emplace` because forwarding
references and variadic templates *didn't exist* back then. And so forth.

That is the kind of lagging behind I'm talking about. C++11 brought about
those language features, and C++11 simultaneously added those features to
the standard library components that could use them. That's good.

Separating the language from the library will make it difficult for that to
happen. That's bad.
Post by Robert Ramey
When the standards committee gets involved - it hobbles progress.
Ranges, Networking. Very complex components. They been available for
years, while the standards committee versions won't be available for
years to com.
You can use that argument for pretty much any big feature, language or
library. I mean, before C++11 came out, GCC has a nearly-complete
implementation of the large Concepts proposal. But the committee decided
not to move forward with it, so progress was hobbled for a good 7 years or
so.

The same goes for many other things C++ features. If we just let compilers
independently create their own separate language features, then C++ would
advance much more quickly.

And it would advance in incompatible ways. Standardization of the language
creates standardization of implementations. The same is true of the
standard library.

Now, you might say that that's not a valid comparison. After all, you can
just download and use a library, while switching compilers is hard. And you
can't use one compiler for some code and another for others, while you can
download two libraries that don't know about each other.

But that's only true if the library doesn't depend on the platform. When it
does (as many useful libraries do), well, now you're at the mercy of the
maker of the library to ensure that it works on your platforms of interest.

A problem with dropping things from the standard is that it creates a lack
of interoperability. Take the entire STL iterator mechanism. I can write
new algorithms that work within the iterator model, and someone else can
write new containers that provide iterators within that model. Because
we're both coding against the same standard model, their containers can
work with my algorithms. That's good.

Take `optional<T>`. Because it's available to everyone, it becomes a lingua
franca type that everyone can use. You can stick it in an interface and not
feel like you're making someone else use something they'd rather not use.
Something similar can be said for `string_view`. That's good too.

Having standard solutions to certain library problems is useful and
important. And that cannot be achieved by using arbitrary external
libraries.

Take the STL iterator model. It is baked into the language, thanks to
range-based `for`. You couldn't do that with a library external model. And
you might have multiple competing iterator models. Some might look like STL
iterators, some might look like Java's "iterator", etc. And they'd be
incompatible.

And while one model might be better in some situations than another, the
fact is picking *some answer* is better than "let the community sort it
out". Because the C++ community has proven that they are really terrible at
that.
Post by Robert Ramey
That's not improving things for anyone.
What good would move support in C++11 have been if no standard library
components used it?
What good would "uniform initialization" have been
without containers using it?
What good are forwarding references and
variadic templates without `emplace` and the like? And so on.
If move support exists, only a short time will pass before library
writers take advantage of it. same for the other features.
Maybe. Maybe not.

Tell me: how long did it take `boost::shared_ptr` to get move support? What
about `boost::optional`? Or `boost::any`? And those are the ones I know off
the top of my head. Even now in 2017, is move support ubiquitous throughout
Boost? Even in the libraries that aren't well maintained?

Boost has `boost::string_view`. Are there alternate versions of APIs that
take `boost::string_view` that take C++17 `std::string_view` too? When will
those appear?

And what about when a language feature strongly encourages a library
redesign? Consider `boost::variant`. Move support is a game changer for
`variant` assignment, as it reduces the circumstances when a `variant`
might need to allocate memory to avoid thrown exceptions. At that point,
the decision to allow memory allocation *at all* starts becoming
questionable.

So no, it takes more than "a short time" for such changes to appear.
Post by Robert Ramey
As for "standards for library development", this idea suggests that the
ISO C++ committee has more power than it actually does. It can no more
enforce "standards for library development" than it can make Microsoft
respect that `class` and `struct` are not supposed to be syntactically
different. And without any genuine enforcement, such a "standard" is
worthless.
Of course I'm aware of this. ButI've never meant to suggest that this
be "enforced". This is why I included other mechanisms to achieve
improvements of higher standards.
People use libraries because they're useful, not because they follow
some "standard for development".
This is my point exactly. Useful libraries have no need to part of some
C++ standard library. Today we have many libraries that are widely
used and are not part of the standard. Eigen, Boost, multiple
serialization libraries, ASIO networking, CGal and many, many, many
more. Being part of the standard wouldn't make these libraries better
and not being part of the standard has not hindered their success.
Being part of the standard would make them *part of the standard* and thus
reliable for all C++ users. That matters in part because of the difficulty
of just using someone else's library, but also because of interoperability.

Let's say there is some library A. And it has a signal callback mechanism,
which takes functions that take an `A::any` type as parameters. Now, let's
say that there is some library B, which has functions you'd like to use
with A's signaling mechanism. The problem is that B's API takes `B::any`,
which is a distinct type.

And since we're talking about an "any" type, you can't create some kind of
one-size-fits-all glue between the two. Your glue code has to know what
type the signaled function expects, so that it can cross the two.

This is a problem only because A and B implemented two types that do the
same thing. If they'd just used `std::any`, this wouldn't be a problem. But
if you had your way, there would be no `std::any`, so you'd have two
Balkanized libraries that only work with themselves and code written
specifically against them.

The thing is, we both agree that there are domains the committee should not
be exploring. It's simply a matter of where that line gets drawn. To you,
that line should be "OS features" and that's it. To me, my concern is
primarily about having platform neutrality and general code inter-operation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a78b9ce4-bc39-4ae5-bac5-76b789ca95a2%40isocpp.org.
Robert Ramey
2018-06-02 23:46:10 UTC
Permalink
In such a system, the library lag
behind language features even more so than it currently does.
I don't believe this.  Many if not most of the standard library
components appeared other places first.  Most of boost, type traits,
STL, etc.  Very little of the standard library was created by the
standards committee.
What does that have to do with anything I was talking about?
You suggested that library lags behind language features. I don't this
is very true. In fact, I'm of the believe that library components come
first and motivate enhancements to the language itself. For example,
functions objects where found to be very useful but syntactically
cumbersome. This motivated addition of lambdas to the language.
STL's `vector` type didn't have move support because move support
/didn't exist/ when STL was created. It didn't have `emplace` because
forwarding references and variadic templates /didn't exist/ back then.
And so forth.
Right. It was only apparent that these facilities were useful when
these libraries were fairly widely used. The language standard follows
code and practice. For the committee to be spending too much time trying
to speculatively anticipate the future is not an effective usage of
resources.
That is the kind of lagging behind I'm talking about. C++11 brought
about those language features, and C++11 simultaneously added those
features to the standard library components that could use them. That's
good.
Those features are/were added to all libraries and user code - not just
those designed by the committee.
Separating the language from the library will make it difficult for that
to happen. That's bad.
No it won't
When the standards committee gets involved - it hobbles progress.
Ranges, Networking.  Very complex components. They been available for
years, while the standards committee versions won't be available for
years to com.
You can use that argument for pretty much any big feature, language or
library.
LOL - of course I can, and I do - because it's a good argument.
I mean, before C++11 came out, GCC has a nearly-complete
implementation of the large Concepts proposal. But the committee decided
not to move forward with it, so progress was hobbled for a good 7 years
or so.
Great example.

As you point out, the idea of concepts is an example where design by
committee has worked out well.

Most if not all the benefits of the future concepts implementation can
and have been implemented as libraries. The Boost Concept Library
(2004) was somewhat crude but effective. The Tick library ( proposed to
boost but not accepted) includes a quite complete and effective
implementation based on C++11. But neither of these libraries are widely
used in spite of a large amount of evangelism at conferences. Of the
very few libraries which actually have documentation, only a few
actually use concepts in their designs - much less enforce them in their
code. In spite of all this, the C++ community has spent huge amounts of
effort promoting and designing this feature as part of the language.

Much better would have be to just let libraries implementing concepts
develop. If they become successful and it becomes apparent that a
change in the language would make them better, the the language can be
enhanced to better support them. This is similar to your example for
vector where vector was invented, found wide usage, and motivate some
enhancements in the language (move).
The same goes for many other things C++ features. If we just let
compilers independently create their own separate language features,
then C++ would advance much more quickly.
I have not proposed this.

but compiler vendors have proposed their own incompatible
features/extensions. The committee cannot and does not prohibit this.
And it would advance in incompatible ways. Standardization of the
language creates standardization of implementations. The same is true of
the standard library.
under my proposal the standard library would be smaller. But all
implementations would be compatible.
But that's only true if the library doesn't depend on the platform.
I've proposed limiting library standardization to those things which are
platform dependent such as i/o (fopen, etc.) to facility the writing of
portable code.
A problem with dropping things from the standard is that it creates a
lack of interoperability. Take the entire STL iterator mechanism. I can
write new algorithms that work within the iterator model, and someone
else can write new containers that provide iterators within that model.
Because we're both coding against the same standard model, their
containers can work with my algorithms. That's good.
Right. In my world standard components would still exist. Someone
would make them and they would become "effectively" standard in that
many people come to depend upon them. ASIO, Eigan are good examples. So
"standard components" will always exist. But this doesn't mean that the
ISO C++ standards committee has to be responsible for designing all of
them. I argue that it doesn't have to spend time on this, that it's not
a good use of their time, and it doesn't result in the most effective
designs.
Take `optional<T>`. Because it's available to everyone, it becomes a
lingua franca type that everyone can use. You can stick it in an
interface and not feel like you're making someone else use something
they'd rather not use. Something similar can be said for `string_view`.
That's good too.
Boost::Optional has existed for many years and has wide use. Spending
c++ committee resources to (re)design it added nothing to C++.
Having standard solutions to certain library problems is useful and
important.
I don't think it's necessary

And that cannot be achieved by using arbitrary external libraries.

The trickiest functions: networking, linear algebra, gui, serialization,
are all currently handled by non-iso libraries. I don't see the value
of the C++ committee trying to contribute to that.
Take the STL iterator model. It is baked into the language,
it's baked into the STL library
thanks to range-based `for`.
Hmmm I'm not seeing that. But maybe you're right. Before I had
range-based 'for', I used BOOST_FOREACH for the same effect. I'm not
totally convinced that it had to "baked into the language". If so, it
raises questions about the design of the feature.
You couldn't do that with a library external model.
And you might have multiple competing iterator models. Some might look
like STL iterators, some might look like Java's "iterator", etc. And
they'd be incompatible.
Could be. But I doubt it. The most successful libraries become dominant
and tend to drive out alternatives... Until some compelling better
alternative comes along. This is a general principle which shows in
evolution, capitalism, art, politics and other fields which are not
overly centralized.
And while one model might be better in some situations than another, the
fact is picking /some answer/ is better than "let the community sort it
out". Because the C++ community has proven that they are really terrible
at that.
Hmmm - Did you write that or did I. I don't remember.
If move support exists, only a short time will pass before library
writers take advantage of it. same for the other features.
Maybe. Maybe not.
Tell me: how long did it take `boost::shared_ptr` to get move support?
What about `boost::optional`? Or `boost::any`? And those are the ones I
know off the top of my head. Even now in 2017, is move support
ubiquitous throughout Boost? Even in the libraries that aren't well
maintained?
To be honest I don't know. I certainly haven't heard anyone complain.
But the real answer is that if there exist superior components to the
boost ones, the boost ones will be driven out when that becomes apparent.
And what about when a language feature strongly encourages a library
redesign? Consider `boost::variant`. Move support is a game changer for
`variant` assignment, as it reduces the circumstances when a `variant`
might need to allocate memory to avoid thrown exceptions. At that point,
the decision to allow memory allocation /at all/ starts becoming
questionable.
another interesting example. I know there has been a lot of dispute
about the various ways variant can / should be implemented. This is
chiefly due to the implementation of the assign operation in the
presence of multi-threading, exceptions, etc. I'm guessing that
different situations will call for different implementations and type
requirements. So trying to standardize this so that everyone or most
people are satisfied is not great idea. (FWIW - I suggested just
deleting the assignment as it works well for my use cases - Response was
underwhelming)
So no, it takes more than "a short time" for such changes to appear.
As for "standards for library development", this idea suggests
that the
ISO C++ committee has more power than it actually does. It can no
more
enforce "standards for library development" than it can make
Microsoft
respect that `class` and `struct` are not supposed to be
syntactically
different. And without any genuine enforcement, such a "standard" is
worthless.
Of course I'm aware of this.  ButI've never meant to suggest that this
be "enforced".  This is why I included other mechanisms to achieve
improvements of higher standards.
People use libraries because they're useful, not because they follow
some "standard for development".
This is my point exactly.  Useful libraries have no need to part of
some
C++ standard library.   Today we have many libraries that are widely
used and are not part of the standard.  Eigen, Boost, multiple
serialization libraries, ASIO networking, CGal and many, many, many
more.  Being part of the standard wouldn't make these libraries better
and not being part of the standard has not hindered their success.
Being part of the standard would make them /part of the standard/ and
thus reliable for all C++ users.
"standardization" and reliability are separate issues.
That matters in part because of the
difficulty of just using someone else's library,
"standard libraries" are not guarenteed to be easy to use. and many are not.

but also because of
interoperability.
I'm not sure what interoperability means in this context. I doubt it's
relevent anyway.
This is a problem only because A and B implemented two types that do the
same thing. If they'd just used `std::any`, this wouldn't be a problem.
But if you had your way, there would be no `std::any`, so you'd have two
Balkanized libraries that only work with themselves and code written
specifically against them.
Right. This is the essence of the argument for the current system. I
don't dispute that the argument has merit. But I don't think that this
is the only consideration. The current system also has a lot of
problems which are widely noted. Something is going to have to change.
My view is that the only thing that will make a difference will be to
narrow the scope of what the committee has to deal with. I think a lot
of people would agree with this. At least until it has to be decide
what should be eliminated from that scope.
The thing is, we both agree that there are domains the committee should
not be exploring. It's simply a matter of where that line gets drawn. To
you, that line should be "OS features" and that's it. To me, my concern
is primarily about having platform neutrality and general code
inter-operation.
Hmmm ... I don't see much difference between what I mean when I say OS
features and you say "platform neutrality".

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/peva40%242lh%241%40blaine.gmane.org.
Richard Hodges
2018-06-07 08:26:36 UTC
Permalink
The 3 major platforms (Windows, OS X, Linux) do not even agree on a
particular API.
Actually they do. If you want to write portable 3D graphics you use
OpenGL and not Direct3d.
With the recent news from Apple that is clearly not the case. More and
more software is moving to the newer, and fragmented, rendering APIs. So I
think saying they do not agree on a particular rendering API is a
reasonably accurate statement.
I'm not saying you're wrong. Have I been misled by this?
"OpenGL is the foundation for hardware-accelerated graphics in macOS."
source: https://developer.apple.com/opengl/
From <https://developer.apple.com/macos/whats-new/>
"Apps built using OpenGL and OpenCL will continue to run in macOS 10.14,
but these legacy technologies are deprecated in macOS 10.14. Games and
graphics-intensive apps that use OpenGL should now adopt Metal. Similarly,
apps that use OpenCL for computational tasks should now adopt Metal and
Metal Performance Shaders."
Ah I see. It's a swift/obj-c wrapper around opengl and opencl.

All the more reason for an international c++ standard for 3d graphics IMHO
(even if separate or an optional appendix to the isocpp standard). Now we
have *yet another* half-baked unilateral attempt to prevent developers from
writing portable applications.

A pox on these software giants.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Gh%3DNv9%2Bo01%2BauyjB2rrHuxAqdipZH-HiN9-yKKqRP6LcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haLuG6PsQ4dCzXzMmxstaxsBEqHzwXXsczCxj9BCYfxag%40mail.gmail.com.
Dejan Milosavljevic
2018-06-01 14:38:47 UTC
Permalink
Take look at next thread:

https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8TpSRdhSAQAJ

Everything what apply to GUI is same for Graphics.
Post by Richard Hodges
Post by Richard Hodges
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
I think most people would agree with that observation.
But what we need is a better way to collecting bits and pieces, not to put
the whole world in the standard to make up for insufficient tooling !
Post by Richard Hodges
Post by m***@gmail.com
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
In my view this is a shame.
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both*
hardware, algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms
or implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the
community) will waste time considering, probably without even having the
expertise for that!
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-
bf6e-28f20a7faccb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61A
WBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%
3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com.
Richard Hodges
2018-06-01 14:52:12 UTC
Permalink
Post by Dejan Milosavljevic
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/8TpSRdhSAQAJ
Everything what apply to GUI is same for Graphics.
And yet OpenGL is a (very successful) standard thing...
Post by Dejan Milosavljevic
Post by Richard Hodges
Post by Richard Hodges
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
I think most people would agree with that observation.
But what we need is a better way to collecting bits and pieces, not to
put the whole world in the standard to make up for insufficient tooling !
Post by Richard Hodges
Post by m***@gmail.com
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
While I agree that a Noddy-style 2d line-drawing library is of no use to
anyone, I strongly feel that there should be a standardised 3d graphics,
sound and human interface library, and damn the difficulties. I'm not
arguing that every compiler vendor ships a fully functioning library, but
if they do there should be a standard so that vendors can report levels of
compliance.
At the moment, collecting together all the bits and pieces to build a
cross-platform graphics engine is just too much work. In the end you give
up the will to continue and switch to an inferior language with better
support.
In my view this is a shame.
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both*
hardware, algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms
or implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the
community) will waste time considering, probably without even having the
expertise for that!
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7915a73c-e305-4bce-bf6e-28f20a7faccb%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ0Ouf4OgeeaeVjYvVP3n61AWBn3f6%3DH2-3A2hMPxGzVg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjxfeHSdw%3DDPJGFBJFJtH1NgQ19tH%3DWY5KqKCKkzs-fPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmz9U8RXHkOD2U06vbAoQZJFa7kgg_yc56Z2GxHep-MmCQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3ha9NLb6AS%2BwcZ4oiKBK3LhSfROk%2BK%2BTEucmLckY9Q-JVA%40mail.gmail.com.
Rene Rivera
2018-06-01 14:58:50 UTC
Permalink
Post by Richard Hodges
Post by Dejan Milosavljevic
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/
8TpSRdhSAQAJ
Everything what apply to GUI is same for Graphics.
And yet OpenGL is a (very successful) standard thing...
With at least three competing "standards". So I guess it's not so standard.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GghBeFQGCv2WqWct1bkfC_F8NrGTGxxAif4DBsvo%3DRqFw%40mail.gmail.com.
Rene Rivera
2018-06-01 14:57:33 UTC
Permalink
Post by Dejan Milosavljevic
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/aEdZvQS1Soc/
8TpSRdhSAQAJ
Everything what apply to GUI is same for Graphics.
Correct.. And the same conclusion applies.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_GikxSi-H7Y1oX8fOz%2Bq2iHuDxT2S4FVBsQvTUO3HEDtuw%40mail.gmail.com.
y***@gmail.com
2018-08-12 01:19:48 UTC
Permalink
hello.

i think anti paper is hateful.
thay look down the game programmer.
game programmer is make economy.
but as i think the 2d paper is too big.
they refer to bad model as GDI+.
i think the paper is near the GDI+.
who want to service the brush,path,matrix.
i need two and one.
Window IO.Surface Spec. and Parameter defines.
other is make by self and others.
why force the full carry at first time by like ms.

why need Surface? it is for doublebuffering and imaging.
imaging is the factory method create to surface.
the surface dispatch to display to done.
if surface spec is nothing. to self refresh the window.
it is very slow in now age.

why not font?
the system defined font system is greater soluton.
but it is finaly pixel.not need Spec on standard.i know it is useful.

last.
i need 2d graphics for my task.
but they drop thinking point.
need more discussion.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3217c680-4cf2-4098-8512-dde3347bef79%40isocpp.org.
Rene Rivera
2018-08-12 02:20:11 UTC
Permalink
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression of the
paper being hateful to anyone, especially game programmers. In the contrary
it seems to go out of it's way to take into consideration the concerns of
game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com.
Richard Hodges
2018-08-12 09:46:07 UTC
Permalink
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression of
the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.

Of course the obvious answer is "yes". There are many fantastic graphics
libraries...

...and after spending 2 weeks of one's life trying to get them to compile
and run on all the platforms you want to support (because we all want to
write cross-platform software, right?) most of us lose the will to live and
go back to our horrible but reliable jobs not programming games.

Standardising platform I/O - including graphics, consoles, keyboards, mice
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.

The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).

In terms of lost man-hours alone, there is no possible argument that can be
made against standardisation of tools and libraries.
Post by Rene Rivera
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHEh_Giw77e%3Daz_dr0N%2BfySwyXyb00CroNU_O%3DuCFfztksbNSA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haAgHkWMb3Y-St-VN%2BDzsp6dUP61WHSs7extgG7RJ5qAQ%40mail.gmail.com.
Nicol Bolas
2018-08-12 14:59:06 UTC
Permalink
Post by Richard Hodges
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression of
the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic graphics
libraries...
...and after spending 2 weeks of one's life trying to get them to compile
and run on all the platforms you want to support (because we all want to
write cross-platform software, right?) most of us lose the will to live and
go back to our horrible but reliable jobs not programming games.
So the problem has nothing to do with its appropriateness for the standard
library. It's the fact that C++ has a terrible build/package environment.
If you could download and use other libraries more easily, then you
wouldn't need it to be in the standard library at all. We should not adopt
standard library components primarily because C++ has a terrible
build/package environment.

Also, we are used to standard libraries being fast, high-performance tools.
Containers, algorithms, these are usually well-optimized stuff in standard
library implementations. So people tend to instinctively assume that the
standard library's implementation of the graphics proposal would be equally
high quality.

So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.

But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite having
virtually identical interfaces to `std::regex`. Here, there's no question;
this is pure QoI, and the standard libraries aren't providing it. Despite
having had a over decade to do so (regex was part of TR1, after all).

What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name users
of C++ platforms aren't interested in using these high level tools. If you
have a big C++ project and you needed regular expressions, you use some
library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.

2D graphics would be in an even worse position. There are plenty of
applications that just don't care about graphics or are perfectly happy
with their existing solutions. They are not going to start using this
unknown standard library component. And if they don't start using it,
implementers will not start optimizing it.

It's a vicious cycle.

So in the end, what you would have is an easy-to-install but terribly
performing tool. If you want to make little toy or learning applications,
it's fine. You can make Tetris or Pac-Man with that (though both of those
require text rendering, which the graphics TS did not have). But you would
not be able to use it to make any kind of 2D game where performance
actually matters. So if you're serious about making a 2D game, you will
eventually have to go do the work to install that library.

So who exactly would be helped by adding a standard library component that
pretends to offer a solution, but if you're actually serious about that
domain, you'll have to ditch for something real? Again, iostreams offers
the perfect example of this sort of thing. You don't tend to see it get
used in high-performance applications (which is ultimately what C++ is
for), and you can't really blame people for that.

Why do we need to spend a huge amount of time to standardize the new
terrible standard library component that nobody uses? Best to nip it in the
bud before spending that time.

Standardising platform I/O - including graphics, consoles, keyboards, mice
Post by Richard Hodges
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that can
be made against standardisation of tools and libraries.
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.

Performance graphics is a specialty field. As such, there's going to be a
significant quality difference from a graphics library written by people
who spend most of their time optimizing the usual C++ code and a graphics
library written by people who actually know graphics.

Sure, more people will be investing more time in competing 2D graphics
libraries overall. But the quality of those libraries will be better.
They're written by people who (presumably) know what they're doing. And if
they aren't, then they will be out-competed by those who do.

In a perfect world, maybe the standard library vendors would produce work
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%40isocpp.org.
Richard Hodges
2018-08-12 16:40:23 UTC
Permalink
Post by Nicol Bolas
Post by Richard Hodges
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression of
the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic graphics
libraries...
...and after spending 2 weeks of one's life trying to get them to compile
and run on all the platforms you want to support (because we all want to
write cross-platform software, right?) most of us lose the will to live and
go back to our horrible but reliable jobs not programming games.
So the problem has nothing to do with its appropriateness for the standard
library. It's the fact that C++ has a terrible build/package environment.
If you could download and use other libraries more easily, then you
wouldn't need it to be in the standard library at all. We should not adopt
standard library components primarily because C++ has a terrible
build/package environment.
Also, we are used to standard libraries being fast, high-performance
tools. Containers, algorithms, these are usually well-optimized stuff in
standard library implementations. So people tend to instinctively assume
that the standard library's implementation of the graphics proposal would
be equally high quality.
So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.
But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite having
virtually identical interfaces to `std::regex`. Here, there's no question;
this is pure QoI, and the standard libraries aren't providing it. Despite
having had a over decade to do so (regex was part of TR1, after all).
What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name users
of C++ platforms aren't interested in using these high level tools. If you
have a big C++ project and you needed regular expressions, you use some
library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.
HTTP and HTML are standards. Vendors fought a vicious war over 20 years to
ensure that they had the "best" implementations. The result is an extremely
functional internet. Standards are only good.
Post by Nicol Bolas
2D graphics would be in an even worse position. There are plenty of
applications that just don't care about graphics or are perfectly happy
with their existing solutions. They are not going to start using this
unknown standard library component. And if they don't start using it,
implementers will not start optimizing it.
It's a vicious cycle.
So in the end, what you would have is an easy-to-install but terribly
performing tool. If you want to make little toy or learning applications,
it's fine. You can make Tetris or Pac-Man with that (though both of those
require text rendering, which the graphics TS did not have). But you would
not be able to use it to make any kind of 2D game where performance
actually matters. So if you're serious about making a 2D game, you will
eventually have to go do the work to install that library.
So who exactly would be helped by adding a standard library component that
pretends to offer a solution, but if you're actually serious about that
domain, you'll have to ditch for something real? Again, iostreams offers
the perfect example of this sort of thing. You don't tend to see it get
used in high-performance applications (which is ultimately what C++ is
for), and you can't really blame people for that.
Why do we need to spend a huge amount of time to standardize the new
terrible standard library component that nobody uses? Best to nip it in the
bud before spending that time.
Standardising platform I/O - including graphics, consoles, keyboards, mice
Post by Richard Hodges
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that can
be made against standardisation of tools and libraries.
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.
N is the number of teams who need to use a graphics library. At the moment,
every single one must figure out how to select, compile, patch, bugfix
(because, you know, open source) and figure out why a given library works
on one platform and not another. This is an utter waste of time.

I agree that packaging is a massive problem for c++, indeed its biggest
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over. In my view there is no
excuse for things refusing to "just work".
Post by Nicol Bolas
Performance graphics is a specialty field. As such, there's going to be a
significant quality difference from a graphics library written by people
who spend most of their time optimizing the usual C++ code and a graphics
library written by people who actually know graphics.
Sure, more people will be investing more time in competing 2D graphics
libraries overall. But the quality of those libraries will be better.
They're written by people who (presumably) know what they're doing. And if
they aren't, then they will be out-competed by those who do.
If these competing libraries are mandated to support a standard interface,
selection and retrofitting becomes a non-issue. You simply test and choose
the most suitable conforming implementation. In this case, standards do
nothing but good. Standards are why computers and operating systems can
talk to each other regardless of the machiavellian natures of their
manufacturers.
Post by Nicol Bolas
In a perfect world, maybe the standard library vendors would produce work
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
I say we should focus on building the perfect world. And we should build in
ways to allow good vendors to profit from excellence.
Post by Nicol Bolas
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0b57f4a-3e3d-4ddd-8511-ef9334ebd76f%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb1y9hhMLBFpPZ0%3DgJ_zzU0qJMzsktB146ASOthYxwb5A%40mail.gmail.com.
Nicol Bolas
2018-08-12 23:07:18 UTC
Permalink
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression of
the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic graphics
libraries...
...and after spending 2 weeks of one's life trying to get them to
compile and run on all the platforms you want to support (because we all
want to write cross-platform software, right?) most of us lose the will to
live and go back to our horrible but reliable jobs not programming games.
So the problem has nothing to do with its appropriateness for the
standard library. It's the fact that C++ has a terrible build/package
environment. If you could download and use other libraries more easily,
then you wouldn't need it to be in the standard library at all. We should
not adopt standard library components primarily because C++ has a terrible
build/package environment.
Also, we are used to standard libraries being fast, high-performance
tools. Containers, algorithms, these are usually well-optimized stuff in
standard library implementations. So people tend to instinctively assume
that the standard library's implementation of the graphics proposal would
be equally high quality.
So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.
But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite
having virtually identical interfaces to `std::regex`. Here, there's no
question; this is pure QoI, and the standard libraries aren't providing it.
Despite having had a over decade to do so (regex was part of TR1, after
all).
What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name
users of C++ platforms aren't interested in using these high level tools.
If you have a big C++ project and you needed regular expressions, you use
some library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.
HTTP and HTML are standards. Vendors fought a vicious war over 20 years to
ensure that they had the "best" implementations. The result is an extremely
functional internet. Standards are only good.
This "extremely functional internet" is based on people spending an
inordinate amount of time compensating for blatantly non-conformant,
sometimes horribly inefficient, and possibly flat-out *broken*
implementations of these standards, such that developers have to
*constantly* test every webpage on a myriad of versions of a myriad of
browsers just to make sure they actually work. The "extremely functional
internet" is very much not write once, run anywhere.

Standards are only good when *followed*. When followed and
well-implemented. How is having regex in the C++ standard good if nobody
uses it because of how terrible implementations are? The time spent
implementing it, however badly, is wasted. The time spent standardizing it
is wasted. The time spent updating that part of the standard, keeping it in
sync with the rest, is wasted.

How is this a good, productive use of peoples' time?

Nobody is going to ditch a standard library implementation over regex;
they'll just download and use a different regex library. This is because
changing standard library implementations is often a lot harder than
installing a normal library. Also, it ensures that you get what you want
rather than playing pot-luck with whatever implementations give you.

Standards are not "only good"; they fail. They fail all the time. You just
don't hear about the failures because... they failed; people don't tend to
talk about failures unless they are spectacular. Standards which go
unimplemented or unused have failed.

IOstreams is mostly a failure. Regex in C++ failed. We don't need more
failures in C++; certainly not 100+ pages of them.

Standardising platform I/O - including graphics, consoles, keyboards, mice
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that can
be made against standardisation of tools and libraries.
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.
N is the number of teams who need to use a graphics library. At the
moment, every single one must figure out how to select, compile, patch,
bugfix (because, you know, open source) and figure out why a given library
works on one platform and not another. This is an utter waste of time.
How would this change by making it part of the standard library? Oh yes,
you don't need to compile or install the standard library. But the standard
library is hardly immune to bugs. And standard library bugs are usually
harder to get rid of precisely *because* you didn't compile/install it. You
have to go get its source code (if available) and then build from that. And
to preserve your patches, you now need to effectively fork and frequently
remerge from the main standard library line.

This is an O(N) problem; this time will be "wasted" either way.

I agree that packaging is a massive problem for c++, indeed its biggest
Post by Richard Hodges
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over.
Remember: the reason C++ got into this mess to begin with was that everyone
decided to write their own build systems. Everyone decided that they had
their own needs and wrote incompatible build systems.

So the last thing C++ needs is 10 different package management systems on
top of its numerous build systems.

There are already several similar projects underway with this goal in mind.
Instead of making your own, pick the one you like the best. Even if you
don't like it *at all*, just being better than the rest is enough. Spend
your time helping it improve faster and making it better.

C++ wins if we get *one* package management system. C++ loses if we get 10
incompatible ones.

In a perfect world, maybe the standard library vendors would produce work
Post by Richard Hodges
Post by Nicol Bolas
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
I say we should focus on building the perfect world.
At what cost? The saying "the perfect is the enemy of the good" is often an
overused platitude, but it is very apt in this case.

The C++ standards committee only has finite amounts of time. LEWG is
already overloaded; at the last meeting, they only reviewed *half* of the
papers submitted for the standard library. And there, 2D graphics was
talked about only for a single evening. A proper review of the 2D graphics
TS would have absorbed a great deal of LWG's time
<https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
leaving even more things undone.

What should be sacrificed for 2D graphics? `span`? Low-level filesystems
work? Text formatting? Executors? Networking? Library support for
`constexpr` heap allocations? What should be sacrificed on this altar?

How many other things in C++ is this "perfect world" worth?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%40isocpp.org.
Richard Hodges
2018-08-13 06:51:22 UTC
Permalink
Post by Nicol Bolas
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression
of the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic
graphics libraries...
...and after spending 2 weeks of one's life trying to get them to
compile and run on all the platforms you want to support (because we all
want to write cross-platform software, right?) most of us lose the will to
live and go back to our horrible but reliable jobs not programming games.
So the problem has nothing to do with its appropriateness for the
standard library. It's the fact that C++ has a terrible build/package
environment. If you could download and use other libraries more easily,
then you wouldn't need it to be in the standard library at all. We should
not adopt standard library components primarily because C++ has a terrible
build/package environment.
Also, we are used to standard libraries being fast, high-performance
tools. Containers, algorithms, these are usually well-optimized stuff in
standard library implementations. So people tend to instinctively assume
that the standard library's implementation of the graphics proposal would
be equally high quality.
So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.
But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite
having virtually identical interfaces to `std::regex`. Here, there's no
question; this is pure QoI, and the standard libraries aren't providing it.
Despite having had a over decade to do so (regex was part of TR1, after
all).
What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name
users of C++ platforms aren't interested in using these high level tools.
If you have a big C++ project and you needed regular expressions, you use
some library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.
HTTP and HTML are standards. Vendors fought a vicious war over 20 years
to ensure that they had the "best" implementations. The result is an
extremely functional internet. Standards are only good.
This "extremely functional internet" is based on people spending an
inordinate amount of time compensating for blatantly non-conformant,
sometimes horribly inefficient, and possibly flat-out *broken*
implementations of these standards, such that developers have to
*constantly* test every webpage on a myriad of versions of a myriad of
browsers just to make sure they actually work. The "extremely functional
internet" is very much not write once, run anywhere.
Standards are only good when *followed*. When followed and
well-implemented. How is having regex in the C++ standard good if nobody
uses it because of how terrible implementations are? The time spent
implementing it, however badly, is wasted. The time spent standardizing it
is wasted. The time spent updating that part of the standard, keeping it in
sync with the rest, is wasted.
How is this a good, productive use of peoples' time?
Nobody is going to ditch a standard library implementation over regex;
they'll just download and use a different regex library. This is because
changing standard library implementations is often a lot harder than
installing a normal library. Also, it ensures that you get what you want
rather than playing pot-luck with whatever implementations give you.
Standards are not "only good"; they fail. They fail all the time. You just
don't hear about the failures because... they failed; people don't tend to
talk about failures unless they are spectacular. Standards which go
unimplemented or unused have failed.
IOstreams is mostly a failure. Regex in C++ failed. We don't need more
failures in C++; certainly not 100+ pages of them.
Standardising platform I/O - including graphics, consoles, keyboards, mice
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that
can be made against standardisation of tools and libraries.
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.
N is the number of teams who need to use a graphics library. At the
moment, every single one must figure out how to select, compile, patch,
bugfix (because, you know, open source) and figure out why a given library
works on one platform and not another. This is an utter waste of time.
How would this change by making it part of the standard library? Oh yes,
you don't need to compile or install the standard library. But the standard
library is hardly immune to bugs. And standard library bugs are usually
harder to get rid of precisely *because* you didn't compile/install it.
You have to go get its source code (if available) and then build from that.
And to preserve your patches, you now need to effectively fork and
frequently remerge from the main standard library line.
This is an O(N) problem; this time will be "wasted" either way.
I agree that packaging is a massive problem for c++, indeed its biggest
Post by Richard Hodges
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over.
Remember: the reason C++ got into this mess to begin with was that
everyone decided to write their own build systems. Everyone decided that
they had their own needs and wrote incompatible build systems.
So the last thing C++ needs is 10 different package management systems on
top of its numerous build systems.
There are already several similar projects underway with this goal in
mind. Instead of making your own, pick the one you like the best. Even if
you don't like it *at all*, just being better than the rest is enough.
Spend your time helping it improve faster and making it better.
C++ wins if we get *one* package management system. C++ loses if we get
10 incompatible ones.
I agree here. I have yet to find one that actually works. There needs to be
one, which appeals to everyone. Which means it must do everything, with
utter simplicity, for all target platforms. It must also appeal to
commercial software-producing firms so that the commercial licence can fund
its maintenance and development.
Post by Nicol Bolas
In a perfect world, maybe the standard library vendors would produce work
Post by Richard Hodges
Post by Nicol Bolas
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
I say we should focus on building the perfect world.
At what cost? The saying "the perfect is the enemy of the good" is often
an overused platitude, but it is very apt in this case.
The C++ standards committee only has finite amounts of time. LEWG is
already overloaded; at the last meeting, they only reviewed *half* of the
papers submitted for the standard library. And there, 2D graphics was
talked about only for a single evening. A proper review of the 2D graphics
TS would have absorbed a great deal of LWG's time
<https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
leaving even more things undone.
What should be sacrificed for 2D graphics? `span`? Low-level filesystems
work? Text formatting? Executors? Networking? Library support for
`constexpr` heap allocations? What should be sacrificed on this altar?
How many other things in C++ is this "perfect world" worth?
The committee is clearly a bottleneck, I do agree. What could be done to
widen it?
--
Post by Nicol Bolas
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/152720b0-b5f2-48e1-ab3e-e1c33fb6b39d%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZAPyyjoT%3D2WH1ceK_bhB7HEmVC5A_f36JPAd4M-gfi%3Dg%40mail.gmail.com.
Hyman Rosen
2018-08-13 07:13:31 UTC
Permalink
Post by Richard Hodges
The committee is clearly a bottleneck, I do agree. What could be done to
widen it?
Libraries don't belong in language standards. If, during library design,
someone thinks that a language change would be helpful, then they can write
a proposal just for that.

People are being misled by history. STL and iostreams were the new shiny
and a great way to show off what C++ could do, and C had a library, so
everyone thought that a C++ standard ought to have one too. That was
wrong, and doesn't need to be compounded with filesystems, regular
expressions, Bessel functions, networking, or graphics. Special interest
groups with subject-matter expertise can go off and standardize C++
interfaces if they're so inclined.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com.
Richard Hodges
2018-08-13 07:58:19 UTC
Permalink
Post by Hyman Rosen
Post by Richard Hodges
The committee is clearly a bottleneck, I do agree. What could be done to
widen it?
Libraries don't belong in language standards. If, during library design,
someone thinks that a language change would be helpful, then they can write
a proposal just for that.
People are being misled by history. STL and iostreams were the new shiny
and a great way to show off what C++ could do, and C had a library, so
everyone thought that a C++ standard ought to have one too. That was
wrong, and doesn't need to be compounded with filesystems, regular
expressions, Bessel functions, networking, or graphics. Special interest
groups with subject-matter expertise can go off and standardize C++
interfaces if they're so inclined.
Actually you have a strong point, as does Nicol. The root of the problem is
that there is no standard way to reliably distribute the output of those
special interest groups across target platforms and build systems.

If we could solve this, everything else library-related becomes a non-issue.
Post by Hyman Rosen
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYFjvjxhSbSzWwLTMBj1veUMwp-H5S1QA%2B1t2J10QeFdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haf6_%3DHaaY-Pmy5EZqVUnQS4VTFs53bRwuWaGq_K9dRjg%40mail.gmail.com.
Robert Ramey
2018-08-13 16:15:41 UTC
Permalink
Post by Richard Hodges
The committee is clearly a bottleneck, I do agree. What could be
done to widen it?
Libraries don't belong in language standards.  If, during library
design, someone thinks that a language change would be helpful, then
they can write a proposal just for that.
People are being misled by history.  STL and iostreams were the new
shiny and a great way to show off what C++ could do, and C had a
library, so everyone thought that a C++ standard ought to have one too.
That was wrong, and doesn't need to be compounded with filesystems,
regular expressions, Bessel functions, networking, or graphics.  Special
interest groups with subject-matter expertise can go off and standardize
C++ interfaces if they're so inclined.
I agree with this.

The intent of the original C library was to make C portable across
operating systems, Just as the C language intent was to make code
portable across machine architectures. So the C library contains things
like printf etc. which had to be implemented in an operating system
specific way. The thing to do is follow this lead. So things which are
coupled to the operating system like filesystem, low level graphic, are
interesting candidates for a C++ standard library. Other things should
be handled separately and written to C++ language standard but be not
part of any concept of standard library.

Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pksanb%24ja7%241%40blaine.gmane.org.
Domen Vrankar
2018-08-13 23:08:43 UTC
Permalink
Post by Hyman Rosen
Post by Richard Hodges
The committee is clearly a bottleneck, I do agree. What could be done to
widen it?
Libraries don't belong in language standards. If, during library design,
someone thinks that a language change would be helpful, then they can write
a proposal just for that.
People are being misled by history. STL and iostreams were the new shiny
and a great way to show off what C++ could do, and C had a library, so
everyone thought that a C++ standard ought to have one too. That was
wrong, and doesn't need to be compounded with filesystems, regular
expressions, Bessel functions, networking, or graphics. Special interest
groups with subject-matter expertise can go off and standardize C++
interfaces if they're so inclined.
It's hard to agree with you... I never worked on really high performance
stuff so that's probably the reason why I don't recall those failures. For
me they were always good enough solutions that I was able to use for
prototyping and even production software.

It's nice that everybody has a plethora of time to implement everything
themselves, search for standard library alternatives before they know that
they will be the bottleneck in the particular software on which they work
and work on large scale products that need to handle millions of users and
so on. Unfortunately for me I come from the different direction - software
that has to first get established before it is feasible to poor allot of
money and effort into.

For such software you're between a rock and a hard place - you need to ship
fast and on low budget but later the successful products need to scale.
Well... You go with Java or PHP and on one hand hope that the product will
succeed as then you'll be able to continue working on it but on the other
hand you silently hope that it doesn't grow too much as then you'll have to
rewrite everything as those Java guys just don't like JNI.

From where I stand C++ went too much into large scale high performance
software while not caring how you get the software to that point.

Regards,
Domen
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BGxmOU6_xhHAOcVbU7r9mp0GrkSEo2jbPC9YHz2gmMxQ%40mail.gmail.com.
Matthew Woehlke
2018-08-13 15:37:18 UTC
Permalink
Post by Nicol Bolas
Post by Richard Hodges
I agree that packaging is a massive problem for c++, indeed its biggest
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over.
Remember: the reason C++ got into this mess to begin with was that everyone
decided to write their own build systems. Everyone decided that they had
their own needs and wrote incompatible build systems.
So the last thing C++ needs is 10 different package management systems on
top of its numerous build systems.
I don't *necessarily* see that as a problem... if those 10 different
package management systems run on 10 different operating systems.

Where package management works *well* is when it is deeply integrated
with the guts of the operating system. The fact that we have apt, dnf
and homebrew is not a problem. It's trying to use several different
pacakge managers on the same computer that turns into a problem.

(Now, at the same time, that's not to say that it wouldn't be a lot
easier on the people trying to get their software packaged if there
weren't so many options...)

BTW, it would help if we all agreed on how to *describe* our packages.
That is the goal behind https://mwoehlke.github.io/cps/. *Finding and
using* packages isn't quite the same problem as *installing* packages,
and indeed the two often don't intersect, even though they could (and
arguably should). This probably has a lot to do, however, with package
managers generally trying to support all sorts of "stuff", including
things that aren't strictly "software" (e.g. fonts, icon themes), while
the "how to find and use" problem can be language-specific. (CPS is
aimed mainly at C/C++, though it has some rudimentary support for Java.)
Post by Nicol Bolas
I agree here. I have yet to find one that actually works. There needs
to be one, which appeals to everyone. Which means it must do
everything, with utter simplicity, for all target platforms.
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%40gmail.com.
Olaf van der Spek
2018-08-13 15:48:23 UTC
Permalink
Post by Matthew Woehlke
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
--
Olaf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HPFEW_%2BW9E021LhfuBN8Wo5mGZoGDboh7Cb-L0RcLUqhw%40mail.gmail.com.
Matthew Woehlke
2018-08-13 16:15:27 UTC
Permalink
Post by Olaf van der Spek
Post by Matthew Woehlke
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
...and none of those are trying to *replace* apt/dnf/etc. None of them
infringe on the core operating system, or indeed, I suspect even compete
with it much. OTOH, pip is something of a mess because it *does* compete
directly with apt/dnf/etc... as a result, we have system python,
"system" pip installs, user-local pip installs, virtual environments,
anaconda, python packages installed via other mechanisms to none of the
above...

...oh, and, don't forget that developers are still going to need support
for local installs that may not even be packaged at all...

The languages you mentioned can get away with having an ecosystem that
is totally divorced from the core operating system because they aren't
providing things that *every* user demands. For example, a desktop, or a
web browser. Those are going to depend on things like libjpeg, which
means *at best* anything that competes with the system package manager
is going to mean having duplicate copies of those dependencies.

Personally, I think the value of trying to create yet another package
manager for C/C++ packages is... dubious at best. (Except for Windows,
because Windows doesn't already have a good one.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42112917-d345-96d3-e86e-4e307cbe984f%40gmail.com.
Domen Vrankar
2018-08-13 22:46:51 UTC
Permalink
Post by Olaf van der Spek
Post by Matthew Woehlke
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
Is it? For Java, Javascript, PHP and Ruby it seems to work quite well.
In this community dependency management systems are starting to sound like
something that will solve all our dependency issues so we don't need to
worry about the libraries as the dependency system is connected to the
aether from where it will pull libraries that will solve all our problems.
I can understand that the committee is swamped with work and can't work on
all big features that we can think of and that C++ standard library
implementers are in the same position but using a lie to the children on us
is a bit off.

I'm not certain how people still manage to praise things like Maven package
management or Nuget packages and so on. It's possible that the teams I
worked with in the past were not using them correctly (or that they are
already outdated and Java, C# and all the other languages already got their
new fancy package management systems that work) but as far as I'm concerned
programming language level package management solves nothing at best - it
just postpones the issues until later when you have less time all of them
can explode in your face at once.

So a longer explanation... The only package management systems that I
worked with and were doing their jobs fairly well were Fedora's dnf (and
yum before that) and Ubuntu's apt. The reason that I'm adding the distro
names along side the package management systems is that the only way they
didn't make my hair fall out was to stay with the latest version of the
operating system (quite often not an option for companies) so that distro
maintainers were the ones doing the heavy lifting of providing consistent
packages that were hopefully up to date with the latest upstream releases.
If they weren't... Well that's a whole new problem (meaning sometimes
compiling a ton of dependencies and those tend to snowball).

The second issue with dependency management systems is that once those are
available people tend to invite every man and his dog to become a
dependency. I know that that's a company/team issue but package management
systems tend to increase it. On one hand you have C++ where as it currently
stands we don't have modules and a standardized package management system
so libraries tend to be bigger and contain more stuff so you think
carefully if the will use size outweighs the will not use size of the
library before you add it as a dependency. On the other hand when I worked
with Java teams the packages were smaller so they added dependencies more
liberally at least until they got out of hands because of the inter package
version dependencies issues. From where I stand that's what you get when
you have allot of small components - allot of people are reusing them but
require different versions so they start colliding until the shared
libraries dependency hell is where you go on vacation after your nerves
break due to small components dependency hell.

I'm honestly happy that C++ is close to getting modules but on the other
hand I'm afraid that once they start mixing with package management systems
they'll cause the mess that I'm used to from other languages.

In the end for me language level dependency management systems (apt/dnf
don't count here as they are most of the time being used as OS level
dependency management systems) are just like Java checked exceptions - they
sound nice in theory and get you hyped but once you have to start using
them you tend form a different opinion.

Regards,
Domen
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BfkkdB_ag3E6NiZGVvdsf424%2BrZ40kwSzriWLRhw6S1w%40mail.gmail.com.
Richard Hodges
2018-08-13 18:18:47 UTC
Permalink
Post by Robert Ramey
Post by Nicol Bolas
Post by Richard Hodges
I agree that packaging is a massive problem for c++, indeed its biggest
problem. I have some ideas on how to address that, and will be starting
a
Post by Nicol Bolas
Post by Richard Hodges
project to that effect once the Summer is over.
Remember: the reason C++ got into this mess to begin with was that
everyone
Post by Nicol Bolas
decided to write their own build systems. Everyone decided that they had
their own needs and wrote incompatible build systems.
So the last thing C++ needs is 10 different package management systems
on
Post by Nicol Bolas
top of its numerous build systems.
I don't *necessarily* see that as a problem... if those 10 different
package management systems run on 10 different operating systems.
Where package management works *well* is when it is deeply integrated
with the guts of the operating system. The fact that we have apt, dnf
and homebrew is not a problem. It's trying to use several different
pacakge managers on the same computer that turns into a problem.
(Now, at the same time, that's not to say that it wouldn't be a lot
easier on the people trying to get their software packaged if there
weren't so many options...)
BTW, it would help if we all agreed on how to *describe* our packages.
That is the goal behind https://mwoehlke.github.io/cps/. *Finding and
using* packages isn't quite the same problem as *installing* packages,
and indeed the two often don't intersect, even though they could (and
arguably should). This probably has a lot to do, however, with package
managers generally trying to support all sorts of "stuff", including
things that aren't strictly "software" (e.g. fonts, icon themes), while
the "how to find and use" problem can be language-specific. (CPS is
aimed mainly at C/C++, though it has some rudimentary support for Java.)
Post by Nicol Bolas
I agree here. I have yet to find one that actually works. There needs
to be one, which appeals to everyone. Which means it must do
everything, with utter simplicity, for all target platforms.
If you try to replace apt/dnf/etc. *without* doing so at the distro
level, I *guarantee* you are just going to run into
https://xkcd.com/927/ and make things worse. For that matter, if you try
to start something new without taking into account what apt/dnf/etc.
already provide, that's just a recipe for outright failure.
I am only interested with building in a 100% cross-platform way. DNF etc
are great for building on *your linux machine* but utterly useless for
building *for any machine*.

When I say dependency/package manager, what I want is: "here is my program
- it depends (optionally) on this, that and the other. We're building it
for fedora, windows, iOS, etc. Go build it. Find or build any missing
dependencies ad stop bothering me with this nonsense".

A dependency manager for building on the local machine is not interesting.
It's a solved problem, but it doesn't solve my problem.
Post by Robert Ramey
--
Matthew
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8d604a5e-7e1b-c6c4-0e03-e3137579dc94%40gmail.com
.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZsj34JNpVbDJ1x6-H_nhtmGSfaf6GQG7MG18GWZLnjmQ%40mail.gmail.com.
Domen Vrankar
2018-08-13 23:47:13 UTC
Permalink
Post by Nicol Bolas
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
Post by Rene Rivera
Post by y***@gmail.com
hello.
i think anti paper is hateful.
thay look down the game programmer.
Speaking as a game programmer I can say I did not get the impression
of the paper being hateful to anyone, especially game programmers. In the
contrary it seems to go out of it's way to take into consideration the
concerns of game programmers and others.
Post by y***@gmail.com
last.
i need 2d graphics for my task.
I don't doubt it. But do none of existing 2d libraries satisfy your
requirement?
I think this the crux of it.
Of course the obvious answer is "yes". There are many fantastic
graphics libraries...
...and after spending 2 weeks of one's life trying to get them to
compile and run on all the platforms you want to support (because we all
want to write cross-platform software, right?) most of us lose the will to
live and go back to our horrible but reliable jobs not programming games.
So the problem has nothing to do with its appropriateness for the
standard library. It's the fact that C++ has a terrible build/package
environment. If you could download and use other libraries more easily,
then you wouldn't need it to be in the standard library at all. We should
not adopt standard library components primarily because C++ has a terrible
build/package environment.
Also, we are used to standard libraries being fast, high-performance
tools. Containers, algorithms, these are usually well-optimized stuff in
standard library implementations. So people tend to instinctively assume
that the standard library's implementation of the graphics proposal would
be equally high quality.
So let's compare the quality of other high-level stuff in the standard
library. Iostreams is pretty notorious for bad performance. People always
blame iostream's performance primarily on its interface, the many virtual
functions and the need for locale support. So maybe we can excuse it as
being as good as iostreams' design allows.
But what about Regex? From what I've gathered from others, most standard
library regex implementations perform poorly. Boost.Regex is frequently
much faster <https://stackoverflow.com/a/50611867/734069>, despite
having virtually identical interfaces to `std::regex`. Here, there's no
question; this is pure QoI, and the standard libraries aren't providing it.
Despite having had a over decade to do so (regex was part of TR1, after
all).
What that tells me is that standard library implementers just don't care
about higher-level stuff. Oh, they'll tick the feature box on their list of
what the compiler supports. But unless big name users of their platforms
*make* them optimize these things, they will not. And most big name
users of C++ platforms aren't interested in using these high level tools.
If you have a big C++ project and you needed regular expressions, you use
some library. If `std::regex` didn't provide equivalent performance to that
library, you ignored it.
HTTP and HTML are standards. Vendors fought a vicious war over 20 years
to ensure that they had the "best" implementations. The result is an
extremely functional internet. Standards are only good.
This "extremely functional internet" is based on people spending an
inordinate amount of time compensating for blatantly non-conformant,
sometimes horribly inefficient, and possibly flat-out *broken*
implementations of these standards, such that developers have to
*constantly* test every webpage on a myriad of versions of a myriad of
browsers just to make sure they actually work. The "extremely functional
internet" is very much not write once, run anywhere.
It's hard not to agree with you in this regard but...
Post by Nicol Bolas
Standards are only good when *followed*. When followed and
well-implemented. How is having regex in the C++ standard good if nobody
uses it because of how terrible implementations are? The time spent
implementing it, however badly, is wasted. The time spent standardizing it
is wasted. The time spent updating that part of the standard, keeping it in
sync with the rest, is wasted.
How is this a good, productive use of peoples' time?
Nobody is going to ditch a standard library implementation over regex;
they'll just download and use a different regex library. This is because
changing standard library implementations is often a lot harder than
installing a normal library. Also, it ensures that you get what you want
rather than playing pot-luck with whatever implementations give you.
I don't recall the failure regex in C++ standard... In large scale, high
performance software this may be true (not my department - we've had much
larger bottlenecks elsewhere and most of the time still managed to get away
with it).

Before regex came into standard we preferred writing bash scripts for such
things or harder to maintain find/replace/substring/repeat C++ code if the
data could not be transformed before entering the program. Not a high
performance solution but since we didn't need the regex features that often
it was good enough and preferred to adding an additional external
dependency.
Post by Nicol Bolas
Standards are not "only good"; they fail. They fail all the time. You just
don't hear about the failures because... they failed; people don't tend to
talk about failures unless they are spectacular. Standards which go
unimplemented or unused have failed.
IOstreams is mostly a failure. Regex in C++ failed. We don't need more
failures in C++; certainly not 100+ pages of them.
Standardising platform I/O - including graphics, consoles, keyboards, mice
Post by Richard Hodges
Post by Nicol Bolas
Post by Richard Hodges
and sound etc - would put the onus on the compiler-writing community to
solve this once for each platform, with the benefits being fanned out to
the global developer community. This is an O(1) solution in terms of
man-hours.
The current situation is that a million developers must solve the same
infuriating problems a million times, and they must do it every time a
library or a compiler suite goes through a version increment. This is at
best O(N).
In terms of lost man-hours alone, there is no possible argument that
can be made against standardisation of tools and libraries.
I'm not sure what "N" represents here (number of platforms, number of
libraries, number of GPUs? And it's not like there's only one standard
library implementation, or even one per-platform), but it doesn't really
matter. The analysis is flawed in that it assumes that all man hours are
equal.
N is the number of teams who need to use a graphics library. At the
moment, every single one must figure out how to select, compile, patch,
bugfix (because, you know, open source) and figure out why a given library
works on one platform and not another. This is an utter waste of time.
How would this change by making it part of the standard library? Oh yes,
you don't need to compile or install the standard library. But the standard
library is hardly immune to bugs. And standard library bugs are usually
harder to get rid of precisely *because* you didn't compile/install it.
You have to go get its source code (if available) and then build from that.
And to preserve your patches, you now need to effectively fork and
frequently remerge from the main standard library line.
This is an O(N) problem; this time will be "wasted" either way.
I agree that packaging is a massive problem for c++, indeed its biggest
Post by Richard Hodges
problem. I have some ideas on how to address that, and will be starting a
project to that effect once the Summer is over.
Remember: the reason C++ got into this mess to begin with was that
everyone decided to write their own build systems. Everyone decided that
they had their own needs and wrote incompatible build systems.
So the last thing C++ needs is 10 different package management systems on
top of its numerous build systems.
There are already several similar projects underway with this goal in
mind. Instead of making your own, pick the one you like the best. Even if
you don't like it *at all*, just being better than the rest is enough.
Spend your time helping it improve faster and making it better.
C++ wins if we get *one* package management system. C++ loses if we get
10 incompatible ones.
In a perfect world, maybe the standard library vendors would produce work
Post by Richard Hodges
Post by Nicol Bolas
of equivalent quality. But the C++ world is not, and will never be,
perfect. Best to improve the good and mitigate the bad.
I say we should focus on building the perfect world.
At what cost? The saying "the perfect is the enemy of the good" is often
an overused platitude, but it is very apt in this case.
The C++ standards committee only has finite amounts of time. LEWG is
already overloaded; at the last meeting, they only reviewed *half* of the
papers submitted for the standard library. And there, 2D graphics was
talked about only for a single evening. A proper review of the 2D graphics
TS would have absorbed a great deal of LWG's time
<https://botondballo.wordpress.com/2018/03/28/trip-report-c-standards-meeting-in-jacksonville-march-2018/>,
leaving even more things undone.
What should be sacrificed for 2D graphics? `span`? Low-level filesystems
work? Text formatting? Executors? Networking? Library support for
`constexpr` heap allocations? What should be sacrificed on this altar?
How many other things in C++ is this "perfect world" worth?
I agree with you here - 2D graphics proposal as it was presented is not
worth it. But that doesn't mean that language level package management
system would solve anything or that it wouldn't be feasible to add drawing
areas to the standard. I always hate it when I have to use OpenGL C api -
maybe that has changed with Vulkan C++ library that is supported by the
Khronos group (haven't checked it out yet) - and what is even more annoying
that quite often I can't use a graphics library in combination with my code
because they either try to force you to use the drawing area that their
library provides or have your rendering code conform to their api so much
that it's easier to just open up two windows and render your stuff on one
and the libraries on the other (not really scalable - maybe not even
solvable).

But if you want things to sacrifice on the altar... Even though I'll use
them once they get into the standard I'd sacrifice constexpr heap
allocations, low-level filesystem and text formatting for a definition of a
rendering surface (local and remote screen as well as back buffers that are
used for multi pass rendering) and some 2D and 3D math stuff (things that
are for example implemented in GLM library) even if the standard
implementations would perform worse than the libraries that I'm currently
using. For me prototyping and low resource input at the beginning of a
project are just as important as when the project gets more funding and
larger scope due to it being well received by the market. And for such
software (that wasn't born with high performance demands but requires them
once it has to scale) it's annoying to first have to write and maintain a
Java/C#/PHP version (prototypes quite often become first part of the
software - not smart but it happens - so prototyping languages win) and
then try to scale it into a different language once the demands grow.

For me this is not a learnability issue but a software scaling issue.

Regards,
Domen
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6B%2BXtX0eXnR8dxd-Cd29Ksjrv%2BoAqZ6QkDjGF9zkDY6%3D6Q%40mail.gmail.com.
y***@gmail.com
2018-08-13 08:38:16 UTC
Permalink
i say one of memory.

do you know BASIC lang.
it is not visual basic.
i am grow by Basic.
Basic is completly creative.
but it have some problem in spec.
i decide to go next.
the next is c lang.
it time i fall in despier.
nothing need of all.
graphic sound input
what happen??
crash my head.
as C++ cant aid it.
but c++ give me to many stady.
i can write one of sysrem.without some effecttive.

can you sell prodact it deposit warranty to other.
if other as hobbist too?
yes.i am not hate hobbist.but i need strong warranty.

one more.
do you hear c lang mean.
i am hear mean the computer.
now age's computer have many entertainment element.
but it is cant control by default.
some person on my old way.
i want to solve it.
i want to happy working for any way.

do you want to hard to hard the working? it for bisiness?

i think computer's life is bottleneck by c/c++.
C/C++ need more rich.Building needs good base.

any way the problem is the paper biggest.
need power for diet.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cf2aff90-d259-40c7-8c89-8d65b58fe3fb%40isocpp.org.
Giovanni Piero Deretta
2018-08-13 18:05:14 UTC
Permalink
Post by m***@gmail.com
Hello, I recently stumbled into p1062R0 (Diet Graphics)
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1062r0.html>
I wholeheartedly agree, the Committee should not pursue *any* from of
"Graphics Programing".
- *Impossible* to keep up-to date with modern trends - *both* hardware,
algorithms and APIs to address the hardware change all the time.
- *Impossible *to look (or perform) nearly the same on all platforms or
implementations.
- *Impossible* to be complete and useful for the real world - useful
graphics programming framework is way bigger the standard library itself!
- *Impossible* to keep up to date in terms of user requests - new
primitives, strokes, colors, brushes, filters, helper functions,
customization points, etc etc etc etc etc
- *Heavy* *burden* on the implementations.
- *Limited use *as a percent of c++ community in comparison to many
other features and libraries, including higher level ones like filesystem
- *Will open the floodgates* for *Proposals Related To Graphics* *and* *Proposals
Which Build On Top Of Graphics, *which the Committee (and the community)
will waste time considering, probably without even having the expertise for
that!
And still we have standardized stdin/stdout/stderr. You are not going to
use them to write a word processor or a fully featured logger, but they are
still useful. There are plenty of applications where graphics are only a
secondary concern which would benefit from a simple built in graphic
library.

Lack of resources or difficulty to find an agreement between vendors can
all be practical reasons not to include them in C++ of course.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a17143d-7479-4bdd-8be1-36c31c0e678c%40isocpp.org.
Loading...