Discussion:
Any progress on modules?
(too old to reply)
a***@gmail.com
2014-12-29 13:54:58 UTC
Permalink
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.

Anyway, is there any significant progress on modules? Will they be actually
implemented in C++17?

This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.

Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2014-12-29 16:46:51 UTC
Permalink
***@gmail.com writes:

| Sorry guys for posting it here and not in the modules section but I
| wasn't able to post it there.
|
| Anyway, is there any significant progress on modules? Will they be
| actually implemented in C++17?

Progress are being made. I know of at least 2 ongoing active
implementation efforts: (1) MS VC; and (2) Clang.
You will certainly hear more modules for the Lexena meeting (May 2015),
if not before.

| This question rises from the appalling compilation times C++ has
| compared to C# which is quite an embarrassment.

Everybody agrees.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
z***@gmail.com
2014-12-29 19:05:17 UTC
Permalink
Post by Gabriel Dos Reis
| Sorry guys for posting it here and not in the modules section but I
| wasn't able to post it there.
|
| Anyway, is there any significant progress on modules? Will they be
| actually implemented in C++17?
Progress are being made. I know of at least 2 ongoing active
implementation efforts: (1) MS VC; and (2) Clang.
Regarding clang: Is there any effort to implement something based on N4214
or their own system only?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2014-12-29 21:25:35 UTC
Permalink
***@gmail.com writes:

| Am Montag, 29. Dezember 2014 17:46:52 UTC+1 schrieb Gabriel Dos Reis:
|
| ***@gmail.com writes:
|
| | Sorry guys for posting it here and not in the modules section
| but I
| | wasn't able to post it there.
| |
| | Anyway, is there any significant progress on modules? Will they
| be
| | actually implemented in C++17?
|
| Progress are being made.  I know of at least 2 ongoing active
| implementation efforts: (1) MS VC; and (2) Clang.  
|
|
| Regarding clang: Is there any effort to implement something based on
| N4214 or their own system only?

I do not know the exact current implementation details of Clang; but
there is a strong consensus within WG21 and among implementers (Clang's
included) behind the general directions of N4214. There will be a joint
paper to explain where we are and what remains to be worked out.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2014-12-30 12:48:45 UTC
Permalink
Is there any chance of modules actually being production ready feature in
C++17 or is this something that we shouldn't hold on our breath for?

C# is polluting space. I don't consider it a good thing. C# doesn't give
anything (except compiling times which are really fantastic) and takes
everything.
I'm in AAA gaming industry now. I do work with Unreal Engine 4. One would
think that in this industry there wouldn't be a place for some language
which is so much slower than C++. In this industry every tick really
matters and yet, despite all of this C# is gaining ground with terrifying
speed. Part of that engine are already rewritten in C#.
What is the reason then to use C#? The answer is compilation times. As in
any development there is constant need to recompile what was written couple
of minutes ago in order to check if everything is working. With C#
compilation times are virtually non observable. Yes, *non observable*. With
C++ similar amount of lines compiles about 40 - 50 sec.
I do love C++. I do want to use it, but from what I see there is a trend to
use languages which actually increase productivity, and compilation times
do increase productivity exponentially.

I see that there is enormous amount of "proposals" traffic on virtually
daily basis, yet something as fundamentally wrong and corrupted as
compilation times is seems to be worked on with at best half speed. I
really think that this cannot end up well for C++.

If big companies have a choice of releasing their product every year
instead of a two year cycle, they will definitely go with the first option.
C++ will become a niche language. Like assembler. Like C.

I really hope that I'm so wrong.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-03 02:36:21 UTC
Permalink
Post by a***@gmail.com
Is there any chance of modules actually being production ready feature in
C++17 or is this something that we shouldn't hold on our breath for?
C# is polluting space. I don't consider it a good thing. C# doesn't give
anything (except compiling times which are really fantastic) and takes
everything.
I'm in AAA gaming industry now. I do work with Unreal Engine 4. One would
think that in this industry there wouldn't be a place for some language
which is so much slower than C++. In this industry every tick really
matters and yet, despite all of this C# is gaining ground with terrifying
speed. Part of that engine are already rewritten in C#.
What is the reason then to use C#? The answer is compilation times. As in
any development there is constant need to recompile what was written couple
of minutes ago in order to check if everything is working. With C#
compilation times are virtually non observable. Yes, *non observable*.
With C++ similar amount of lines compiles about 40 - 50 sec.
I do love C++. I do want to use it, but from what I see there is a trend
to use languages which actually increase productivity, and compilation
times do increase productivity exponentially.
I see that there is enormous amount of "proposals" traffic on virtually
daily basis, yet something as fundamentally wrong and corrupted as
compilation times is seems to be worked on with at best half speed. I
really think that this cannot end up well for C++.
If big companies have a choice of releasing their product every year
instead of a two year cycle, they will definitely go with the first option.
C++ will become a niche language. Like assembler. Like C.
I really hope that I'm so wrong.
I get the sense of alarm the OP feels, so it would be great to have some
rough answers/guesses to the questions the OP raises, by people more in the
know who might be able to make such estimations.

In my view, C++ is making some great strides with some of the best yet to
come but the OP's alarm is reflected in things like the tiobe index
where C++ still shows steady declines. Yes when Java etc. shows similar
declines it might not be as drastic as it would otherwise feel, but I don't
know Java's fortune in that context makes any difference.

When one mentions the tiobe index, people write it off as irrelevant or of
unknown value. Maybe, but I think that just means we need to find
ways to measure C++'s success that we do trust.

Perhaps some resources could be used (does isopcpp have any?) to measure if
the C++'s user base is expanding? This would allow one to gauge if the work
being done on C++ is working and when it's sufficient. Measurement is an
important aspect to most development so it would seem reasonable here.

JavaScript etc. seems to be aggressively gaining ground on everything but I
don't know that's a vote of confidence in JavaScript, more than a sign that
C++ needs to get more web integrated to compete in that space better.

In comparing the fortunes of C++ to C# as the OP does, we always talk about
using the right tool for the right job, but I actually don't see why C++
can't be good for most things and not just games but web application
development too. If not now, then hopefully soon? If not, why not?

I.e. I really think a C++ with Concepts, Modules, the Call syntax: x.f(y)
vs. f(x,y) proposal (N4174) and operator dot proposal (N4173) and one of
the co-routines proposals will more than measure up to C# in a pretty
mighty way, if that were not already the case.

When things like the Range proposal and the pattern matching work come to
fruition too, what can't C++ do well? I see no reason to talk C++ up as a
"performance only" language which is vibe I often get?

We just need to continue to remove complexity where we can too.

Overall, I think there's fabulous work being done by this site and Meeting
C++ in really bringing the C++ community together in a great way and I
think reddit is a good C++ resource too so hats off to everyone who is
making all of that happen.

It quite exciting to me compared to the years to C++ stagnation that
precluded all of this. We just need some way of measuring if this is all
really working, do we not?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Nadav Har'El
2015-01-04 10:09:18 UTC
Permalink
Post by g***@gmail.com
I get the sense of alarm the OP feels, so it would be great to have some
rough answers/guesses to the questions the OP raises, by people more in the
know who might be able to make such estimations.
In my view, C++ is making some great strides with some of the best yet to
come but the OP's alarm is reflected in things like the tiobe index
where C++ still shows steady declines.
I would like to offer my two cents.

I wholeheartedly agree that C++ needs to adopt proposals (such as modules)
that will help speed up compilation.

However, I don't get the feeling that this slow compilation can explain why
people are turning away from C++ today (if that is indeed the case - and
I'm not sure it is).
As I see this, the seriously slow compilation is a relatively *new* problem
in C++. Yes, sure, C++ compilation was always slower than the alternatives,
but this slowness used to be manageable and tolerable. But as C++ evolves
with C++11 and C++14 more and more towards generic programming, and its
astute users are making more and more complex templates, and moving more
and more code to header files, this slowness is becoming more and more
pronounced. In some cases, projects that went "overboard" (in a good
sense...) with their use of templates can find compilation to be 100 times
slower than compilation of comparable C programs. But despite all these
problems, I think they are mostly reached by people who have adopted C++ to
the fullest - not by people who have stopped using C++. So I think these
problems will cause C++'s usage to drop in the future (and we should
preemptively fix this problem - before it becomes a show-stopper) - but
cannot explain why fewer people are using C++ today (if that is indeed the
case).

So I think we need to look elsewhere to understand why people are not
flocking to C++ today - despite it being today a better language than it
ever was, and more relevant to today's programming needs than ever. One
thing which would be nice to reconsider (although perhaps this is just
pipe-dreaming, considering the 30 years of legacy....) would be the
complexity and sheer volume of the language. I learned C++ in 1988, from
the first edition of Stroustrup's book. Since then I bought (and read), the
second, third, and forth edition of this book. The most apparent thing
about these books is that their sizes - and the size of the language - grew
exponentially with time. I don't have all the editions in front of me (I
have them proudly on my bookshelf at home), but if I remember correctly the
latest edition is about 5 times thicker than it was in its first edition.
While I can't deny this was mostly a good thing - e.g., the growth of the
C++11 standard library was very important - we also can't deny how
difficult it has become to fully learn C++, even for seasoned programmers.
For beginners to write today's efficient C++ code, they need to understand
object-oriented programming, generic programming (templates), pointers,
references, move semantics, RAII, lambda capture, a large standard library
etc., etc. I've seen many programmers simply giving up and choosing other
languages. Not because they found it impossible to learn modern C++ - but
just because they thought it would be impossible to learn. And if this is
the problem that is lowering C++'s adoption rates, adding *more* features
will not help, but the opposite. Consider that the "modules" proposal, for
example, does not offer to replace the old "#include" method but to keep
both - so now people learning C++ will need to learn both, instead of just
modules. And the fifth edition of the C++ book will become even thicker :-)
Post by g***@gmail.com
We just need to continue to remove complexity where we can too.
Perhaps we need two C++ books: "Object Oriented C++" focusing on simplicity
and easy-to-understand code, and "Generic C++" focusing on optimum
performance of generated code (move semantics, templates, etc.). Both books
will need to drop historical comparisons, no-longer-recommended language
constructs, etc., which only complicate the life of beginners.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-04 21:15:13 UTC
Permalink
Post by Nadav Har'El
Post by g***@gmail.com
I get the sense of alarm the OP feels, so it would be great to have some
rough answers/guesses to the questions the OP raises, by people more in the
know who might be able to make such estimations.
In my view, C++ is making some great strides with some of the best yet to
come but the OP's alarm is reflected in things like the tiobe index
where C++ still shows steady declines.
I would like to offer my two cents.
I wholeheartedly agree that C++ needs to adopt proposals (such as modules)
that will help speed up compilation.
However, I don't get the feeling that this slow compilation can explain
why people are turning away from C++ today (if that is indeed the case -
and I'm not sure it is).
As I see this, the seriously slow compilation is a relatively *new*
problem in C++. Yes, sure, C++ compilation was always slower than the
alternatives, but this slowness used to be manageable and tolerable. But as
C++ evolves with C++11 and C++14 more and more towards generic programming,
and its astute users are making more and more complex templates, and moving
more and more code to header files, this slowness is becoming more and more
pronounced. In some cases, projects that went "overboard" (in a good
sense...) with their use of templates can find compilation to be 100 times
slower than compilation of comparable C programs. But despite all these
problems, I think they are mostly reached by people who have adopted C++ to
the fullest - not by people who have stopped using C++. So I think these
problems will cause C++'s usage to drop in the future (and we should
preemptively fix this problem - before it becomes a show-stopper) - but
cannot explain why fewer people are using C++ today (if that is indeed the
case).
The speed issue you are talking about here will be fixed by Modules though
right? Or are you thinking something in addition is needed to improve the
speed?
Post by Nadav Har'El
So I think we need to look elsewhere to understand why people are not
flocking to C++ today - despite it being today a better language than it
ever was, and more relevant to today's programming needs than ever. One
thing which would be nice to reconsider (although perhaps this is just
pipe-dreaming, considering the 30 years of legacy....) would be the
complexity and sheer volume of the language. I learned C++ in 1988, from
the first edition of Stroustrup's book. Since then I bought (and read), the
second, third, and forth edition of this book. The most apparent thing
about these books is that their sizes - and the size of the language - grew
exponentially with time. I don't have all the editions in front of me (I
have them proudly on my bookshelf at home), but if I remember correctly the
latest edition is about 5 times thicker than it was in its first edition.
While I can't deny this was mostly a good thing - e.g., the growth of the
C++11 standard library was very important - we also can't deny how
difficult it has become to fully learn C++, even for seasoned programmers.
For beginners to write today's efficient C++ code, they need to understand
object-oriented programming, generic programming (templates), pointers,
references, move semantics, RAII, lambda capture, a large standard library
etc., etc. I've seen many programmers simply giving up and choosing other
languages. Not because they found it impossible to learn modern C++ - but
just because they thought it would be impossible to learn. And if this is
the problem that is lowering C++'s adoption rates, adding *more* features
will not help, but the opposite. Consider that the "modules" proposal, for
example, does not offer to replace the old "#include" method but to keep
both - so now people learning C++ will need to learn both, instead of just
modules. And the fifth edition of the C++ book will become even thicker :-)
Post by g***@gmail.com
We just need to continue to remove complexity where we can too.
Perhaps we need two C++ books: "Object Oriented C++" focusing on
simplicity and easy-to-understand code, and "Generic C++" focusing on
optimum performance of generated code (move semantics, templates, etc.).
Both books will need to drop historical comparisons, no-longer-recommended
language constructs, etc., which only complicate the life of beginners.
I think two books are a good idea and more books in general.
Regarding complexity, I don't know what more can be done to reduce the
complexity of C++ than what's already being done that would make any
significant difference?

Some things like Uniform Initialization irk me because it gives the
feeling that "we have two ways of doing the same thing". I find that
somewhat true because the new syntax looks "wrong" and out of place against
anything existing so I don't like using it except where I need it and it
seems unlikely that you can just teach one of those syntaxes with so much
existing code out there, so I can see everyone using both syntaxes forever
now?

Any new syntax here would have resulted in the same thing so what can you
do. I wish it had been possible to fix the existing syntax and deal with
compatibility some other way to avoid what actually happened but I'm sure
that wasn't viable so that's just the deal I guess. Is it a big deal,
probably not, but it feels hacky and looks ugly and adds to that "ugh"
feeling of C++ a little. Other languages aren't burdened by that stuff so
they have an advantage there.

But move semantics while they complicate the language on some levels they
also simplify it too and overall it's hard to see resist a feature that
means you can just recompile your existing code and have it go faster for
nothing. I have heard the "you don't need to know how that works if you
don't want to" argument applied to some of these things but sometimes there
is no substitute for having to learn how to use powerful tools if you want
to create powerful things. I can't imagine not having that "move" now,
that's my acid test.

I think a lot of the day to day complexity is going to be reduced in my
opinion in C++ even if it doesn't help with learning the language itself.

I think Concepts will make error messages drastically better for everyone,
especially for new users to C++ and I think that will help a lot.
I also suspect a new STL will arrive in the future that that will reduce a
lot of niggles and things like signed/unsigned harassment at the very least.
The new Range facilities will surely make a lot of iterator stuff much
tidier and new algorithms will mean you will need to roll your own code
much less often and mess with a lot less bugs.
And when modules arrive, if they drastically do improve the compile times,
I'm hopeful C++ might get some clearly noticeable upward traction at that
time.

I'm hopeful that will all turn things around. It would just be nice to be
able to measure that happening reliably.

If people want to use C# instead, well what can you do. I programmed in C#
for years before returning to C++. I found C# to be all very productive and
the tools too, but despite that I was utterly bored by it. I honestly don't
know what that says?

But my hope is that if C++ keeps improving the way it is and just as
importantly if the tools around it do the same then I don't see why C++
can't be every bit as productive as C# if not more so. At that point it
just needs more libraries and to get targeted into new application areas
outside it's typical domains of gaming and infrastructure. I'd love to see
it hit back hard in general line of business app development.

In the end, isn't it the case that C++, C#, and Java are now all so big
that they are all a mission to learn if you are just starting?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 01:55:32 UTC
Permalink
Post by g***@gmail.com
The speed issue you are talking about here will be fixed by Modules though
right? Or are you thinking something in addition is needed to improve the
speed?
My guess -- and this is an entire guess -- is that it won't be entirely fixed.
Modules will help, but how much remains to be seen.

The largest part of the time compiling C++ code does not seem to be related to
the preprocessor. My experience with enabling precompiled headers in a large
C++ project (Qt) is that it can reduce the build time from 20 to 30%. And I'm
not sure Modules would be that much faster than precompiled headers,
especially considering precompiled headers have no requirement to binary
compatibility between compiler versions (they're never installed).

If I am to be optimistic, I'd say that Modules may speed up compilations by up
to 2x -- that is, 50% faster. The rest is still going to remain as compilation
itself, optimisation and linking.

Heck, linking has got SLOWER recently, with GCC and Clang supporting link-time
optimisation, which is a great performance improvement. Fair enough, that's
for release builds.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-05 03:09:55 UTC
Permalink
Post by Ville Voutilainen
Post by g***@gmail.com
The speed issue you are talking about here will be fixed by Modules
though
Post by g***@gmail.com
right? Or are you thinking something in addition is needed to improve
the
Post by g***@gmail.com
speed?
My guess -- and this is an entire guess -- is that it won't be entirely fixed.
Modules will help, but how much remains to be seen.
The largest part of the time compiling C++ code does not seem to be related to
the preprocessor. My experience with enabling precompiled headers in a large
C++ project (Qt) is that it can reduce the build time from 20 to 30%. And I'm
not sure Modules would be that much faster than precompiled headers,
especially considering precompiled headers have no requirement to binary
compatibility between compiler versions (they're never installed).
If I am to be optimistic, I'd say that Modules may speed up compilations by up
to 2x -- that is, 50% faster. The rest is still going to remain as compilation
itself, optimisation and linking.
Heck, linking has got SLOWER recently, with GCC and Clang supporting link-time
optimisation, which is a great performance improvement. Fair enough, that's
for release builds.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
This might make you a heretic to answer but the burning question then is if
you could click your fingers and magically turn all your code in QT from
C++ to C# with zero compatibility issues for you and your customers in
order to get the near instant compile times that C# gives, would you do it?

Are speedier compile times the killer feature that would make the
difference to make people prefer C++ to C# if they don't already? What is?

If modules really aren't the killer productivity feature then that a lot of
people are hoping they will be, how bad is that?

What else can be done to make up the difference?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 04:59:42 UTC
Permalink
Post by g***@gmail.com
Post by Thiago Macieira
Heck, linking has got SLOWER recently, with GCC and Clang supporting link-time
optimisation, which is a great performance improvement. Fair enough, that's
for release builds.
This might make you a heretic to answer but the burning question then is if
you could click your fingers and magically turn all your code in QT from
C++ to C# with zero compatibility issues for you and your customers in
order to get the near instant compile times that C# gives, would you do it?
No, definitely not. Reasons I can think of:

1) all our devs know C++, not C#. Why would we use a language we don't know?
2) is C# usable on embedded devices (bare metal)? On iOS?
3) we have a reasonably good influence on the C++ language and we're well-
known, whereas in C# we'd be competing with MS efforts and Mono.
4) we *like* the control over everything that C++ gives us. Give me pointers
so I can do GC, reference counting or whatever I may choose, instead of
choosing for me. We in fact have a little bit of assembly in Qt (intrinsics
and inline assembly).
Post by g***@gmail.com
Are speedier compile times the killer feature that would make the
difference to make people prefer C++ to C# if they don't already? What is?
No. When I used to work for Trolltech, we sped up our builds considerably by
doing distributed builds. Each developer's machine was part of the build farm,
offering its resources to everyone else. The machine only did preprocessing and
sent the compressed preprocessed output over the network for everyone else to
help. I used to do make -j60 and I never saturated the network.

We initially developed our own tool for that (called Teambuilder) and now
there's an open source replacement for Linux called icecc (or icecream). For
Windows, there's Incredibuild, which does similar things.

Like I said, build times are not the issue. You don't rebuild that often,
especially as you don't have to rebuild everything every time. Very few people
touch a global header that affects everything. And with judicious use of
ccache, even rebased builds that did touch qglobal.h can be sped up
considerably, to just a couple of minutes. When developing, I usually have to
wait for very little time when I press Ctrl+B (Build) or F5 (Start Debugging)
in Qt Creator.

Even in our Continuous Integration system, the turnaround time is limited by
availability of machines (especially OS X, since they can't be virtualised on
generic hardware) and the time it takes to actually run the tests. If Qt takes
45 minutes to build from scratch, the tests take another 150-180 minutes to
run.
Post by g***@gmail.com
If modules really aren't the killer productivity feature then that a lot of
people are hoping they will be, how bad is that?
They're not bad. Modules are there to solve the preprocessor problems, not
speed up compilation. Like I said in the previous email, the build time is
mostly spent in the actual compilation part and in the optimiser and linker.
Post by g***@gmail.com
What else can be done to make up the difference?
Stop thinking that build times are the issue. They're not.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-05 05:51:45 UTC
Permalink
On Monday, January 5, 2015 5:59:48 PM UTC+13, Thiago Macieira wrote:
<snip>
Post by Thiago Macieira
Post by g***@gmail.com
What else can be done to make up the difference?
Stop thinking that build times are the issue. They're not.
They are not for me, but I can easily see why they would be for other
people who work on larger projects than me.

Pre compiled headers and distributed builds such as you mention
are features that require people to have to learn how to use them and set
them up which requires additional effort and knowledge to what is already a
big learn on top of C++.

They are also not standard features in anyway and aren't typical bundled /
built into most tool chains (as far as I know) so I think that a lot of
people don't use them (even if they should).

I can see beginners being quite impressed by fast build times and a
competitive language that featured that would be quite compelling to a
beginner or expert alike especially when it means they don't have to learn
about distributed build systems etc. on top of the language.

So though I kind of agree with you, I'm not sure I agree entirely overall
because of what I've just said. The OP's experience would seem to not match
yours. Maybe they can elaborate.

Perhaps when the all of the features you mentioned like distributed builds
and precompiled headers are standard, default or bundled with all the major
tool chains, then the view that compilation speed isn't THAT big of a
factor might be more universally shared.

It would seem an area where value could be added by bundling distributed
build systems with compilers etc.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Nadav Har'El
2015-01-05 17:27:13 UTC
Permalink
Post by g***@gmail.com
Post by g***@gmail.com
What else can be done to make up the difference?
Stop thinking that build times are the issue. They're not.
They are not for me, but I can easily see why they would be for other
people who work on larger projects than me.
Unfortunately, even in small projects, compilation problems can become
annoying. One C++ project I'm involved with has just 48 source files with
30,000 LOC - not huge by any measure - but takes more than two minutes to
compile on 4 cores.

Some of the previous posters on this thread seem to blame all the
compilation slowness on modules. I'd like to a few other issues which I
believe help the slowness

1. Templates and inline code sits in header files, which is included by
many source files, so if a header file is changed, it causes many source
files to need to be recompiled. It's not clear to me if modules will
completely eliminate this problem.

2. In the old days, the optimizer was a nice bonus, but debugging builds
were often unoptimized and were faster to compile. But a lot of modern C++
code assumes the optimizer is smart enough to get rid of all sort of
unnecessary cruft, resulting in unoptimized builds that are unacceptably
slow - I've seen one case it was 10 times slower than the optimized build -
so people end up often building with "-O2" - which makes compilation slower.

3. A lot of clever modern C++ code uses a lot of template metaprogramming
tricks, and these are excruciatingly slow, and in some cases even exhibit
non-linear time. I've seen one example where one particular template trick
caused one source file's compilation to jump to several minutes (!), which
obviously meant we couldn't use this trick. It would be nice if some time
in the future, C++ could adopt some sort of efficient compile-time language
which is more efficient than template metaprogramming.

Some things can be done even today today to improve on these problems. As
one silly example, consider a trivial (a handful of lines of code) boost
unit test which uses:

#include <boost/test/included/unit_test.hpp>

Compiling such a trivial test case on my machine takes a whopping 10
seconds.

The problem is that this specific header file contains all the boost unit
test framework, so it needs to be compiled again and again every time.
Boost provides an alternative, a pre-compiled libboost_unit_test_framework,
and then you only include <boost/test/unit_test.hpp> which includes less
code. Compiling with this method takes just one second - which is still a
lot (for one trivial source file!), but 10 times faster than the other way.

So even without modules and other future improvements, programmers already
have techniques to speed up compilation somewhat, but it's difficult and
unnatural, and people often don't use them, and it results in painfully
slow build times. Even the one second compilation example I gave above as
an improvement is too slow to be proud of.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-05 18:15:38 UTC
Permalink
Hi,
Thank you for your input.

To me as a developer in AAA company, I simply don't have time to use all
those tricks and methods and what not in order to speed up compilation
times. I as a developer in modern world expect that to have that feature
"out of the box" from so called modern language, so I can keep myself busy
with actual game content creation and programming - things that I actually
get paid for, that is things that actual users of my product can see and
buy.

I'm sorry but this is hard real world. If I can release iteration of my
product every year instead of every two years, without *visible* loss of
performance and quality then I'm sorry but here my commitment to C++ ends.
I have family to think of, and if C++ isn't going to improve my life but
make it worse I do not feel obliged to be loyal to it and I'm actually
forced by C++ to chose an alternative - C#.
Post by Nadav Har'El
Post by g***@gmail.com
Post by g***@gmail.com
What else can be done to make up the difference?
Stop thinking that build times are the issue. They're not.
They are not for me, but I can easily see why they would be for other
people who work on larger projects than me.
Unfortunately, even in small projects, compilation problems can become
annoying. One C++ project I'm involved with has just 48 source files with
30,000 LOC - not huge by any measure - but takes more than two minutes to
compile on 4 cores.
Some of the previous posters on this thread seem to blame all the
compilation slowness on modules. I'd like to a few other issues which I
believe help the slowness
1. Templates and inline code sits in header files, which is included by
many source files, so if a header file is changed, it causes many source
files to need to be recompiled. It's not clear to me if modules will
completely eliminate this problem.
2. In the old days, the optimizer was a nice bonus, but debugging builds
were often unoptimized and were faster to compile. But a lot of modern C++
code assumes the optimizer is smart enough to get rid of all sort of
unnecessary cruft, resulting in unoptimized builds that are unacceptably
slow - I've seen one case it was 10 times slower than the optimized build -
so people end up often building with "-O2" - which makes compilation slower.
3. A lot of clever modern C++ code uses a lot of template metaprogramming
tricks, and these are excruciatingly slow, and in some cases even exhibit
non-linear time. I've seen one example where one particular template trick
caused one source file's compilation to jump to several minutes (!), which
obviously meant we couldn't use this trick. It would be nice if some time
in the future, C++ could adopt some sort of efficient compile-time language
which is more efficient than template metaprogramming.
Some things can be done even today today to improve on these problems. As
one silly example, consider a trivial (a handful of lines of code) boost
#include <boost/test/included/unit_test.hpp>
Compiling such a trivial test case on my machine takes a whopping 10
seconds.
The problem is that this specific header file contains all the boost unit
test framework, so it needs to be compiled again and again every time.
Boost provides an alternative, a pre-compiled libboost_unit_test_framework,
and then you only include <boost/test/unit_test.hpp> which includes less
code. Compiling with this method takes just one second - which is still a
lot (for one trivial source file!), but 10 times faster than the other way.
So even without modules and other future improvements, programmers already
have techniques to speed up compilation somewhat, but it's difficult and
unnatural, and people often don't use them, and it results in painfully
slow build times. Even the one second compilation example I gave above as
an improvement is too slow to be proud of.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Vicente J. Botet Escriba
2015-01-05 22:45:14 UTC
Permalink
Post by a***@gmail.com
Hi,
Thank you for your input.
To me as a developer in AAA company, I simply don't have time to use
all those tricks and methods and what not in order to speed up
compilation times. I as a developer in modern world expect that to
have that feature "out of the box" from so called modern language, so
I can keep myself busy with actual game content creation and
programming - things that I actually get paid for, that is things that
actual users of my product can see and buy.
Hi,

could you tell me the compiler you are using to create your games? How
much it cost to your company?
Which libraries are you using? How much it cost to your company?

If companies are ready to spend more for the tools they use, maybe we
could expect to have better compilers, tools, libraries, standards, ....

Just my 2 cts.
Vicente
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
G M
2015-01-05 20:52:07 UTC
Permalink
Post by Nadav Har'El
Post by g***@gmail.com
Post by g***@gmail.com
What else can be done to make up the difference?
Stop thinking that build times are the issue. They're not.
They are not for me, but I can easily see why they would be for other
people who work on larger projects than me.
Unfortunately, even in small projects, compilation problems can become
annoying. One C++ project I'm involved with has just 48 source files with
30,000 LOC - not huge by any measure - but takes more than two minutes to
compile on 4 cores.
Hi thanks for the detail. I think your post is quite reflective of the
situation and feelings in general.
Post by Nadav Har'El
Some of the previous posters on this thread seem to blame all the
compilation slowness on modules. I'd like to a few other issues which I
believe help the slowness
1. Templates and inline code sits in header files, which is included by
many source files, so if a header file is changed, it causes many source
files to need to be recompiled. It's not clear to me if modules will
completely eliminate this problem.
It'd be great if someone like Richard Smith could comment here. clang and
llvm are all giant mloc applications. He is very familiar with very large
code bases and he does work on Modules for clang which appears to be in
quite an advanced state of development. If I'm not mistaken in all of
that, he might be another great candidate to comment.
Post by Nadav Har'El
2. In the old days, the optimizer was a nice bonus, but debugging builds
were often unoptimized and were faster to compile. But a lot of modern C++
code assumes the optimizer is smart enough to get rid of all sort of
unnecessary cruft, resulting in unoptimized builds that are unacceptably
slow - I've seen one case it was 10 times slower than the optimized build -
so people end up often building with "-O2" - which makes compilation slower.
I don't know if you using MSVC but that certainly did a few things to
burden debug builds but I think they are working on performance in a much
more focused way than they have in the past so that might improve a bit in
2015.

It's worth reminding ourselves that not everything that is wrong with build
times etc. is actually C++. It's sometimes the tools themselves but that's
no consolation If nobody fixes them and C++ will get the blame if they
don't. It does seem there is a trend to fix things, but unfortunately Intel
spots those trends and likes to throw slower hardware at that when that
happens.
Post by Nadav Har'El
3. A lot of clever modern C++ code uses a lot of template metaprogramming
tricks, and these are excruciatingly slow, and in some cases even exhibit
non-linear time. I've seen one example where one particular template trick
caused one source file's compilation to jump to several minutes (!), which
obviously meant we couldn't use this trick. It would be nice if some time
in the future, C++ could adopt some sort of efficient compile-time language
which is more efficient than template metaprogramming.
Some things can be done even today today to improve on these problems. As
one silly example, consider a trivial (a handful of lines of code) boost
#include <boost/test/included/unit_test.hpp>
Compiling such a trivial test case on my machine takes a whopping 10
seconds.
The problem is that this specific header file contains all the boost unit
test framework, so it needs to be compiled again and again every time.
Boost provides an alternative, a pre-compiled libboost_unit_test_framework,
and then you only include <boost/test/unit_test.hpp> which includes less
code. Compiling with this method takes just one second - which is still a
lot (for one trivial source file!), but 10 times faster than the other way.
Maybe the very experienced people at boost might want to spend time looking
at these things. I think they will if more people actively discuss what
they find and there development experience. Thanks for doing so.
Post by Nadav Har'El
So even without modules and other future improvements, programmers already
have techniques to speed up compilation somewhat, but it's difficult and
unnatural, and people often don't use them, and it results in painfully
slow build times. Even the one second compilation example I gave above as
an improvement is too slow to be proud of.
I think this statement is entirely reflective of the reality. I see that MS
(for example) are looking for a lot of feedback in this area right now on
their blogs. They have a history of not listening to that feedback which
can be frustrating but things are improving there. I hope you start to
see improvement here and that it continues.

While I'm here I wonder what the intersection of pre-compiled headers and
modules might be or if one utterly replaces the other. I also wonder if
modules is going to take sometime to arrive, if pre-compiled headers could
be informally standardized by at least the main tool vendors i.e. for gcc,
clang and msvc....
Post by Nadav Har'El
--
---
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-discussion/IU9FSoLXPh0/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 22:50:25 UTC
Permalink
Post by Nadav Har'El
Unfortunately, even in small projects, compilation problems can become
annoying. One C++ project I'm involved with has just 48 source files with
30,000 LOC - not huge by any measure - but takes more than two minutes to
compile on 4 cores.
It's either dependent on how your project coded its source code or on the
frameworks you're using. Or both.

With 4 cores, in two minutes I can compile (in debug mode) all of QtCore and
that's 253 source files, plus the running of moc on 43 header files, one run of
uic, compiling 177 headers with -Werror and the linking, with 13 seconds to
spare. That's 250 kLOC.
Post by Nadav Har'El
Some of the previous posters on this thread seem to blame all the
compilation slowness on modules. I'd like to a few other issues which I
believe help the slowness
1. Templates and inline code sits in header files, which is included by
many source files, so if a header file is changed, it causes many source
files to need to be recompiled. It's not clear to me if modules will
completely eliminate this problem.
That is true. I guess they won't, not entirely, but they should help a lot.
Like precompiled headers, the template information can be stored in the Module
output. At the very least, this saves the first pass of the compilation and a
lot of the parsing.
Post by Nadav Har'El
2. In the old days, the optimizer was a nice bonus, but debugging builds
were often unoptimized and were faster to compile. But a lot of modern C++
code assumes the optimizer is smart enough to get rid of all sort of
unnecessary cruft, resulting in unoptimized builds that are unacceptably
slow - I've seen one case it was 10 times slower than the optimized build -
so people end up often building with "-O2" - which makes compilation slower.
Also true. There's -Og in newer GCC versions but I've never tried to debug
with that. The old rule of thumb I had was -O2 -fno-inline -fno-reorder-blocks
-fno-sched-insns, which made for debuggable code, but still slow due to -fno-
inline.
Post by Nadav Har'El
Some things can be done even today today to improve on these problems. As
one silly example, consider a trivial (a handful of lines of code) boost
#include <boost/test/included/unit_test.hpp>
Compiling such a trivial test case on my machine takes a whopping 10
seconds.
The problem is that this specific header file contains all the boost unit
test framework, so it needs to be compiled again and again every time.
Boost provides an alternative, a pre-compiled libboost_unit_test_framework,
and then you only include <boost/test/unit_test.hpp> which includes less
code. Compiling with this method takes just one second - which is still a
lot (for one trivial source file!), but 10 times faster than the other way.
Again, it's a choice you made for using that framework.

<QtTest/QtTest> takes somewhere between 500 ms and 750 ms to compile for me
and that includes all of QtTest and all of QtCore headers. Of course, this
does not include the time to compile QtCore and QtTest themselves, but that's
something I do, not my users.

As you can see, I am a big fan of using C++ judiciously. You don't have to use
all the features the language gives you just because they're there. Use what
makes sense and make good use of those that you do. In other words, don't
abuse the language. If you need to do something more complex that the language
doesn't support, there are code generators (e.g., gperf for a perfect hash).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-05 04:09:59 UTC
Permalink
Post by Thiago Macieira
The largest part of the time compiling C++ code does not seem to be related to
the preprocessor. My experience with enabling precompiled headers in a large
C++ project (Qt) is that it can reduce the build time from 20 to 30%.
From what I understand, the description of modules in the Clang page does seem to be like multiple precompiled headers. Precompiled headers can help a lot. They were essential when I used Eigen with GCC in a project with several source files. They don’t only save the result of preprocessing; the AST and perhaps other stuff such as class layouts and class template instantiations get saved too.

The problem with PCHes is that they introduce a dependency bottleneck. Any header included from the PCH is cheap-as-free, but adding a header to the PCH requires recompiling everything else. That’s what modules should fix.

Templates need to be accelerated too, for libraries that spend significant time on instantiation. Any cross-TU template cache pretty much turns into export templates. I think that’s where things ultimately need to go, but the issue is old and it’s orthogonal to modules.

For what it’s worth, I don’t see why a compiler can’t just make a list of all tokens that are used (hence not allowed as macro names) by a particular header, and cache that header as if it were a module as long as no such macros are defined. Such caching would be an evolutionary leap forward, and applied to things other than tokens, it would help with ODR diagnosis.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 05:02:26 UTC
Permalink
Post by David Krauss
The problem with PCHes is that they introduce a dependency bottleneck. Any
header included from the PCH is cheap-as-free, but adding a header to the
PCH requires recompiling everything else. That’s what modules should fix.
Indeed. One of the finds I had when I introduced a Qt-wide precompiled header
solution is that it slowed down the build for the small modules. Adding a
precompiled header is like adding a new source file, so if you have 4 other
sources, you should expect it to add to the build time. Not to mention that
it's in the critical path for everything else: if you have 8 cores, 7 are idle
while the header is precompiled.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2015-01-07 13:45:29 UTC
Permalink
"Nadav Har'El" <***@cloudius-systems.com> writes:

[...]

| Consider that the
| "modules" proposal, for example, does not offer to replace the old
| "#include" method but to keep both - so now people learning C++ will
| need to learn both, instead of just modules. And the fifth edition of
| the C++ book will become even thicker :-)

That is an unfair characterization, and only play to the hands of those
who would like to ridicule C++ for being too bloated, without paying any
single attention to the constraints within which the language evolution
has to operate.

As noted in the module proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4214.pdf, pp
4-5), the preprocessor has been around for far too long and supports far
too many creative usage for its eradication to be realistic in the short
term. Past experience suggests that any improvements to the preprocessor
(for modularization) is likely to be judged either not enough or going
too far.

One of the primary characteristics of a module is that importing a
module twice (or more) in the same translation unit has the same effect
as just importing it just once. However, real-world programs contain
source files that are designed expressly to be included several times in
the same translation unit. Clearly, those constructs aren't modular;
and you can't reasonably blame modules for being modular.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-07 14:15:40 UTC
Permalink
| so now people learning C++ will
| need to learn both, instead of just modules. And the fifth edition of
| the C++ book will become even thicker :-)
That is an unfair characterization, and only play to the hands of those
who would like to ridicule C++ for being too bloated, without paying any
single attention to the constraints within which the language evolution
has to operate.
This rhetoric is falling flat. There is little difference between being “constrained by legacy” and being “bloated.”

However, modules will indeed hopefully save beginners from learning about #include, since multiply-included headers are the exclusive domain of advanced metaprogrammers.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2015-01-07 14:38:50 UTC
Permalink
David Krauss <***@gmail.com> writes:

| On 2015–01–07, at 9:45 PM, Gabriel Dos Reis <***@axiomatics.org>
| wrote:
| | so now people learning C++ will
|
| | need to learn both, instead of just modules. And the fifth
| edition of
| | the C++ book will become even thicker :-)
|
|
|
| That is an unfair characterization, and only play to the hands of
| those
| who would like to ridicule C++ for being too bloated, without
| paying any
| single attention to the constraints within which the language
| evolution
| has to operate.
|
|
| This rhetoric is falling flat. There is little difference between
| being “constrained by legacy” and being “bloated.”

I have no clue of what you mean. I don't know what you mean by
"constrained by legacy". I gave an example (in the part that you left
out in your reply) of a scenario where the desired semantics of module
cannot cover what people do today (and will continue to do) with
#include, even in a module unit.

| However, modules will indeed hopefully save beginners from learning
| about #include, since multiply-included headers are the exclusive
| domain of advanced metaprogrammers.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-03 05:35:29 UTC
Permalink
Is there any chance of modules actually being production ready feature in C++17 or is this something that we shouldn't hold on our breath for?
Modules will be standardized as a Technical Specification, a separate standard document from C++17. Compilers will implement the TS as an extension much like they did the TR1 library. As far as I can tell, the Clang and MSVC implementations are working toward convergence while meeting the demands of their volunteer test users, and the TS will reflect that convergence without much input from the greater C++ committee.

Given the TS and sufficient user adoption, it should be merged with a future C++ standard, presumably after 2017.

If you want to know where modules are really at, you might test-drive the Clang implementation. Also, please report back on your experiences, because I’ve not heard anything from anyone outside the development effort.

http://clang.llvm.org/docs/Modules.html
I can’t find a page for MSVC. The feature might not have a public release yet.
GCC doesn’t seem to have an ongoing effort.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Ville Voutilainen
2015-01-03 14:58:17 UTC
Permalink
Post by a***@gmail.com
Is there any chance of modules actually being production ready feature in
C++17 or is this something that we shouldn't hold on our breath for?
Modules will be standardized as a Technical Specification, a separate
That has not been decided yet, so it's too early to make such statements.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-04 03:07:18 UTC
Permalink
Post by Ville Voutilainen
That has not been decided yet, so it's too early to make such statements.
Oh? What’s the other alternative?

What bar needs to be passed for the WG to accept a TS?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Ville Voutilainen
2015-01-04 08:35:05 UTC
Permalink
Post by David Krauss
Post by Ville Voutilainen
That has not been decided yet, so it's too early to make such statements.
Oh? What’s the other alternative?
C++17. Now, to be fair, even though this is mere speculation, there
are some indications
according to which it's somewhat likely that a TS would be a probable target.
Post by David Krauss
What bar needs to be passed for the WG to accept a TS?
A straw poll that is accepted by the committee, of course. :)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-04 12:24:53 UTC
Permalink
Post by Ville Voutilainen
C++17. Now, to be fair, even though this is mere speculation, there
are some indications
according to which it's somewhat likely that a TS would be a probable target.
So, C++17 if they finish the design, prototyping, implementation convergence, and formal specification all within the next two years or so, else a TS. It’s possible, I suppose, in theory.
Post by Ville Voutilainen
Post by David Krauss
What bar needs to be passed for the WG to accept a TS?
A straw poll that is accepted by the committee, of course. :)
But as for what the committee is looking for, is my impression correct that they only need to document the behavior of publicly deployed implementations? In other words, the committee won’t actively try to add improvements or critique the functionality.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Ville Voutilainen
2015-01-05 04:07:23 UTC
Permalink
Post by David Krauss
Post by Ville Voutilainen
C++17. Now, to be fair, even though this is mere speculation, there
are some indications
according to which it's somewhat likely that a TS would be a probable target.
So, C++17 if they finish the design, prototyping, implementation convergence, and formal specification all within the next two years or so, else a TS. It’s possible, I suppose, in theory.
Yes, in theory. That's also assuming, in addition to other material
like Concepts
being candidates for IS inclusion, that the committee wants to try to
include Modules
straight into an IS. We don't know yet how it'll play out.
Post by David Krauss
Post by Ville Voutilainen
Post by David Krauss
What bar needs to be passed for the WG to accept a TS?
A straw poll that is accepted by the committee, of course. :)
But as for what the committee is looking for, is my impression correct that they only need to document the behavior of publicly deployed implementations? In other words, the committee won’t actively try to add improvements or critique the functionality.
The committee will most likely do both. WG21 is recommended but not
required to standardize
existing practice, and it's a fairly inventive group, so there are no
such hard limitations to
what kind of feedback it may provide.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2015-01-07 13:55:02 UTC
Permalink
David Krauss <***@gmail.com> writes:

| > On 2015–01–03, at 10:58 PM, Ville Voutilainen
| > <***@gmail.com> wrote:
| >
| > That has not been decided yet, so it's too early to make such statements.
|
| Oh? What’s the other alternative?

At this point? I would say the same as any other interesting new C++
functionality that has the potential to significantly alter how we
practice programming with C++ :-)

| What bar needs to be passed for the WG to accept a TS?

My personal view is that obsessing over TS at this point is premature.
I would rather see a spec and implementations, and then decide how to
handle it than decide upfront the bureaucratic vehicle it must ride
before we've seen the complete spec.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2015-01-07 13:50:52 UTC
Permalink
David Krauss <***@gmail.com> writes:

| On 2014–12–30, at 8:48 PM, ***@gmail.com wrote:
|
|
| Is there any chance of modules actually being production ready
| feature in C++17 or is this something that we shouldn't hold on
| our breath for?
|
|
| Modules will be standardized as a Technical Specification, a separate
| standard document from C++17.

Who said that?

[...]

| I can’t find a page for MSVC. The feature might not have a public
| release yet.

Correct. Like I said, there is an ongoing implementation effort; news
and findings will be shared as things mature enough and other
circumstances permit.

| GCC doesn’t seem to have an ongoing effort.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-05 11:00:32 UTC
Permalink
@Tiego Maciera
Post by g***@gmail.com
Post by Thiago Macieira
1) all our devs know C++, not C#. Why would we use a language we don't
know?
Well, that is just your case. In my personal experience out of 10 new devs
coming out of college 2 know C++ rest is spread between C# and Java.
Post by g***@gmail.com
Post by Thiago Macieira
2) is C# usable on embedded devices (bare metal)? On iOS?
No, but in many scenarios this isn't a big issue. Example: AAA games.
Post by g***@gmail.com
Post by Thiago Macieira
4) we *like* the control over everything that C++ gives us. Give me
pointers
so I can do GC, reference counting or whatever I may choose, instead of
choosing for me.
Most devs in AAA development (not engines for AAA games but actual games
using that engine) doesn't want nor need that control. What they want is to
be able to do iterations as quickly as possible. Example:
C++ - iteration times (minimal) 40-50 seconds. Achieved frames per second
120
C# - iteration times (minimal) UNOBSERVABLE. Achieved frames per second 100.

What is the conclusion? The conclusion is that you as a user of their
product will not see the difference, because you cannot tell difference
between 120 and 100 frames per second. Your eyesight will not register it.
For them the difference is that instead of having paycheck every two year
they have paycheck every year. That is the difference and most studios will
go for paycheck every year, than every two year. As you would do too, I'm
pretty sure.
Post by g***@gmail.com
Are speedier compile times the killer feature that would make the
difference to make people prefer C++ to C# if they don't already? What
is?
Post by g***@gmail.com
Post by Thiago Macieira
No.
That is your opinion and your opinion only. From what I see in AAA industry
compile times are listed as a number 1 reason against C++ and in favor of
C#.
Post by g***@gmail.com
Post by Thiago Macieira
Like I said, build times are not the issue. You don't rebuild that often,
Building times are huge issue. We do rebuild very, very often.


Stop thinking that build times are the issue. They're not.
Please stop giving your opinion in a form that suggest that it is actual
fact. My experience differ vastly from yours and in my experience building
times are The killer of C++.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Sean Hunt
2015-01-05 11:15:46 UTC
Permalink
Post by Thiago Macieira
Stop thinking that build times are the issue. They're not.
Please stop giving your opinion in a form that suggest that it is actual
fact. My experience differ vastly from yours and in my experience building
times are The killer of C++.
Your contention, however, is that your experience in one field is
applicable to the language as a whole. It may well be that build times are
a major concern in the high-budget gaming world, but there are vast swaths
of users who are not in that industry niche. That doesn't mean that your
concerns about build times aren't valid, but it does mean that build times
are not necessarily the One True Problem that if solved would Save C++. C++
is popular in the embedded computing industry, for instance, and that is a
different competitive environment. C# is not even a competitor, because of
the language environment. As a result, even if build times are an issue,
they are not nearly so big of an issue.

There are always going to be niche environments where C++ is unsuitable. I
agree that it would be unfortunate if unnecessarily large build times are
one reason for them, but it is a feature, rather than a bug, that you can
do more at compile-time with C++ than with C#. Everything comes with
trade-offs.

Sean
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-05 13:24:49 UTC
Permalink
Post by a***@gmail.com
@Tiego Maciera
Post by g***@gmail.com
Post by Thiago Macieira
1) all our devs know C++, not C#. Why would we use a language we don't
know?
Well, that is just your case. In my personal experience out of 10 new devs
coming out of college 2 know C++ rest is spread between C# and Java
That's a hard problem to fix. There is a gap between what the industry
wants a developer to broadly know and what the industry wants a developer
to be able to use immediately. C++ might provide a better broad grounding
but if C# is in more popular use, the pressure can be more to equip
students for getting a job right now. It's hard to force colleges
to give people a better overall broad knowledge if it might be at the
expensive of them not getting a job.

.
Post by a***@gmail.com
Post by g***@gmail.com
Post by Thiago Macieira
2) is C# usable on embedded devices (bare metal)? On iOS?
No, but in many scenarios this isn't a big issue. Example: AAA games.
Post by g***@gmail.com
Post by Thiago Macieira
4) we *like* the control over everything that C++ gives us. Give me
pointers
so I can do GC, reference counting or whatever I may choose, instead of
choosing for me.
Most devs in AAA development (not engines for AAA games but actual games
using that engine) doesn't want nor need that control. What they want is to
C++ - iteration times (minimal) 40-50 seconds. Achieved frames per second
120
C# - iteration times (minimal) UNOBSERVABLE. Achieved frames per second 100.
What is the conclusion? The conclusion is that you as a user of their
product will not see the difference, because you cannot tell difference
between 120 and 100 frames per second. Your eyesight will not register it.
For them the difference is that instead of having paycheck every two year
they have paycheck every year. That is the difference and most studios will
go for paycheck every year, than every two year. As you would do too, I'm
pretty sure.
Post by g***@gmail.com
Are speedier compile times the killer feature that would make the
difference to make people prefer C++ to C# if they don't already? What
is?
Post by g***@gmail.com
Post by Thiago Macieira
No.
That is your opinion and your opinion only. From what I see in AAA
industry compile times are listed as a number 1 reason against C++ and in
favor of C#.
How can you be sure you are voicing a consensus opinion of game engine
users (as opposed to game engine writers) that compilation speed is the
number 1 reason against C++ in that niche?

My gut feeling is to agree with you I can easily imagine being wrong and
the issue being more about complexity. It's not hard for me to imagine that
game studios might prefer to group programmers like so:

1. Game Engine coders, that need flexibility and speed so use C++ and
therefore need to understand it, plus physics, math and whatever else.

2. Game engine users who can (possibly) can get away having
less understanding of all of these areas in group 1 because they use
abstractions that hide some of that and use a simpler language if the lower
level does all the heavy lifting.

I can also imagine games companies wanting to ship full blown development
tools with their game for mod'ers and not want to ship C++ compilers and
linkers as those tools but something more python like or whatever.

If a scenario like I've just made up is the developing world
order, compilation speed might not be the number problem after all, so C++
might not be the best fit there however fast it compiles.

But maybe C++ could be the best fit overall for other reasons I don't know.
Post by a***@gmail.com
Post by g***@gmail.com
Post by Thiago Macieira
Like I said, build times are not the issue. You don't rebuild that
often,
Building times are huge issue. We do rebuild very, very often.
Stop thinking that build times are the issue. They're not.
Please stop giving your opinion in a form that suggest that it is actual
fact. My experience differ vastly from yours and in my experience building
times are The killer of C++.
If compilation speed really is the number 1 problem shouldn't the game
industry be embracing distributed builds etc.as Thiago suggests. Do you use
such tools in your environment? If they are, why is it still a problem. If
not, why not? Why does your experience not match Thiago's? I might naively
assume QT and a big game or engine might be a comparable as "large"
projects?

I assume build times are a big issue for the industry (just not
particularly so for general app developers). But I don't know that it's so
big as to want to switch to C# - at least not yet - but if we're "only"
going to get a 30% speed improvement out of C++ Modules is that going to
be enough. The rate of header and template use would seem like we
might absorb that pretty quickly. It makes me wonder where more oomph is
going to come from then and what are reasonable expectations to have from
all this optimization being done/planned?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Dain Bray
2015-01-05 17:10:35 UTC
Permalink
For me build times are the #1 issue with C++.

I love the other features proposed for C++17(concepts, ranges etc), but
modules matters more.

Minimizing build times is possible in C++ with *much* effort, but even so
you cannot match the potential speedup modules would bring.
It isn't so much that fast builds are impossible in C++, as that the
effort required to achieve it is excessive for no good reason.
I do not enjoy spending 20-30% of my time programming worrying about how
to avoid increasing the build time. A fast enough build for me is not ~30
seconds, it is < 5 seconds.

For games we generally have a special build mode for fast iteration:
disable link time code gen, split up code into separate DLL's to minimize
link and enable hot reloading.
The idea is to get iteration builds down to under a few seconds, and to
modify the code while the game is running and hot swap the new code in.

My experience is that precompiled headers, if used properly, make a
massive difference in compilation speed. Unfortunately they are fragile &
tedious.
* Example*: On MSVC you can only have one precompiled header per project,
and you cannot even share the output with other projects(without hacking
away at MSBuild).

Yes game engines use distributed builds(Incredibuild mostly).
This does not apply to fast builds, as Incredibuild is only relevant when
compiling more source files than the # of cores on my machine, which is
generally not the case when iterating.

Having to constantly worry about how to minimize the headers being
included, having to always forward declare everything etc is a waste of
time. Not all projects do these things, but if you want < 5 second
rebuilds, C++ forces this down your throat.

* Regarding engine vs game code.* Yes you *can* use two separate
languages, but now you have an interop layer. Interop is not fun. Unreal 4
ditched UnrealScript for this very reason.

The primary reason games have historically used "scripting" languages was
because they offered fast (instant) builds.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 23:13:07 UTC
Permalink
Post by a***@gmail.com
@Tiego Maciera
You asked my opinion about Qt. That included Qt's goals and purpose. You can't
insert the AAA games as a context there. (I don't even know what an AAA game
is; I assume it has nothing to do with car repair, but that's the only "AAA" I
know of).
Post by a***@gmail.com
Post by g***@gmail.com
Post by Thiago Macieira
1) all our devs know C++, not C#. Why would we use a language we don't
know?
Well, that is just your case. In my personal experience out of 10 new devs
coming out of college 2 know C++ rest is spread between C# and Java.
That much is true, but then we have to judge quantity vs quality.

And we have in the past hired junior engineers who knew Java and no C++ to
work on C++. If the person is good, the language is not the problem. We can
teach them C++ and teach them to unlearn some of the bad practices they may
have come with (e.g., networking implies multithreading).
Post by a***@gmail.com
Post by g***@gmail.com
Post by Thiago Macieira
2) is C# usable on embedded devices (bare metal)? On iOS?
No, but in many scenarios this isn't a big issue. Example: AAA games.
It is a big issue for us, so if there's no good compiler implementation for
that language in the target platforms we care, the language is ruled out.

Again, note that your question was about Qt, so the answer is about Qt.
Post by a***@gmail.com
Post by g***@gmail.com
Post by Thiago Macieira
4) we *like* the control over everything that C++ gives us. Give me
pointers
so I can do GC, reference counting or whatever I may choose, instead of
choosing for me.
Most devs in AAA development (not engines for AAA games but actual games
using that engine) doesn't want nor need that control. What they want is to
C++ - iteration times (minimal) 40-50 seconds. Achieved frames per second
120
C# - iteration times (minimal) UNOBSERVABLE. Achieved frames per second 100.
I totally understand tradeoffs. We make them all the time -- reference counting
vs properly controlling copies, for example (Qt chooses the former, for
simplicity, but there's a cost associated).
Post by a***@gmail.com
Post by g***@gmail.com
Are speedier compile times the killer feature that would make the
difference to make people prefer C++ to C# if they don't already? What
is?
Post by g***@gmail.com
Post by Thiago Macieira
No.
That is your opinion and your opinion only. From what I see in AAA industry
compile times are listed as a number 1 reason against C++ and in favor of
C#.
Yes, it is my opinion. But you asked for my opinion.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-05 16:18:33 UTC
Permalink
@Sean Hunt
Surely you not considering a Triple A game development as a niche? It is
probably (cannot be sure now, but my gut feeling tells me) the most
profitable IT industry.
If God forbids C++ loses that field, C++ will be on very slippery slope to
actually compete with C#. Because if not use C++ for speed why else would I
want to use it?
Visual Studio is already rewritten in C#, 3DMax - again, rewritten in C#
and other big players if you care to search web for proves.

Gentlemen, if you think that C++ will survive as a main language based on
it being main language in embedded environments, then you are simply
fooling yourself.
To everyday programmer, embedded environments are not important and very
unattractive to work in. Everyday programmer will definitely not choose C++
as his main language if that will be the case.

Wake up call gentlemen! If we don't do something about C++ being
competitive on this front, C# is taking over and there mustn't be any doubt
about it!
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-05 23:19:22 UTC
Permalink
Post by a***@gmail.com
@Sean Hunt
Surely you not considering a Triple A game development as a niche? It is
probably (cannot be sure now, but my gut feeling tells me) the most
profitable IT industry.
If God forbids C++ loses that field, C++ will be on very slippery slope to
actually compete with C#. Because if not use C++ for speed why else would I
want to use it?
Visual Studio is already rewritten in C#, 3DMax - again, rewritten in C#
and other big players if you care to search web for proves.
Gentlemen, if you think that C++ will survive as a main language based on
it being main language in embedded environments, then you are simply
fooling yourself.
To everyday programmer, embedded environments are not important and very
unattractive to work in. Everyday programmer will definitely not choose C++
as his main language if that will be the case.
Wake up call gentlemen! If we don't do something about C++ being
competitive on this front, C# is taking over and there mustn't be any doubt
about it!
I'll just say this: I think you're wrong.

Not totally wrong, you have some good points. And you're missing a lot of why
C# may be more attractive to some segments than C++ which have nothing to do
with the build times. A more complete stack comes to mind (XML parsing in the
Standard Library?).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-06 03:19:58 UTC
Permalink
Post by a***@gmail.com
Post by a***@gmail.com
@Sean Hunt
Surely you not considering a Triple A game development as a niche? It is
probably (cannot be sure now, but my gut feeling tells me) the most
profitable IT industry.
If God forbids C++ loses that field, C++ will be on very slippery slope
to
Post by a***@gmail.com
actually compete with C#. Because if not use C++ for speed why else
would I
Post by a***@gmail.com
want to use it?
Visual Studio is already rewritten in C#, 3DMax - again, rewritten in C#
and other big players if you care to search web for proves.
Gentlemen, if you think that C++ will survive as a main language based
on
Post by a***@gmail.com
it being main language in embedded environments, then you are simply
fooling yourself.
To everyday programmer, embedded environments are not important and very
unattractive to work in. Everyday programmer will definitely not choose
C++
Post by a***@gmail.com
as his main language if that will be the case.
Wake up call gentlemen! If we don't do something about C++ being
competitive on this front, C# is taking over and there mustn't be any
doubt
Post by a***@gmail.com
about it!
I'll just say this: I think you're wrong.
Not totally wrong, you have some good points. And you're missing a lot of why
C# may be more attractive to some segments than C++ which have nothing to do
with the build times. A more complete stack comes to mind (XML parsing in the
Standard Library?).
This thread gives an insight into some of the C++ vs C# debate in the
context of Unreal game that the OP mentioned.
I think everyone should read it if they have a lot of time on your hands.
Mainly just because it's too funny in a sick way!
But it does offer a (crazy) insight into the perception of C++ out there
and how it's compared to C# and other languages.
*https://forums.unrealengine.*com/showthread.php?2574-Why-C-for-Unreal-4/
<https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4/>

It's actually embarrassing to read if you are C++ developer as It does
demonstrate how enthusiasm for one language can make one
lose appreciation for other peoples experiences.
The "I'm a C programmer" videos are a real treat though, they are just too
funny and on the mark.
Having worked in both C# and C++ I think both "sides" are correct in
that debate, even though I prefer C++.

But it'd be nice if something constructive could come out of this thread
beyond the laughs though.

I do think the OP is correct that C++ can't afford to lose ground to
others languages in game development. It is a big sector IMO.
It would be quite reassuring and interesting for many to have some experts
in this area try to quantify what can be improved upon in the area of build
times and when we might actually see that happening.
It might also offer an insight as to if more might need to be done to meet
expectations.

I do appreciate the voluntary involvement here of people by the way.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Nathan Ernst
2015-01-06 04:07:18 UTC
Permalink
I know we're getting off topic in a hurry here, but in my experience, a lot
of the general problems with C++ compile times tend to come down to I/O.
Either improper include guards or unnecessary includes (a la the example of
the Boost Unit Test "catch all" include) are often suspect. Always
(especially in a header) include the most specific header to get what you
need and nothing more. A lot can be done to reduce compilation time by
understanding, reducing, and minimizing dependencies, especially among
headers. Judicious usage of precompiled headers can go a long way as well
(when used correctly ( - don't include your local headers in the PCH) -
PCHs worked really well for me on Windows, I had sort of mixed results
under GCC).

Also, native parallelization of compilation (from within the IDE) has only
relatively recently been supported under MSVC (undocumented support I think
started in VC8, maybe VC9), but I think it's officially documented and
supported around VC10 or VC11. On *nix, you need to have an appropriate
makefile (that allows independent targets to be built in parallel) or
equivalent set up, but you should be able to use the -j option to make to
specify parallelization to some extent (I usually use a param 2x the number
of logical CPUs I have available). The default is a single process
compilation, so it will not take advantage of 4 cores (you need to make
sure you have your dependencies in order, as well, or incremental builds
are a pain).

I'm not aware of any standard build systems on windows or *nix that
automatically parallelizes. So, to go from a single core to a 4 core system
and magically expect your build to run roughly 4x faster just won't work.

There are other techniques, as well, that can reduce compilation (and link
times), such as minimizing inline code in headers and using the pointer to
impl technique, and then coupled with shared/dynamically linked libraries
can significantly reduce compilation/link times (may not be ideal in terms
of performance, but there's probably tricks that could be used to toggle
the approach on/off for shear performance). Using a combination of the
above techniques, I previously reduced a clean compile and link cycle for
Windows DLLs from 16 hours to about 30-40 minutes. That code base comprised
roughly 500 KLOC internal, with dependencies on Boost, ACE, RogueWave and a
few other internal libraries. Granted, a comparable C# library that
provided about 2/3s of the functionality was written in probably 1/4 of the
amount of code with no external dependencies and compiled/linked in less
than 5 minutes.

Regards,
Nate
Post by g***@gmail.com
Post by a***@gmail.com
Post by a***@gmail.com
@Sean Hunt
Surely you not considering a Triple A game development as a niche? It
is
Post by a***@gmail.com
probably (cannot be sure now, but my gut feeling tells me) the most
profitable IT industry.
If God forbids C++ loses that field, C++ will be on very slippery slope
to
Post by a***@gmail.com
actually compete with C#. Because if not use C++ for speed why else
would I
Post by a***@gmail.com
want to use it?
Visual Studio is already rewritten in C#, 3DMax - again, rewritten in
C#
Post by a***@gmail.com
and other big players if you care to search web for proves.
Gentlemen, if you think that C++ will survive as a main language based
on
Post by a***@gmail.com
it being main language in embedded environments, then you are simply
fooling yourself.
To everyday programmer, embedded environments are not important and
very
Post by a***@gmail.com
unattractive to work in. Everyday programmer will definitely not choose
C++
Post by a***@gmail.com
as his main language if that will be the case.
Wake up call gentlemen! If we don't do something about C++ being
competitive on this front, C# is taking over and there mustn't be any
doubt
Post by a***@gmail.com
about it!
I'll just say this: I think you're wrong.
Not totally wrong, you have some good points. And you're missing a lot of why
C# may be more attractive to some segments than C++ which have nothing to do
with the build times. A more complete stack comes to mind (XML parsing in the
Standard Library?).
This thread gives an insight into some of the C++ vs C# debate in the
context of Unreal game that the OP mentioned.
I think everyone should read it if they have a lot of time on your hands.
Mainly just because it's too funny in a sick way!
But it does offer a (crazy) insight into the perception of C++ out there
and how it's compared to C# and other languages.
*https://forums.unrealengine.*com/showthread.php?2574-Why-C-for-Unreal-4/
<https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4/>
It's actually embarrassing to read if you are C++ developer as It does
demonstrate how enthusiasm for one language can make one
lose appreciation for other peoples experiences.
The "I'm a C programmer" videos are a real treat though, they are just too
funny and on the mark.
Having worked in both C# and C++ I think both "sides" are correct in
that debate, even though I prefer C++.
But it'd be nice if something constructive could come out of this thread
beyond the laughs though.
I do think the OP is correct that C++ can't afford to lose ground to
others languages in game development. It is a big sector IMO.
It would be quite reassuring and interesting for many to have some experts
in this area try to quantify what can be improved upon in the area of build
times and when we might actually see that happening.
It might also offer an insight as to if more might need to be done to meet
expectations.
I do appreciate the voluntary involvement here of people by the way.
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
http://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-06 05:14:55 UTC
Permalink
Post by Nathan Ernst
I know we're getting off topic in a hurry here, but in my experience, a
lot of the general problems with C++ compile times tend to come down to
I/O. Either improper include guards or unnecessary includes (a la the
example of the Boost Unit Test "catch all" include) are often suspect.
Always (especially in a header) include the most specific header to get
what you need and nothing more. A lot can be done to reduce compilation
time by understanding, reducing, and minimizing dependencies, especially
among headers. Judicious usage of precompiled headers can go a long way as
well (when used correctly ( - don't include your local headers in the PCH)
- PCHs worked really well for me on Windows, I had sort of mixed results
under GCC).
Also, native parallelization of compilation (from within the IDE) has only
relatively recently been supported under MSVC (undocumented support I think
started in VC8, maybe VC9), but I think it's officially documented and
supported around VC10 or VC11. On *nix, you need to have an appropriate
makefile (that allows independent targets to be built in parallel) or
equivalent set up, but you should be able to use the -j option to make to
specify parallelization to some extent (I usually use a param 2x the number
of logical CPUs I have available). The default is a single process
compilation, so it will not take advantage of 4 cores (you need to make
sure you have your dependencies in order, as well, or incremental builds
are a pain).
I'm not aware of any standard build systems on windows or *nix that
automatically parallelizes. So, to go from a single core to a 4 core system
and magically expect your build to run roughly 4x faster just won't work.
There are other techniques, as well, that can reduce compilation (and link
times), such as minimizing inline code in headers and using the pointer to
impl technique, and then coupled with shared/dynamically linked libraries
can significantly reduce compilation/link times (may not be ideal in terms
of performance, but there's probably tricks that could be used to toggle
the approach on/off for shear performance). Using a combination of the
above techniques, I previously reduced a clean compile and link cycle for
Windows DLLs from 16 hours to about 30-40 minutes. That code base comprised
roughly 500 KLOC internal, with dependencies on Boost, ACE, RogueWave and a
few other internal libraries. Granted, a comparable C# library that
provided about 2/3s of the functionality was written in probably 1/4 of the
amount of code with no external dependencies and compiled/linked in less
than 5 minutes.
Regards,
Nate
It would be nice to be able to have a switch on the compiler that basically
forces an analysis and reports what could be done to improve build times.

e.g. the compiler could analyse all the classes and macros etc.that were
introduced by an include and determine what was used and report things like
"#include <iostream>' was not necessary" or perhaps "if main.cpp used these
forward declarations 'xxx', the #include of <iostream> would not be
necessary".

Quite how viable that is I don't know. Maybe there is a group of
build performance warnings that could be cheap to have on by default that
would encourage people to fix performance problems than be unaware or do
nothing about them, I don't know?

FWIW I timed how long it takes to build llvm and clang from trunk in
release mode on my intel 2670QM Windows based machine. It takes about 35
minutes. I have no SSD but task manager reports all 8 processors maxed out
at 100% using ninja suggesting an CPU bound build. But I haven't looked at
it deeply since it's not a problem for me but maybe is for others. Physical
memory was about half to two thirds used, so from what I can tell not a
factor.

I suspect most projects are not as well written as LLVM/clang and many
people may not use tools that parallel build well by default like ninja
does (I used to have a lot of parallel build reliability problems with make
in the past) so I can imagine other projects taking way way longer.

Maybe if more tools existed to analyse build performance or compilers could
be made to report more on the subject and suggested what action to
take, then maybe more library writers would use them more and we'd see
accumulative improvements to build times as one optimizes one's owns code
for build performance and third party libraries like boost do the same?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
n***@gmail.com
2015-01-07 23:39:59 UTC
Permalink
Post by a***@gmail.com
@Sean Hunt
Surely you not considering a Triple A game development as a niche? It is
probably (cannot be sure now, but my gut feeling tells me) the most
profitable IT industry.
If God forbids C++ loses that field, C++ will be on very slippery slope to
actually compete with C#. Because if not use C++ for speed why else would I
want to use it?
Visual Studio is already rewritten in C#, 3DMax - again, rewritten in C#
and other big players if you care to search web for proves.
Please don't spread falsehoods. 3dsmax has not be rewritten in c#. It is
still the same crappy mix of C and 1980's c++.
Post by a***@gmail.com
Gentlemen, if you think that C++ will survive as a main language based on
it being main language in embedded environments, then you are simply
fooling yourself.
To everyday programmer, embedded environments are not important and very
unattractive to work in. Everyday programmer will definitely not choose C++
as his main language if that will be the case.
Wake up call gentlemen! If we don't do something about C++ being
competitive on this front, C# is taking over and there mustn't be any doubt
about it!
I don't see the cause for alarm, c++ is getting more attention than it has
in a long time, and a lot of big companies are investing heavily in it's
future.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-06 10:59:41 UTC
Permalink
@Tiego Maciera
I don't recall asking you specifically about QT.
The issue I've risen is appalling compilation times compared to C#. You
seem to be oblivious to this fact and simply ignore it or threat is as "not
an issue". I don't think that is the right attitude
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-06 17:04:40 UTC
Permalink
Post by a***@gmail.com
@Tiego Maciera
I don't recall asking you specifically about QT.
No, you didn't. It was someone else with no name and just a "@gmail.com" email
address that doesn't spell out a name, so I'm sorry I mistook you two. In any
case, the question I answered *specifically* asked about Qt, so the answer is
about Qt's context only, even if you didn't ask the question.

***@gmail.com asked on <e3c52fdb-2f49-4b21-9ccf-***@isocpp.org>:

"if you could click your fingers and magically turn all your code in QT from
C++ to C# with zero compatibility issues for you and your customers in
order to get the near instant compile times that C# gives, would you do it?"

That phrased the whole answer in terms of Qt's point of view.
Post by a***@gmail.com
The issue I've risen is appalling compilation times compared to C#. You
seem to be oblivious to this fact and simply ignore it or threat is as "not
an issue". I don't think that is the right attitude
I'm not oblivious to the fact. I'm saying that it's neither as big a problem
as you seem to make of it nor is fixing it the holy grail of solutions.
Moreover, I am also adding to the discussion that most of the compilation time
is spent in optimising code and that can't change.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-06 11:01:34 UTC
Permalink
@Vicente J. Botet Escriba
I use Visual Studio 2013.
Libraries, we use Boost, Intel tbb mainly + those included in Unreal Engine
4.
The game engine we use is Unreal Engine 4.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-06 17:58:02 UTC
Permalink
@Thiago

"most of the compilation time is spent in optimising code and that can't
change" - again, you delivering your opinion as a fact. Please stop doing
it. You cannot be certain that in the future optimizing code can be done
more efficiently with better tools. You simply cannot know that.

And sure, improving just compilation times is not a Holy Grail. But it is a
big, big issue, and one of *main* points that C# is chosen over C++.
And now I will give my opinion:
If God forbids C++ loses AAA gaming industry to C#, there will be no reason
to use C++ for everyday programmers, which I believe form a majority of
programmers. I am very everyday programmer I'm glad to say. I program for
living, in order to support my family. I am choosing best tools for the
job, not the tools I love and would like to use all the time. If with C# I
can have paycheck twice as often than if I'd used C++, then I'm sorry, I do
not own C++ anything. I'm choosing C#. Best tool for the job. And I believe
most of everyday programmers thinks along similar lines.

But there is also other aspect of this whole C++ vs C# compilation times
debate: Managers.
Which option will most of them go with, you think if you present to them:
a) C++ hard to learn, difficult to use, lots of time *wasted* on
compilation times, results compared to C# unobservable.
b) C# easy/(ier) to learn, easy/(ier) to use, very little time wasted on
compilation times, lots of people know it so it is much easier to replace
employee. Instead of having our products being released every two year
cycle, we can have them released every year.

Which option do you think most managers will go with?

And as a side note, not directly to your answer but someone else said it,
and I agree with him wholeheartedly:

Dear C++ committee, what's wrong with you? How is having different ways of
initializing things easier to learn? If you want to make language uniform
make it uniform - everyone agrees - but what you doing is, you are saying
one thing "Let's make the language more uniform", and you are doing
complete opposite: You introduce yet another method of initializing!!! So
instead of one, newcomers have to learn two!!!

How is that easier to teach/learn?!?!
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Matthew Woehlke
2015-01-06 18:36:56 UTC
Permalink
Post by a***@gmail.com
If God forbids C++ loses AAA gaming industry to C#, there will be no reason
to use C++ for everyday programmers, which I believe form a majority of
programmers.
I find it interesting that you equate "the AAA game industry" (whatever
that is) with "people that write software for a living". I assure you,
there are plenty of programmers in other industries.

I've worked in a couple "industries", now... High performance networking
(think banking and stock exchanges), which hesitates to use even C++ due
to performance concerns (C is preferred) or else uses primarily Java.
Scientific uses a combination of C++, Python and MatLab. In neither one
have I seen C# used to any significant degree. Then of course there is
web development where Python and JavaScript rule.

In my experience, either end performance is important, and therefore
C/C++ are used, or rapid development is important, and therefore Python
or MatLab is used. C# seems to me to be in a sort of no-man's land
between the two.

It's also my experience that one's perspective is strongly shaped by
one's employment. In particular, I've seen very little C# on non-Windows
machines... and my entire working career has been in industries where at
least wide server-class support is crucial. I *briefly* ran Windows
during my first job, but have been using primarily Linux at work for
almost a decade, and *exclusively* Linux at home for nearly as long. In
*my* world, Windows barely exists, and it would hardly (directly) affect
me if tomorrow every instance of Windows in existence suddenly stopped
working. It wouldn't directly affect me *at all* if C# were to cease to
exist, unlike C++, Python, etc.

For that matter, I'm sure I could find people that are fully convinced
that the world revolves around Fortran, or COBOL, or even Visual
Basic... and *I* wouldn't discount them out of hand.

The point is, you own *personal* view does not reflect reality as a
whole, so please stop acting as if it does.
Post by a***@gmail.com
I am very everyday programmer I'm glad to say. I program for
living, in order to support my family.
So do I. In C++ (and Python, and JavaScript). I haven't even *looked* at
a line of C# in years.
Post by a***@gmail.com
If with C# I can have paycheck twice as often than if I'd used C++
You really get paid based on number of lines of code completed, or some
similar metric? That's... unusual, in my experience. I very much doubt
I'd want to work at such a job, as there is usually a direct correlation
between code quality and how long it takes to produce that code.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-06 21:29:44 UTC
Permalink
Hi

I'm not the OP or who you are aiming this post at, but I find it surprising.
Post by a***@gmail.com
Post by a***@gmail.com
If God forbids C++ loses AAA gaming industry to C#, there will be no
reason
Post by a***@gmail.com
to use C++ for everyday programmers, which I believe form a majority of
programmers.
I find it interesting that you equate "the AAA game industry" (whatever
that is) with "people that write software for a living". I assure you,
there are plenty of programmers in other industries.
Agreed, but there are lots of big sectors. The point the OP makes is
C++ can't afford to concede a big one like gaming. I agree with that and
it's not just gaming.
The OP perhaps might want to make that point in little less aggressively as
it sounded to me, as if it's the C++ Committees intent or your desire
to concede a sector but we also shouldn't sound so blasé about the
competition C# or any language provides to C++ or that is isn't happening.

I think this post sounded like that, perhaps just because it isn't
happening in your experience.
Post by a***@gmail.com
I've worked in a couple "industries", now... High performance networking
(think banking and stock exchanges), which hesitates to use even C++ due
to performance concerns (C is preferred) or else uses primarily Java.
That sentence there reads a little like "banks are worried about the
performance of C++ so use C or Java.".
I assume you that's not what you mean as I'm not aware Java has performance
Post by a***@gmail.com
= C++ overall. But maybe you mean performance in a different way to flat
out speed of runtime execution.
Post by a***@gmail.com
Scientific uses a combination of C++, Python and MatLab. In neither one
have I seen C# used to any significant degree. Then of course there is
web development where Python and JavaScript rule.
In my experience, either end performance is important, and therefore
C/C++ are used, or rapid development is important, and therefore Python
or MatLab is used. C# seems to me to be in a sort of no-man's land
between the two.
That's NOT remotely my experience (not to say you are wrong,we can both be
"right" in our own worlds).
But in my experience many many companies who write line of business or
commercial apps used C++ but started to shift from C++ because C++ was
getting sorely neglected for years. When C# came out it was seen
as simpler because it had an amazing IDE experience compared to C++, some
good libraries bundled, especially GUI and compile times are a
significantly better. That does work well for rapid development, as does
not having people spend forever scratching their heads trying to work out
template errors or fixing bugs because they use templates but shouldn't
because they don't grok them properly.

All that has propelled C# on a trajectory where it's considered in many
companies to be a better fit than C++, because it all added up to feeling
simpler and actually being faster to use. That then puts pressure on other
companies to follow suit eve if they don't want to.

A lot of companies have significant investments in C++ though but they do
waste a lot of money and time writing interop code because they have dual
investments in both C++ and C# now because they wanted faster/easier
development for new projects and to get the "fancy" gui libraries / tools /
IDE's so they are now stuck in both camps and would like a way to just be
in one.

I'm not talking about the gaming sector here, but I suspect some parts of
the gaming sector got caught in this trap too for various reasons. This
story has not played out on other platforms so much AFAIK as it's a mainly
Windows thing. But Windows is a big sector.

But now the situation has somewhat changed IMO. MS has made epic fails with
Windows 8 and it's store and mobile has come into the picture big time
where performance is crucial and a big market.

Also and possibly because of that, C++ has come out of it's neglect
cycle. MS has embarked on some big productivity changes for C++ in the IDE
and clang has put some great momentum in opening up opportunities for C++
and it's tooling. The IDE experience for C++ has really starting to move to
getting on a par with C# or at least acceptable and productive. In that
time C# and it's libraries have got more complex and competition like QT
has got better.

This means that today C++ isn't the laggard it was compared to C# and for a
lot of companies, the desire to shift to C# isn't theoretically nearly as
strong.
But C# still has momentum and convincing managers to use C++ over C#
with C#'s perceived simplicity and C++'s perceived complexity is still an
issue and it takes time convince them things have changed. It takes time to
say hey, why write all this interop rubbish etc. and hey look at the
opportunities C++ opens up and hey C++ is nearly as east as C# and the
complexity difference is worth while for all the opportunities and power
you gain and it's easier to use than ever before.

But changing peoples minds comes after changing the technologies and C++ is
only part way through it's technological recovery. We shouldn't be blasé to
that or the extent of the threat that still exists.
Post by a***@gmail.com
It's also my experience that one's perspective is strongly shaped by
one's employment. In particular, I've seen very little C# on non-Windows
machines... and my entire working career has been in industries where at
least wide server-class support is crucial. I *briefly* ran Windows
during my first job, but have been using primarily Linux at work for
almost a decade, and *exclusively* Linux at home for nearly as long. In
*my* world, Windows barely exists, and it would hardly (directly) affect
me if tomorrow every instance of Windows in existence suddenly stopped
working. It wouldn't directly affect me *at all* if C# were to cease to
exist, unlike C++, Python, etc.
I'm sure you are correct. But for many people the opposite is also true.
Post by a***@gmail.com
For that matter, I'm sure I could find people that are fully convinced
that the world revolves around Fortran, or COBOL, or even Visual
Basic... and *I* wouldn't discount them out of hand.
The point is, you own *personal* view does not reflect reality as a
whole, so please stop acting as if it does.
Agreed. I think the OP might share the same view.
Post by a***@gmail.com
Post by a***@gmail.com
I am very everyday programmer I'm glad to say. I program for
living, in order to support my family.
So do I. In C++ (and Python, and JavaScript). I haven't even *looked* at
a line of C# in years.
Post by a***@gmail.com
If with C# I can have paycheck twice as often than if I'd used C++
You really get paid based on number of lines of code completed, or some
similar metric? That's... unusual, in my experience. I very much doubt
I'd want to work at such a job, as there is usually a direct correlation
between code quality and how long it takes to produce that code.
I don't think we should go down this road. The OP wants assurance that C++
is going to deliver certain metrics and Modules facilities one of those -
the compllation performance metric that C# has beat.

I think the discussion should be about will Modules likely do that and what
else can be done if it doesn't.
I'd also like to see some assurance that Modules isn't going to start a
whole new incompatibility wave.

The C++ vs C# debate is somewhat relevant because C# does have compilation
performance beat.

Also it's all for nothing if we don't take see C# as a serious competitor
to C++ as it is in my experience even if C#'s reason to exist is starting
to wane.
People are worried because they have a lot of experience, interest and real
investment tied up in C++ and want to see it is being preserved.
I think it's hard to get that feeling if we sound all blasé which I think
some of the comments have sounded.

I think that now C++ is developing again and the landscape has changed such
that many of C#'s advantages are starting to disappear as C++ gains those
same advantages (like IDE and tooling support) it's time and appropriate to
start talking up C++ against C# and dispel what is hopefully now or soon to
be the myth that C# is a better fit for any app than C++ and that C++ is
only about performance. If things go as they could, the only place where C#
is a better choice than C++ is if it does what you want and you already
have a bunch of C# developers. But that's still a big challenge while a lot
of people are learning C# at school because it is less complex than C++ and
compiles faster.

I think we should acknowledge that is a challenge and not be or sound blasé
about it.

As an aside, I'd generally like to see companies stop using language as a
lock in and just go about developing new markets and let programmers use
the languages they like and just help the programmer use whatever language
they like. I can't tell if that's happening or not. Companies seem to stop
then start on dow that road and switch positions.

Anyway: Modules, how fast can we compile, how source compatible can we stay?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Matthew Woehlke
2015-01-06 21:53:56 UTC
Permalink
Post by g***@gmail.com
Post by Matthew Woehlke
I've worked in a couple "industries", now... High performance networking
(think banking and stock exchanges), which hesitates to use even C++ due
to performance concerns (C is preferred) or else uses primarily Java.
That sentence there reads a little like "banks are worried about the
performance of C++ so use C or Java.".
I assume you that's not what you mean as I'm not aware Java has performance
Post by Matthew Woehlke
= C++ overall.
Right. The "or else" is in reference to "hesitates to use even C++ due
to performance concerns"... i.e. if performance matters, prefer C, else
prefer Java. (This was a while ago; maybe C# has taken off a bit more,
but in my experience C# competes with Java more than with C++.)
Post by g***@gmail.com
Post by Matthew Woehlke
In my experience, either end performance is important, and therefore
C/C++ are used, or rapid development is important, and therefore Python
or MatLab is used.
That's NOT remotely my experience (not to say you are wrong,we can both be
"right" in our own worlds).
Not surprising. The above refers specifically to the scientific /
computer vision sectors (the mention of MatLab should tip you off ;-)).
That said, I personally would still, in general, reach for Python over
C# (for one, it's more portable).
Post by g***@gmail.com
The C++ vs C# debate is somewhat relevant because C# does have compilation
performance beat.
Sure. It's not far from an interpreted language. If you want that,
what's wrong with Python? ;-)

As Thiago mentioned, the real issue with compile speed is that it's not
going to get magically better as long as you're... actually compiling.
C# can be fast because a lot happens at run time (or not at all, i.e.
optimization) compared to what happens when you compile C++.

Maybe what we need is rather a C++ virtual machine, like we have for
Java and C#.

Actually... for testing, I can see that being a totally awesome idea...
fast testing cycles (at the cost of slower overall performance) during
development with the ability to compile and optimize for "final" versions.

There's nothing in the standard AFAIK that prevents us having this
today... just that no one has written such an environment.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Jim Porter
2015-01-06 22:49:45 UTC
Permalink
Post by Matthew Woehlke
Maybe what we need is rather a C++ virtual machine, like we have for
Java and C#.
Actually... for testing, I can see that being a totally awesome idea...
fast testing cycles (at the cost of slower overall performance) during
development with the ability to compile and optimize for "final" versions.
There's nothing in the standard AFAIK that prevents us having this
today... just that no one has written such an environment.
This sounds an awful lot like CERN's "cling" interpreter, which is an
interactive C++ interpreter built on clang.

- Jim
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-06 23:32:10 UTC
Permalink
Post by Matthew Woehlke
Right. The "or else" is in reference to "hesitates to use even C++ due
to performance concerns"... i.e. if performance matters, prefer C, else
prefer Java. (This was a while ago; maybe C# has taken off a bit more,
but in my experience C# competes with Java more than with C++.)
I don't choose to use C but I can similarly see why people do, like I see
why people use C#.
Your statement demonstrates what I was talking about in my previous post
about perceptions.
C isn't faster runtime wise than C++, it can't be - for
most circumstances - as it's roughly a subset of C++.
C is just simpler to learn compared to C++ in the way that a bicycle is
simpler than a motor bike.
There's a lot less buttons to mess with but if you want to motor you might
be stuck unless you can pedal fast or are on a nice hill lol
But C might stop some from ugly crashes where people get overwhelmed by all
the buttons in C++.

C used well stops a lot of mess that occurs when C++ is used badly. But it
cuts both ways and depends on how disciplined you are in either case and
your circumstances.

When I used C for my purposes I spent a lot of time wrestling with pointers
and memory allocation concerns and bugs from that; and -> everywhere, even
though I grok pointers well.
When I use C++, I avoid all that, but I have to endure template errors.
But I can be disciplined to just use them and not write them much and soon
I won't have the errors to deal with thanks to Concepts. But not everyone
is disciplined and can spend hours writing them to bad effect and still
never learn enough to master them. Like I used to.
If I use C#, I get amazing productivity but get bored out of my mind and
frustrated with excess use of attributes and reflection.

But now C++ has to more productive again and the tools that go with it,
it's as productive or more so than C# for a lot of cases.
if that continues, I can't imagine why anyone would continue to use C#
except for the libraries and staff availability and compile time concerns.

I can still see why we aren't quite yet there yet and why people who have
built up a lot of experience in C# and don't know C++ might want to stay in
C# land.
I don't think we should be complacent though that it might still not happen
or that C# is a credible threat.

C++ does need to stop getting uglier though, the complexity and two ways of
doing things feeling like uniform initialisation really irks me.
I assume that was necessary because C++ is a living language that had to
wrestle with compatibility but I just wish it wasn't so. Developments like
that make people look at C++ badly. How much baggage can you acquire before
you can't carry it. But all real languages are affected by this so I remain
hopeful.
Post by Matthew Woehlke
Post by g***@gmail.com
That's NOT remotely my experience (not to say you are wrong,we can both
be
Post by g***@gmail.com
"right" in our own worlds).
Not surprising. The above refers specifically to the scientific /
computer vision sectors (the mention of MatLab should tip you off ;-)).
That said, I personally would still, in general, reach for Python over
C# (for one, it's more portable).
Post by g***@gmail.com
The C++ vs C# debate is somewhat relevant because C# does have
compilation
Post by g***@gmail.com
performance beat.
Sure. It's not far from an interpreted language. If you want that,
what's wrong with Python? ;-)
As Thiago mentioned, the real issue with compile speed is that it's not
going to get magically better as long as you're... actually compiling.
C# can be fast because a lot happens at run time (or not at all, i.e.
optimization) compared to what happens when you compile C++.
Maybe what we need is rather a C++ virtual machine, like we have for
Java and C#.
Actually... for testing, I can see that being a totally awesome idea...
fast testing cycles (at the cost of slower overall performance) during
development with the ability to compile and optimize for "final" versions.
There's nothing in the standard AFAIK that prevents us having this
today... just that no one has written such an environment.
--
Matthew
C# is on the move across platforms and going native too AFAIKT. I
wouldn't pick C# still unless the libraries dedicated that.
As for python, I wouldn't put it on the same level as C++ and I don't
prefer it. In fact I've mostly forgotten it after my small scale use. I
would think more people would compare C# and C++ than python and that's
where I see most of the job replacement and competition.

When I see people hiring for C# they like a C++ background. When they hire
for C++, they might accept C# in some instances. I don't see python in the
mix on that front much. I do here good things about python though. It never
gets the dis that C++ does but then it's not as popular to earn that. But
C# has had a lot o the momentum in recent times at least on Windows. How
good it not when C++ was neglected for such a long time there.

After writing that last sentence I just checked where python actually was
on the tiobe index.and I noticed the new Jan report has just this second
appeared. I see C++ has halted it's apparent massive drops though it only
reflects a month anyway. It was down 2.16% in December and now it's down
.86% in Jan. God only knows what any of that really means but slightly
interesting.

I see JavaScript is the attention grabber. I'm keen to see more C++ in web
as I'm keen to see it stay in games. That appears to be happening with cool
JSON libraries and web servers appearing and all that in C++. Cool stuff.
It just needs to compile faster! :)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Nadav Har'El
2015-01-06 23:56:02 UTC
Permalink
On Wed, Jan 7, 2015 at 1:32 AM, <***@gmail.com> wrote:

C is just simpler to learn compared to C++ in the way that a bicycle is
Post by g***@gmail.com
simpler than a motor bike.
No, C is simpler to learn compared to C++ in the way that a bicycle is
simpler than a space shuttle :-)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 00:11:04 UTC
Permalink
Post by g***@gmail.com
C is just simpler to learn compared to C++ in the way that a bicycle is
Post by g***@gmail.com
simpler than a motor bike.
No, C is simpler to learn compared to C++ in the way that a bicycle is
simpler than a space shuttle :-)
Good point. lol I stand corrected! :)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Matthew Woehlke
2015-01-07 15:36:52 UTC
Permalink
Post by g***@gmail.com
Post by Matthew Woehlke
Right. The "or else" is in reference to "hesitates to use even C++ due
to performance concerns"... i.e. if performance matters, prefer C, else
prefer Java. (This was a while ago; maybe C# has taken off a bit more,
but in my experience C# competes with Java more than with C++.)
Your statement demonstrates what I was talking about in my previous post
about perceptions.
C isn't faster runtime wise than C++, it can't be - for
most circumstances - as it's roughly a subset of C++.
[...]
C used well stops a lot of mess that occurs when C++ is used badly. But it
cuts both ways and depends on how disciplined you are in either case and
your circumstances.
Right. Well written C++ can certainly be as fast as C. I think the
reasons I saw C being chosen over C++ had to do with portability (this
dates back to an error when C++ compilers were much less consistent, and
where it was less unusual for the user and library vendor to have
different C++ compilers - and yes I realize it's possible to avoid those
pitfalls with a carefully written and properly firewalled C interface)
and that with C you are necessarily more aware of exactly what is
happening 'under the hood' (i.e. the code you actually write is much
closer to the assembly code that is generated).

Mind you, I happen to prefer C++ personally :-).
Post by g***@gmail.com
But now C++ has to more productive again and the tools that go with it,
it's as productive or more so than C# for a lot of cases.
if that continues, I can't imagine why anyone would continue to use C#
except for the libraries and staff availability and compile time concerns.
For what it's worth... I see standard libraries as something of a mixed
blessing. Certainly there is a lot of value in a good standard library,
but if it's not so good, it can be a burden to the language as users
prefer to use a better external solution anyway.

My impression is that languages that succeed at having large standard
libraries tend to have One True Compiler (or One True Interpreter, or
whatever). This allows for the language itself to have much greater
flexibility, as the entire ecosystem is much more tightly held together
and users don't have to worry about coding for a half dozen different
compilers and standard libraries in various states of playing 'chase the
standard'. (Also, because the libraries effectively *are* the standard,
you pretty well sidestep the issue of the two ever being out of sync.)

If anything, what we need is better organization around third party
libraries so that users are more aware of what is out there and what
libraries are accepted as the "best of breed", versus having a half
dozen (or more) libraries all trying to solve the same problem.
Post by g***@gmail.com
C++ does need to stop getting uglier though, the complexity and two ways of
doing things feeling like uniform initialisation really irks me.
I assume that was necessary because C++ is a living language that had to
wrestle with compatibility but I just wish it wasn't so. Developments like
that make people look at C++ badly. How much baggage can you acquire before
you can't carry it. But all real languages are affected by this so I remain
hopeful.
I have to agree with that; the inability (or *unwillingness*) to
*remove* features may be C++'s biggest weakness. At some point I think
C++ needs to learn that there comes a time to stop supporting past
mistakes and require people to port their code (at least if they want to
use new features).

Languages like Python are able (willing) to do that. See for example
changes to exception handling syntax, conversion of 'print' from a
keyword to function, renaming of 'xrange' to 'range', 'raw_input' to
'input', etc. Python3 looks an awful lot *like* Python2, but the two are
*not* entirely compatible.
Post by g***@gmail.com
As for python, I wouldn't put it on the same level as C++ and I don't
prefer it.
I wouldn't either, and I wasn't comparing Python to C++... I was
comparing it to C#.
Post by g***@gmail.com
I would think more people would compare C# and C++ than python and
that's where I see most of the job replacement and competition.
Again, different views from different angles. I'm not aware that my
company, or anyone in our field, even, uses C# *at all*... but we use
quite a bit of Python. Nor do I hear about C# being used to allow user
code in shipped applications, which definitely happens with Python (and
JavaScript). There are at least three systems for interfacing Python
with Qt (all of which I've actually *used*, even); I only see one for C#
and I'd never even heard of it until I went looking (but it's keeping
company with bindings for D, Lua and Haskell, which should tell you
something; the Ada bindings appear to be more heavily promoted than the
C# bindings). I could probably list other examples, but you get the idea.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-07 04:33:45 UTC
Permalink
Post by a***@gmail.com
@Thiago
"most of the compilation time is spent in optimising code and that can't
change" - again, you delivering your opinion as a fact. Please stop doing
it. You cannot be certain that in the future optimizing code can be done
more efficiently with better tools. You simply cannot know that.
Sorry, I misspoke. I meant that currently nothing the Standards Committee can
do will affect the optimisation steps that compilers affect since that's
completely out of the standard's scope. Compilers are free to generate totally
unoptimised (plain dumb) code if they want to.

And that said, I don't believe that we can get optimisers that are radically
more efficient. First because it's not an easy task. And second because the more
CPU power we get, the more we do with it. So instead of taking less time to do
the same tasks as we used to, newer compilers will take the same time to do
more than they used to.

This is my educated opinion.
Post by a***@gmail.com
And sure, improving just compilation times is not a Holy Grail. But it is a
big, big issue, and one of *main* points that C# is chosen over C++.
I still think it's a red herring.

I think that the compilation time is being perceived as a pain point in proxy
for other issues that people may face with C++ over other languages.

Also, as a curiosity, when you're talking about C# compile times, you're
talking about compiling to native code, right? Not to CLR. Same thing if we
talk about Java: compiling to native, not to bytecode or Dalvik.
Post by a***@gmail.com
But there is also other aspect of this whole C++ vs C# compilation times
debate: Managers.
a) C++ hard to learn, difficult to use, lots of time *wasted* on
compilation times, results compared to C# unobservable.
b) C# easy/(ier) to learn, easy/(ier) to use, very little time wasted on
compilation times, lots of people know it so it is much easier to replace
employee. Instead of having our products being released every two year
cycle, we can have them released every year.
Which option do you think most managers will go with?
That's a tricky question because a good manager will not make a decision. The
good manager will let the engineers make the decision based on the best tool
for the job, though more often than not "the best tool" means "the tool the
team knows best".
Post by a***@gmail.com
Dear C++ committee, what's wrong with you? How is having different ways of
initializing things easier to learn? If you want to make language uniform
make it uniform - everyone agrees - but what you doing is, you are saying
one thing "Let's make the language more uniform", and you are doing
complete opposite: You introduce yet another method of initializing!!! So
instead of one, newcomers have to learn two!!!
http://xkcd.com/927/
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 05:00:51 UTC
Permalink
Post by Thiago Macieira
Post by a***@gmail.com
@Thiago
"most of the compilation time is spent in optimising code and that can't
change" - again, you delivering your opinion as a fact. Please stop
doing
Post by a***@gmail.com
it. You cannot be certain that in the future optimizing code can be done
more efficiently with better tools. You simply cannot know that.
Sorry, I misspoke. I meant that currently nothing the Standards Committee can
do will affect the optimisation steps that compilers affect since that's
completely out of the standard's scope. Compilers are free to generate totally
unoptimised (plain dumb) code if they want to.
And that said, I don't believe that we can get optimisers that are radically
more efficient. First because it's not an easy task. And second because the more
CPU power we get, the more we do with it. So instead of taking less time to do
the same tasks as we used to, newer compilers will take the same time to do
more than they used to.
This is my educated opinion.
Post by a***@gmail.com
And sure, improving just compilation times is not a Holy Grail. But it
is a
Post by a***@gmail.com
big, big issue, and one of *main* points that C# is chosen over C++.
I still think it's a red herring.
I think that the compilation time is being perceived as a pain point in proxy
for other issues that people may face with C++ over other languages.
Can you elaborate on that. I don't know what you mean? What issues are you
thinking?
Post by Thiago Macieira
Also, as a curiosity, when you're talking about C# compile times, you're
talking about compiling to native code, right? Not to CLR. Same thing if we
talk about Java: compiling to native, not to bytecode or Dalvik.
Post by a***@gmail.com
But there is also other aspect of this whole C++ vs C# compilation times
debate: Managers.
Which option will most of them go with, you think if you present to
a) C++ hard to learn, difficult to use, lots of time *wasted* on
compilation times, results compared to C# unobservable.
b) C# easy/(ier) to learn, easy/(ier) to use, very little time wasted on
compilation times, lots of people know it so it is much easier to
replace
Post by a***@gmail.com
employee. Instead of having our products being released every two year
cycle, we can have them released every year.
Which option do you think most managers will go with?
That's a tricky question because a good manager will not make a decision. The
good manager will let the engineers make the decision based on the best tool
for the job, though more often than not "the best tool" means "the tool the
team knows best".
What the team knows best often prevails yes. But if the colleges push out
more C# bods than C++ that'll be C# that they know best. But also people
love the idea that if something is easier it'll be cheaper so they can pay
less. A lot of managers are on that line of thinking. I hope the
work bjarne and herb and others in the community to dispel the idea
that C++ is so bad or had is good because we need to continue to dispel the
idea that C# is still much easier than C++. It just has less warts because
it's a baby in comparison to C++.
Post by Thiago Macieira
Post by a***@gmail.com
Dear C++ committee, what's wrong with you? How is having different ways
of
Post by a***@gmail.com
initializing things easier to learn? If you want to make language
uniform
Post by a***@gmail.com
make it uniform - everyone agrees - but what you doing is, you are
saying
Post by a***@gmail.com
one thing "Let's make the language more uniform", and you are doing
complete opposite: You introduce yet another method of initializing!!!
So
Post by a***@gmail.com
instead of one, newcomers have to learn two!!!
http://xkcd.com/927/
Ha ha funny :)

But C++ has enough warts with things like uniform initialization that it
is looking pretty ugly now. I think there is only so much ugly a programmer
can sit and look at all day. I always wondered if some source to source
translation thing could have prevented us from having to have had to
introduce uniform initialization syntax and if the pain of doing that
(assuming it was possible) would have worked. Don't ask me exactly how that
source to source idea would have worked though. I don't know. Maybe it
wouldn't have been viable. I just hate to see int I{0}; everywhere.
Post by Thiago Macieira
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-07 05:25:17 UTC
Permalink
Post by g***@gmail.com
Post by Thiago Macieira
I think that the compilation time is being perceived as a pain point in proxy
for other issues that people may face with C++ over other languages.
Can you elaborate on that. I don't know what you mean? What issues are you
thinking?
I'm thinking of the usual suspects when people say C++ is hard, bloated and/or
slow.

For example, a developer may make more mistakes when writing C++ code, which
means he/she has to compile more often, which is why he/she thinks the build
time is an issue. The build time is not the root cause of this scenario, but
the fact that the developer made more mistakes. And the actual root cause may
be the complexity of the language (hard to understand) or because the
developer in question did not get proper training in the language in the first
place. Or both.

Whenever I talk to C developers, they think C++ is slow. C++ isn't slow, it's
the code they wrote because C++ gave them too much rope to hang themselves and
they did.

But either way, that adds to the frustration with the language and people lash
out at the most visible sticking point saying that it's the biggest problem
since doing arithmetic. So people will say compilation times are a problem and
must be solved, the lack of reflection is a problem and must be solved, the
lack of lambdas was a problem and had to be solved, etc.

Mind you, I'm not saying those problems don't exist or don't deserve to be
solved. I'm simply saying I'm skeptical that their relative relevance is that
big and that I expect that the real problem may be different than what people
perceive it to be.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 05:59:41 UTC
Permalink
Post by Thiago Macieira
Post by g***@gmail.com
Post by Thiago Macieira
I think that the compilation time is being perceived as a pain point
in
Post by g***@gmail.com
Post by Thiago Macieira
proxy
for other issues that people may face with C++ over other languages.
Can you elaborate on that. I don't know what you mean? What issues are
you
Post by g***@gmail.com
thinking?
I'm thinking of the usual suspects when people say C++ is hard, bloated and/or
slow.
For example, a developer may make more mistakes when writing C++ code, which
means he/she has to compile more often, which is why he/she thinks the build
time is an issue. The build time is not the root cause of this scenario, but
the fact that the developer made more mistakes. And the actual root cause may
be the complexity of the language (hard to understand) or because the
developer in question did not get proper training in the language in the first
place. Or both.
Whenever I talk to C developers, they think C++ is slow. C++ isn't slow, it's
the code they wrote because C++ gave them too much rope to hang themselves and
they did.
But either way, that adds to the frustration with the language and people lash
out at the most visible sticking point saying that it's the biggest problem
since doing arithmetic. So people will say compilation times are a problem and
must be solved, the lack of reflection is a problem and must be solved, the
lack of lambdas was a problem and had to be solved, etc.
Mind you, I'm not saying those problems don't exist or don't deserve to be
solved. I'm simply saying I'm skeptical that their relative relevance is that
big and that I expect that the real problem may be different than what people
perceive it to be.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
I can agree with a lot of that without conceding the point that compile
times need to improve a lot. I really think expecting people to wrestle
with pre-compiled headers and distributed builds etc. is unreasonable when
C# requires non of that.

But you are right in many ways, I definitely make more typo mistakes in C++
than in C#. I don't know why, but I noticed that a few times. I also
remember being a lot more productive with VC6 than VS2013.... what's with
that... apart from a bad memory lol. I assume it's because it's so slow
because some of it's written in C#....

I think there is a lot of scope to improve performance beyond raw compile
times if companies actually take an interest. The advent of mobile and
perhaps webserver seems to have sparked that interest in performance to a
degree in a way that didn't appear to be there before. C++ tooling is
getting better which is why I'm turning from pessimist to optimist about
it. But it's been a long time coming.

VS doesn't lock the machine up quite so much these days, when it did,
it created a sense of waiting and waiting forever for builds before one
could do anything else, but that's now changing and other improvements seem
to be following. Don't laugh but a long long time ago I used VB6 and found
it's edit and continue to be an amazing productivity boon because it seemed
to work so comprehensively, C++ just never seemed to get that as good.
Never before was it so quick to write such bad code. lol

I think all these things on top of raw compile speed can make a big
difference but they need to happen. Smart tools that know what's going on
but that aren't bloated can really help. You'll be pleased to know I
experimented with QT Creator recently against my own build of clang and the
build started and finished so quickly I hadn't realised and thought
something was wrong. :)

Things deteriorated soon after that as I wrestled with cmake syntax.
Standard project formats systems next. lol
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-06 19:04:57 UTC
Permalink
@Matthiew

"In *my* world, Windows barely exists" - Matthiew, all I can say, check
this link and see how real world really looks like:

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

No, I do not get paid for number of lines. I am an owner of a small game
development company and get paid for the games we release. If I release
game every two years I get paid every two years. If I release game every
year I get paid every year.

"The point is, you own *personal* view does not reflect reality as a whole,
so please stop acting as if it does. "

Sure, it is my personal point of view, but this point of view is shaped
through observing what's happening in the part of world you are not aware
of, which is roughly 87% if you care to check the link I've provided, of
real world with real computers, software and people using them.

And please understand. I do not try to fight here with people. I simply try
to raise awareness of the fact that C++ unbelievable as it seems is not the
one and only choice for AAA gaming studios. Partially due to the fact that
is simply to long to produce something compared to C# for example. That's
all.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Matthew Woehlke
2015-01-06 21:32:59 UTC
Permalink
Post by a***@gmail.com
Post by a***@gmail.com
In *my* world, Windows barely exists
all I can say, check
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
(Well, apparently my view is 45% correct. That's not too bad...)

On a serious note: I didn't say it was broadly representative...
actually, that was sort of the point is that it *isn't*. From your
perspective, C++ is dead and C# has achieved world domination. From my
perspective, Windows is not very unimportant and C# may as well not exist.

That said, see also:

http://www1.american.edu/carmel/nk3791a/Software.htm
http://www.valuewalk.com/2014/01/it-most-undervalued-sector-goldman-sachs/
http://www.bsa.org/country/Public
Policy/~/media/Files/Policy/Security/General/sw_factsfigures.ashx

(Apparently it's hard to find statistics for the software industry
broken down by sector...)

Only *one* of those even calls out "home entertainment"... with "0%"
(which I take to mean 'less than 0.5%') market share. None mention
"games". It's also informative to note that there seems to be a pattern
of consumer-facing software having in general a very low share of the
industry. (And if you think about it logically, this isn't too surprising.)

(For the record, Windows is far from 87% of the industry, also. They
only have a majority in the "desktop computer" sector, which is, if
anything, a *minority* as far as the industry as a whole. Their share of
the "mobile" market is pitiful. They barely exist in supercomputing. As
far as I know, they *don't* exist, at all, in the embedded world. That's
a lot of industry that's removed from Windows, much less "AAA games".)
Post by a***@gmail.com
No, I do not get paid for number of lines. I am an owner of a small game
development company and get paid for the games we release. If I release
game every two years I get paid every two years. If I release game every
year I get paid every year.
That's quite different from how things work at large companies. Not to
say that there isn't probably *some* degree that productivity has an
effect, but for the most part, employees get paid a mostly fixed salary,
and products are produced when they're produced. (There is also a big
difference between one-off products that have an initial release and are
then forgotten, versus products that have ongoing development and
support for years and even decades.)
Post by a***@gmail.com
"The point is, you own *personal* view does not reflect reality as a whole,
so please stop acting as if it does. "
Sure, it is my personal point of view, but this point of view is shaped
through observing what's happening in the part of world you are not aware
of, which is roughly 87% if you care to check the link I've provided, of
real world with real computers, software and people using them.
(I'm not going to further dignify the FUD - not to mention unfounded
personal insults - in that with a reply. Suffice to say, your reply
proves the very point to which you replied.)

Whether you mean to or not, you come across as feeling that your point
of view is representative of the majority, or at least the only segment
that matters.

Sure, faster compiler times would be interesting. However, I don't buy
your very limited view as being conclusive proof that this issue is
critical to the future of C++.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
m***@gmail.com
2015-01-06 22:01:45 UTC
Permalink
One question who cames recently in my mind is C compatibility. I explain:
- C++ still use the C includion model, which keep C++ compatible with C.
- Modules are because this inclusion model have quite a lots of
shortcomings, compilation time being one of them.
- I doubt C++ will ever be made imcompatible with C code and libraries.
=> All this put together, this means that in the future C++ will have to
support both the C file inclusion model and the module inclusion model. But
is this a good things? Has already sais in this thread, having 2 way to do
the same thing makes the language harder to learn and to understand. (The
previous post was speaking about uniform initialisation syntax, but it is
also true for the includion model). So (my question will follow), since
removing the C-inclusion model isn't an option for now in order to keep
compatibility, will the module inclusion model being submitted to the C
world, so that at least newly written C libraries could take advantage of
it, and therefore C++ projet using those libraries as well?
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-07 04:42:25 UTC
Permalink
Post by m***@gmail.com
So (my question will follow), since
removing the C-inclusion model isn't an option for now in order to keep
compatibility, will the module inclusion model being submitted to the C
world, so that at least newly written C libraries could take advantage of
it, and therefore C++ projet using those libraries as well?
My guess is that it will happen naturally. Since the C++ modules must,
entirely by construction of the language, work for C code as much as for C++
code, any compiler that implements C++ modules will have all the necessary
infrastructure to support it in C. In turn, expect those compilers to provide
Modules first as an extension to C, and then later get adopted in C too.

This has happened before:
- the C++11 memory model is adopted in C11
- C++11 static_assert is present in C11
- C++11 non-template atomic types came to C11 in <stdatomic.h>
- GCC has __auto_type as an extension to C11

That said, #include and the preprocessor won't go away for at least (this is a
guess) 20 years. Too much legacy.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 03:47:29 UTC
Permalink
Hi everyone,
I do apologize if I sounded aggressively. That was not my intention. But I
find it really upsetting when I am rising a serious issue, and I'm getting
blase/complacent attitude.
Appalling compiling times of C++ *are* great disadvantage (I know it is
not the only disadvantage, but major one for sure) and in modern times when
everything needs to be done faster then year ago, this is something to be
aware of and weary of.

I do not want to insult nor irritate anybody nor I'm sure if I'm correct in
what I'll say now, but I'm getting the impression that C++ committee
consist of people who either:
a) Work in organization which uses C++ exclusively and don't have place for
any other language
b) Uses C++ exclusively and don't use any other language
c) Teaches exclusively C++

What is my point? My point is that if you in one of the groups listed
above, you will not see the whole picture. For you, your personal world
consist of purely C++ and there is no neither need nor danger of anything
upcoming because you hardly see any glimpse of it.

Don't mean to personally attack, but when somebody like @Matthew Woehlke
states that:
"In *my* world, Windows barely exists, and it would hardly (directly)
affect me if tomorrow every instance of Windows in existence suddenly
stopped working."
then I am really stumped on such... I don't know even how to call it.
Ignorance? Arrogance? Unawareness? Sorry Mathew, don't take it personally.
How can somebody in right mind ignore existence of a Windows OS? Sure,
windows has no place in embedded environment, but lets think about it for a
second. How many newly graduates dream of becoming embedded system
developers, how many of them dream of developing games, how many of them
dream of developing applications with GUI? I bet the majority will be
concentrated in two last options. If we agree on that, then having 87% of
market domination is a huge factor and Windows owns it. That means that
there is 87% more of a chance to be employed in company who works in
Windows environment. That means that this person will code for windows. And
here comes the punch:
If C# will dominate windows environment, 87% (not whole 87 but majority of
it) of most popular OS jobs will be (in time) jobs for C# developers. Year
after year, there will be more and more C# dominance and less and less C++
in Windows.
And sure, C++ will thrive on Linux, embedded systems and other esoteric
platforms (esoteric for most of every day developers), but *huge* chunk of
a market will be lost. Can C++ afford it? I really don't think so.

I really love C++. I want to use it. I hope that C++ committee will
concentrate on *real* improvements, make C++ more competitive *in every
area*, and stop adding new and more features which very often only add
burden than anything else. It seems to me that they threat C++ as their
personal toy, which they own and can do anything with it, and the more
"clever" they make it the more important they feel. This is saddening.
Couple of examples only, which I probably be crucified for:
a) uniform initialization - not uniform at all, it seems to me that it
brings more burden on newcomers than help
b) lambdas, yes, lambdas, I find them to actually pollute code with "raw"
lines of code instead of abstraction. How? They are guts of a function.
Surely it is easier to read function's name and deduce what that function
is doing then read entire body of a lambda and then figure out what is it
doing?
c) recursion in templates instead of iteration. This is simply a disaster,
and I have no words to describe how I feel about it. Not that I don't
understand how recursion works. I do. But iteration is a far easier concept
to grasp/teach and use. Code is clearer and easier to read when iteration
is used. The things I saw how recursion is used... Even in latest book by
Mr Bjarne C++11 4th edition. My God, with iteration example that would take
2-3 lines of code with recursion not only page is needed, but to actually
understand what is happening takes a lots of time and patience. And what
for? To feel clever and important? Maybe for some people this is a reason
good enough.
But that is C++ committee's toy. They are on a path to create language for
geniuses and nerds only.

My 10c.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 04:41:49 UTC
Permalink
Post by a***@gmail.com
Hi everyone,
I do apologize if I sounded aggressively. That was not my intention. But I
find it really upsetting when I am rising a serious issue, and I'm getting
blase/complacent attitude.
Appalling compiling times of C++ *are* great disadvantage (I know it is
not the only disadvantage, but major one for sure) and in modern times when
everything needs to be done faster then year ago, this is something to be
aware of and weary of.
I do not want to insult nor irritate anybody nor I'm sure if I'm correct
in what I'll say now, but I'm getting the impression that C++ committee
a) Work in organization which uses C++ exclusively and don't have place
for any other language
b) Uses C++ exclusively and don't use any other language
c) Teaches exclusively C++
What is my point? My point is that if you in one of the groups listed
above, you will not see the whole picture. For you, your personal world
consist of purely C++ and there is no neither need nor danger of anything
upcoming because you hardly see any glimpse of it.
"In *my* world, Windows barely exists, and it would hardly (directly)
affect me if tomorrow every instance of Windows in existence suddenly
stopped working."
then I am really stumped on such... I don't know even how to call it.
Ignorance? Arrogance? Unawareness? Sorry Mathew, don't take it personally.
How can somebody in right mind ignore existence of a Windows OS?
I don't think anyone including Matt means to be blasé more than you mean to
be aggressive. I think it's just people work in different areas and have a
different sense of urgency and priority because of that and aren't
initially thinking on your train of thought but can do once the awareness
is sparked and they've had time to take it all in. Plus we all get
passionate at times and that comes out as heat.

I was surprised at Matt's statement too but he was just relating that
Windows means nothing to him which is basically true because he isn't using
it. I'm the same way with Linux. I'm taking more interest in Linux now and
at least have it installed and play with it a little but that's only
happened in recent times because of Microsoft pulls the chain too hard. But
I agree with you anyway, I'm just saying it's not that surprising.
Post by a***@gmail.com
Sure, windows has no place in embedded environment, but lets think about
it for a second.
How many newly graduates dream of becoming embedded system developers, how
many of them dream of developing games, how many of them dream of
developing applications with GUI? I bet the majority will be concentrated
in two last options. If we agree on that, then having 87% of market
domination is a huge factor and Windows owns it. That means that there is
87% more of a chance to be employed in company who works in Windows
environment. That means that this person will code for windows. And here
If C# will dominate windows environment, 87% (not whole 87 but majority of
it) of most popular OS jobs will be (in time) jobs for C# developers. Year
after year, there will be more and more C# dominance and less and less C++
in Windows.
And sure, C++ will thrive on Linux, embedded systems and other esoteric
platforms (esoteric for most of every day developers), but *huge* chunk of
a market will be lost. Can C++ afford it? I really don't think so.
Agreed.
Post by a***@gmail.com
I really love C++. I want to use it. I hope that C++ committee will
concentrate on *real* improvements, make C++ more competitive *in every
area*, and stop adding new and more features which very often only add
burden than anything else. It seems to me that they threat C++ as their
personal toy, which they own and can do anything with it, and the more
"clever" they make it the more important they feel. This is saddening.
a) uniform initialization - not uniform at all, it seems to me that it
brings more burden on newcomers than help
b) lambdas, yes, lambdas, I find them to actually pollute code with "raw"
lines of code instead of abstraction. How? They are guts of a function.
Surely it is easier to read function's name and deduce what that function
is doing then read entire body of a lambda and then figure out what is it
doing?
c) recursion in templates instead of iteration. This is simply a disaster,
and I have no words to describe how I feel about it. Not that I don't
understand how recursion works. I do. But iteration is a far easier concept
to grasp/teach and use. Code is clearer and easier to read when iteration
is used. The things I saw how recursion is used... Even in latest book by
Mr Bjarne C++11 4th edition. My God, with iteration example that would take
2-3 lines of code with recursion not only page is needed, but to actually
understand what is happening takes a lots of time and patience. And what
for? To feel clever and important? Maybe for some people this is a reason
good enough.
But that is C++ committee's toy. They are on a path to create language for
geniuses and nerds only.
I think some of that is a bit unfair even if somewhat true. e.g. As far as
I know, Bjarne wasn't that impressed with lambdas himself. He has said all
along he thinks overuse of unnamed functions is a bad idea and that people
will overuse lambda's in a bad that way because it happens to every
new feature until people work out what it's good for.

He also said he doesn't like everything in C++ but it doesn't matter if he
doesn't like it, it's what everyone votes on that counts. I think that is a
position you could ascribe to any Committee member and they voted lamda's
in. As much as I have issues with lambda's myself, I'm not sure I could
have resisted not voting for them either. So what does that say? I wouldn't
want to hold the language back because as Bjarne says, perfect is the enemy
of good... etc.

Are lambda's overused or useful or both, decide for yourself:
http://moderncpp.com/
If they weren't in the language C++ would be decried for "not evening
having lambda's".

I also think there is a limit to what big features the Committee can do
with C++ on a voluntary basis without corporate backing to some extent. We
have to be careful when we get upset to remember that. On a bad day I lose
site of that myself. We should also try to remember we don't contribute
remotely as much if anything to this as we get out of it.
Post by a***@gmail.com
My 10c.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I
wasn't able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2015-01-07 05:07:35 UTC
Permalink
Post by a***@gmail.com
Hi everyone,
I do apologize if I sounded aggressively. That was not my intention. But I
find it really upsetting when I am rising a serious issue, and I'm getting
blase/complacent attitude.
Hi

By the way, what's your name?

Let me start by saying that I do agree there's a lot the Standards community
can do to improve C++ adoption and I want to add that there's a lot more that
is actually the responsibility of the implementations, not of the Standard.

The problem here is that you're reading too much into what people are saying.
Post by a***@gmail.com
"In *my* world, Windows barely exists, and it would hardly (directly)
affect me if tomorrow every instance of Windows in existence suddenly
stopped working."
then I am really stumped on such... I don't know even how to call it.
Ignorance? Arrogance? Unawareness?
You call it "statement of fact".

Matthew said that in *his* world Windows has little relevance and would hardly
affect *him* and *his world* if Windows were to suddenly disappear.
Post by a***@gmail.com
Sorry Mathew, don't take it personally.
How can somebody in right mind ignore existence of a Windows OS?
He isn't ignoring the existence. That's not at all what he said.
Post by a***@gmail.com
Sure,
windows has no place in embedded environment, but lets think about it for a
second. How many newly graduates dream of becoming embedded system
developers, how many of them dream of developing games, how many of them
dream of developing applications with GUI? I bet the majority will be
concentrated in two last options. If we agree on that, then having 87% of
market domination is a huge factor and Windows owns it. That means that
there is 87% more of a chance to be employed in company who works in
Windows environment. That means that this person will code for windows.
First of all, what students dream of depends on what they are exposed to prior
to graduation. If they happen to study in a University that has an extensive
embedded curriculum and has contacts to the embedded industry, that might take
students in another direction.

Second, I doubt students today dream of developing desktop GUI applications.
No, they dream of developing mobile applications and web services (cloud-
hosted services) and in neither of those domains is Windows dominant.

Even if students dream of developing games, the vast majority of them will
develop mobile games where again Windows is not a benchmark.

Finally, when you talk about being employed, everything changes. It's no
longer about what the person wants, but what the job requires. If you take the
computing world as a whole, desktop development is only a fraction. I won't
guess how big, but I can say with absolute certainty it's less than 100%,
which is what you concluded when you equated "desktop market domination" to
"overall market domination".

So no, I dispute your assumptions and your conclusions.
Post by a***@gmail.com
If C# will dominate windows environment, 87% (not whole 87 but majority of
it) of most popular OS jobs will be (in time) jobs for C# developers. Year
after year, there will be more and more C# dominance and less and less C++
in Windows.
First of all, domination for Windows depends a lot on Microsoft. If Microsoft
puts a lot of effort into pushing C#, then C# gets an upper hand. If Microsoft
puts more effort into C++ and C++/CLI, then who knows?
Post by a***@gmail.com
And sure, C++ will thrive on Linux, embedded systems and other esoteric
platforms (esoteric for most of every day developers), but *huge* chunk of
a market will be lost. Can C++ afford it? I really don't think so.
You're way, way off the mark when you say "huge chunk". I believe the non-
Windows parts of the market are the huge chunk. I think you're seriously
underestimating the size and the value of those other parts.

More than likely, we're both biased by our contexts here. The company I work
for has a workforce at least 10x bigger working on Linux development compared
to Windows, not to mention the people doing web app development and other
things. So if you want to do software development in the same company I do,
there's less than 5% chance that it will be related to Windows.
Post by a***@gmail.com
c) recursion in templates instead of iteration. This is simply a disaster,
and I have no words to describe how I feel about it. Not that I don't
understand how recursion works. I do. But iteration is a far easier concept
to grasp/teach and use. Code is clearer and easier to read when iteration
is used. The things I saw how recursion is used... Even in latest book by
Mr Bjarne C++11 4th edition. My God, with iteration example that would take
2-3 lines of code with recursion not only page is needed, but to actually
understand what is happening takes a lots of time and patience. And what
for? To feel clever and important? Maybe for some people this is a reason
good enough.
That wasn't intentional. Template metaprogramming happened by accident, it
wasn't part of the design. So you can say that all the metaprogramming today
is an "abuse" of the original goal. Constexpr functions should help a lot and
there's a lot that can be done to improve this.
Post by a***@gmail.com
But that is C++ committee's toy. They are on a path to create language for
geniuses and nerds only.
You do realise that it's not a bad thing to have a select audience, right?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Gabriel Dos Reis
2015-01-07 14:07:44 UTC
Permalink
***@gmail.com writes:

| Hi everyone,
| I do apologize if I sounded aggressively. That was not my intention.
| But I find it really upsetting when I am rising a serious issue, and
| I'm getting blase/complacent attitude.
| Appalling compiling  times of C++ *are* great disadvantage (I know it
| is not the only disadvantage, but major one for sure) and in modern
| times when everything needs to be done faster then year ago, this is
| something to be aware of and weary of.
|
| I do not want to insult nor irritate anybody nor I'm sure if I'm
| correct in what I'll say now, but I'm getting the impression that C++
| committee consist of people who either:
| a) Work in organization which uses C++ exclusively and don't have
| place for any other language
| b) Uses C++ exclusively and don't use any other language
| c) Teaches exclusively C++

In summary: your intention wasn't to be aggresive, but in your world
view people dedicating their voluntary resouces (e.g. good parts of their
lives and dedication) to working on C++ are monolinguistic bingots.

Now that you've repeatedly called them names, you want them to listen to
your wisdom and solve your problems, presto?

If someone was actively working to sabotage development of C++ and
divide the C++ community for the benefits of the competition, I suspect
this might be a good template to deploy.

-- Gaby
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Matthew Woehlke
2015-01-07 16:10:00 UTC
Permalink
Post by a***@gmail.com
How can somebody in right mind ignore existence of a Windows OS?
How can somebody in their right mind *choose* to use Windows? ;-) It's
an atrocious OS.

Thankfully, I rarely have to deal with it, and so I don't. YMMV,
obviously (I never said otherwise).
Post by a***@gmail.com
how many [new graduates] dream of developing applications with GUI?
Heh. It's just a bit ironic to imply that GUI == Windows, considering
how many times Qt has been mentioned in this thread. (And, not that
you'll get much from *me*, but where's the iOS love? ;-))

Anyway, this is getting wildly off topic. Please take (both of) the
above for the light humor they are intended to be and let's let this
drop now...
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 19:32:47 UTC
Permalink
Post by Matthew Woehlke
Post by a***@gmail.com
How can somebody in right mind ignore existence of a Windows OS?
How can somebody in their right mind *choose* to use Windows? ;-) It's
an atrocious OS.
Thankfully, I rarely have to deal with it, and so I don't. YMMV,
obviously (I never said otherwise).
Ha! I don't know how someone in their right mind could *use* Linux even if
they've chosen to!
I tried for years to install several Linux distro's on my laptop(s) and
they all died during the install stage.
Admittedly I didn't try too hard. If the install failed I gave up without
further investigation.
But even when one did install (only late last year) it would only work in a
VM and was stuck at 1024x768.
The res app failed to see anything higher. So I gave up again rather than
investigate too hard.

Only in the last month did one install (Linux Mint) that was capable
of setting my laptops pathetic max 1366x768 resolution by default.

But then package manager only offered me g++ 4.2 or something though and
after reading that package managers aren't standard on Linux, I lost
interest in learning it and gave up.

I've never had this trouble in Windows in over 10 years.

In fact I've had the opposite, Windows 8 installed fine with the correct
resolution, but I wish it didn't. ;)

I already have clang on my Windows machine that is suitable for C++17
experimenting so it's hard to want to persist with Linux when I hit an
obstacle if I don't have to.

Loosely steering this conversation back to modules though, what I really
think is that the industry needs to grok the idea we as programmers can't
afford to waste so much of our time NOT programming. Which is what happens
when we are expected to mess with bad installers, overly complicated
configuration options, bad user interfaces, bad diagnostics, distributed
build systems and pre-compiled headers, all of which are non standard and
not about what we do. Oh and we need to get way better at documenting what
we've already done.

We need to make the core experience better by default which in the case of
C++ it means it needs to compile faster. But it could also help us more in
other ways. My compiler won't even tell me (or provide the option to tell
me) that my include path contains folders that don't exist, or has the same
folder repeated twice or is wasting time including more than I need or tell
me how I can get away with including less.

Anyway, all of this started when the OP wanted to know about modules. Maybe
the answer I'm looking for might come from getting the answer to this
question.

Anybody: Can clang build itself and has anyone ever tried to build clang
with itself using it's own support for Modules? If so, how much quicker was
it to compile under modules? If nobody has tried this, why not and does
anyone plan to try that and roughly when and will they post results when
they know them?

Thanks
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
g***@gmail.com
2015-01-07 05:11:57 UTC
Permalink
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
I just updated my clang / llvm tree with change r225338, a change to
smallvector.h and that has triggered the whole of llvm and clang to
rebuild. 1500 or so files taking 35 minutes with all 8 logical cpu's maxed
out at 100%. Would modules have changed things much, I don't know.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
David Krauss
2015-01-07 05:21:50 UTC
Permalink
I just updated my clang / llvm tree with change r225338, a change to smallvector.h and that has triggered the whole of llvm and clang to rebuild. 1500 or so files taking 35 minutes with all 8 logical cpu's maxed out at 100%. Would modules have changed things much, I don't know.
If you can find a comparable compiler that is implemented in C#, then we can see how going in that direction would change things.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 11:07:52 UTC
Permalink
@Thiago
Hi, my name is Artur Czajkowski. I'm glad and pleased to meet you.

When you say:

"You do realise that it's not a bad thing to have a select audience, right?
"

I can actually with almost 100% certainty say that if that's become the
case C++ will become a dead language rather sooner or later. Just like a
Latin. Why? Because in order for a language to survive it needs to be used
by as many people in as many areas as possible. Not just in churches in
some countries which I don't even know in which part of world they are,
and not as merely medical terminology, used only by specialists amongst
specialists.

I'm sorry but if that's become the case, that is C++ only for geniuses and
nerds, then I really don't see it thriving.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 14:43:16 UTC
Permalink
@Gabriel

You dedicated your free time because most likely you want to do it, it
satisfies your either power needs, fun needs, belonging needs or any
combination of those.

And as for me and C++?
Don't fix C++. Forget about it. It doesn't need fixing. It's great, no
competitors anywhere at the horizon. It's getting better and better from
year to year, so why would you do anything about it?
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Ville Voutilainen
2015-01-07 14:49:52 UTC
Permalink
Post by a***@gmail.com
You dedicated your free time because most likely you want to do it, it
satisfies your either power needs, fun needs, belonging needs or any
combination of those.
And as for me and C++?
Don't fix C++. Forget about it. It doesn't need fixing. It's great, no
competitors anywhere at the horizon. It's getting better and better from
year to year, so why would you do anything about it?
Ah, mr. forum-troll, were you by any chance banned from this forum for a while,
and that ban was recently lifted? That would certainly explain why
your contributions
are back at the same high-quality level as they ever were.

Feel free to tell us when you plan to contribute anything but whining
to C++. Many
of the rest of us do.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 16:09:24 UTC
Permalink
@Ville
I am really appalled by your comment. Are you serious? I'm sure that you
have the way to check my account and if it was banned *ever*.

There wasn't and there will be no reason to ban me.

Unless you are willing me what kind of offense I've committed either here
or other threads?
So perhaps in the future you will check your facts before actually calling
somebody a troll?

But that's typical of disgruntled admins. Call me a troll, ban me and for
sure you will never hear from me. That's right. Why would you listen to
somebody from outside? Why?
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 16:10:52 UTC
Permalink
@Gabriel

Would you mind telling me what are you doing for living?
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 16:13:07 UTC
Permalink
@Gabriel

And while I'm asking you a questions, do you mind pointing me to the place
in this thread where I've called people names?
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 16:16:46 UTC
Permalink
@Ville

I've given some thought to your atrocious post addressed by me, and I
request from you to point me into the place in my posts which would qualify
as a trolling. I am really asking you to point me to these place/those
places.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-07 16:19:44 UTC
Permalink
@Matthew
Sure, there was never my intention to have any fights with anybody here. I
don't have any bad feelings towards you and wish you all the best. I came
here with best intentions, to share *my personal* view of the C++ world.
What did I find?
Blase attitude, complacent, denial, being told that I'm wrong and that I'm
troll. Well done.

And AFAIC the person who called me troll is active C++ committee member.
Unbelievable. No wonder why C++ is in the state it is.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
a***@gmail.com
2015-01-08 00:11:18 UTC
Permalink
@Bo Person,

Sure, and that's why you so many job offers for Latin speakers. Right.
Post by a***@gmail.com
Sorry guys for posting it here and not in the modules section but I wasn't
able to post it there.
Anyway, is there any significant progress on modules? Will they be
actually implemented in C++17?
This question rises from the appalling compilation times C++ has compared
to C# which is quite an embarrassment.
Thank you.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.
Continue reading on narkive:
Loading...