On 11/14/2018 12:01 PM, Russel Winder wrote:
> At the ACCU conference (https://conference.accu.org ) if someone says they are
> a C++ expert, they are probably a member of WG21. ;-)
> (For the uninitiated WG21 is the C++ standards committee.)

AFAIK, most WG21 members specialize in certain areas of the language. The list of people who thoroughly understand C++ is:

1. Herb Sutter
2. can't think of anyone else :-)

On Wed, Nov 14, 2018 at 04:47:16PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, November 14, 2018 4:25:07 PM MST Walter Bright via Digitalmars-d wrote:
[...]
> > 5. What size is an `int`?
> 
> While I agree with the point that you're trying to make, that particular type actually isn't really a problem on modern systems in my experience, since it's always 32 bits.
[...]
> It's long that shoots you in the foot, because that still varies from system to system, and as such, I've always considered long to be bad practice in any C++ code base I've worked on. [...] But even then, when you're dealing with something like printf, you're screwed, because it doesn't understand the types with fixed sizes. So, you're constantly fighting the language and libraries.

Haha yeah, using printf with variable-sized integral types like long is a nightmare in C/C++.  Though in my current project, a hack solution has been devised by making use of the otherwise-evil preprocessor:

	long l = ...;
	printf("Long value is: %"PRIlong"\n", l);

where PRIlong is a macro defined in a suitable global header file that defines the correct format specifier for 'long'.  It's a workaround as ugly as sin, but it does save you from the utter headache of trying to figure out which of %d, %ld, %lld you need to use.  (Unfortunately, it doesn't stop people from continuing to write %ld where they really should be writing %"PRIlong"... programming by convention rears its head again with all of its ugly consequences.)


> D's approach of fixing the size of most integer and floating point types is vastly superior, and the problems that we do have there are from the few places where we _didn't_ make them fixed, but since that mostly relates to the size of the memory space, I'm not sure that we really had much choice there.

Yeah, recently I've had size_t bite me in the rear: I had code cross-compiled to 32bit Android/ARM and my size_t's were working nicely with int parameters... then I wrote a test driver for testing non-OS specific modules on the host PC, and suddenly I have a whole bunch of compile errors because size_t no longer converts to int.


> The main outlier is real, though most of the controversy there seems to have do with arguments about the efficiency of the x87 stuff rather than having to do with differences across systems like you get with the integers.
[...]

Yeah, 'real' is a blemish in D's otherwise beautifully-designed basic types.  (Just don't get me started on int promotion rules, and I'll pretend everything else is beautiful too. :-D)

Confession: I used to love 'real'... but after researching more thoroughly into its performance characteristics recently (esp. on recent hardware), I've started to realize it wasn't quite what I had expected.


T

-- 
What's a "hot crossed bun"? An angry rabbit.

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> ...what are the advantages of using D vs C++ if my goal is to build a complex system / product?

That 'goal' really needs further refinement ;-)

What is a 'complex system/product' anyway?

Are you building an o/s kernel?

Are you building a relational database system?

> what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

So you've moved from a pretty blurry goal, to comparing 'language features'..already?

You really need to start at a higher level of thinking first.

What paradigm will best suit the 'complexity' you mention?
 (and remember, multi-paradigm could just increase that complexity and place extra burden on programmers)

Do you want/need garbage collection?
Do you want/need exception handling?
Do you want/need a unified type system?
Do you want/need cross-platform (whatever that means these days).
How stable is the language?
How many developers are you likely to need?
How experienced will they need to be?
How easy can you obtain their services, and at what cost?
Can you retain such programmers over the lifetime of the product?

Comparing language features in order to discover which language best suits your goal, first depends on having a clear goal in the first place.

Ask the right questions first. That's my advice.

On Wed, 2018-11-14 at 15:59 -0800, Walter Bright via Digitalmars-d wrote:
> On 11/14/2018 12:01 PM, Russel Winder wrote:
> > At the ACCU conference (https://conference.accu.org ) if someone says they
> > are
> > a C++ expert, they are probably a member of WG21. ;-)
> > (For the uninitiated WG21 is the C++ standards committee.)
> 
> AFAIK, most WG21 members specialize in certain areas of the language. The
> list
> of people who thoroughly understand C++ is:
> 
> 1. Herb Sutter
> 2. can't think of anyone else :-)

Jonathan Wakely, Roger Orr, Kate Gregory, etc. I can think of quite a few more.

But yes, WG21 is about fragmentation as much as integration.

A couple of potentially boring facts:

1. C++ has no std::string strip function. I started an effort, Anthony Williams wrote an implementation, the proposal got started, and is now going nowhere for lack of someone to push it through the WG21 system.

2. C++ has no thread-safe queue, and no thread-safe channel system in the standard library. For a language with std::thread this is unbelievable. WG21 as a whole it seems thinks shared memory multi-threading is the right way of doing concurrency and parallelism. Oh well.

As I now use Rust not C++, I no longer actually care.

Whilst GtkD and GStreamerD are lovely, the GStreamer community is shifting C → Rust, so Rust it has to be for the stuff I am doing now: D isn't really an option in this community, though many know of it.

Rust has a wonderful amalgam of futures, channels, and executors generally and
especially in in gtk-rs that make multi-thread, reactive programming trivially
easy.  It would be great if this got added to D and GtkD, but I can't see it
happening – this is not the same thing as vibe.d. JavaScript and Python have
their single threaded version of effectively the same thing – which probably
is a bit like vibe.d. Kotlin has it's co-routines, Go it's goroutines and Java
will likely get something similar in OpenJDK13 if not 12 – to supersede use of
the Rx extensions – more like what Rust has not as JavaScript and Python have.
My feeling, agreed by many whose judgement I trust, is that this is not "me
too" as a fashion, but is a genuine move forward for asynchronous computing.
Though many opine that Python's current offering is not of good enough
quality.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 14 November 2018 at 17:47:10 UTC, Basile B. wrote:
> On Wednesday, 14 November 2018 at 16:09:32 UTC, Eugene Wissner wrote:
>> No, it wasn't the reason. Some algorithms cannot be implemented with ranges as efficient as with iterators.
>>
>> "In other words, by converting the is_word_boundary from iterators to D-style ranges, the algorithm goes from O(1) to O(N). From this we draw the following conclusion: D’s choice of algorithmic basis operations is inherently less efficient than C++’s."
>>
>> C++ iterators are more flexible.
>
> You meant D ?

No, more flexible and prone to contortion. More flexible, less useful.

On Wednesday, 14 November 2018 at 23:22:44 UTC, H. S. Teoh wrote:
> On Wed, Nov 14, 2018 at 03:09:33PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 11/14/2018 7:33 AM, rikki cattermole wrote:
>> > Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...
>> 
>> The C++ community insists they invented ranges independently from D.
> [...]
>
> That's ridiculous.  Didn't the guy who wrote the C++ range proposal copy the code example from my article on component programming in D?
>
>
> T

Yep, the calendar one. TBF, you were in the list of citations for that talk.

On Thursday, 15 November 2018 at 06:55:12 UTC, Nicholas Wilson wrote:
> On Wednesday, 14 November 2018 at 23:22:44 UTC, H. S. Teoh wrote:
>> On Wed, Nov 14, 2018 at 03:09:33PM -0800, Walter Bright via Digitalmars-d wrote:
>>> On 11/14/2018 7:33 AM, rikki cattermole wrote:
>>> > Really butchered. From what I can see they never mentioned D in any of the documents (kinda glad tbh). Those documents even question what it should be doing...
>>> 
>>> The C++ community insists they invented ranges independently from D.
>> [...]
>>
>> That's ridiculous.  Didn't the guy who wrote the C++ range proposal copy the code example from my article on component programming in D?
>>
>>
>> T
>
> Yep, the calendar one. TBF, you were in the list of citations for that talk.

https://www.youtube.com/watch?v=mFUXNMfaciE&feature=youtu.be?t=123

On Wednesday, 14 November 2018 at 15:07:46 UTC, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/
>
> By 2020 C++ is planning to introduce:
>
> * Ranges
> * Contracts
> * Concepts (`__traits`)
> * Proper constexpr
> * Modules
> * Reflections
> * Green threads
>
> Right now it already has:
>
> * `auto` variables
> * Ranged for (`foreach`)
> * Lambda expressions and closures
> * `nothrow` attributes
> * Proper containers
> * Proper RAII
>
> In no way this is the usual trollpost (I am a participant of SAoC). What bugs me is the shortening distance regarding what D has to offer with respect to C++. While D for sure has a way better syntax (thinking of template declarations, `immutable`, UDAs) and a GC, what are the advantages of using D vs C++ if my goal is to build a complex system / product?
>
> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

I've been in the community since 2014 and occasionally monitor the kind of developers using D. D might not be the hype out there but its a very solid language  from a software engineering perspective. People from very important companies (I mean well known companies people depend on and use their software) are starting to use D day by day. Its slowly moving.


We can count features but at the end of the day, what conveniently get the job done is what matters. Its impractical for companies to leave their legacy code since C++ is already in use, hence their attention to those languages. But D is maturing both in tools, libraries/packages and stability/reliability...making it a valid alternative to consider when starting afresh or where it makes sense to even port or integrate D into legacy code...D is powerful enough for all that.

End of the day, I believe having a community is D's greatest strength.


Aberba,
Ghana, West Africa.
Github.com/aberba

On 11/14/18 4:07 PM, lagfra wrote:
> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/ 
> 
> 
> By 2020 C++ is planning to introduce:
> 
> * Ranges
> * Contracts
> * Concepts (`__traits`)
> * Proper constexpr
> * Modules
> * Reflections
> * Green threads
> 
> Right now it already has:
> 
> * `auto` variables
> * Ranged for (`foreach`)
> * Lambda expressions and closures
> * `nothrow` attributes
> * Proper containers
> * Proper RAII
> 
> In no way this is the usual trollpost (I am a participant of SAoC). What bugs me is the shortening distance regarding what D has to offer with respect to C++. While D for sure has a way better syntax (thinking of template declarations, `immutable`, UDAs) and a GC, what are the advantages of using D vs C++ if my goal is to build a complex system / product?
> 
> TL;DR: what will D offer with respect to C++ when almost all key features of D are present in C++20(+)?

Thanks for asking. Saw several good answers, to which I feel compelled to add the following.

I just delivered the opening keynote for Meeting C++ (https://meetingcpp.com/2018/Schedule.html). The video will come about in a few days. There's a bit of a twitter storm going about.

I think C++ is not properly equipped for the next big thing, which is Design by Introspection. C++ has a history of poorly copying features from D while missing their core point, which makes the import much more difficult to use. The example I give in the talk is that C++ initially rejected everything and anything about static if, to then implement it under a different name ("whatever it is, make sure it's not static if!") and entirely missing the point by having if constexpr insert a new scope (whereby NOT introducing the scope is the entire point of the feature in the first place).

So going through the motions is far from achieving real parity. At the same time C++ is spending a lot of real estate on language features of minor impact (concepts) or mere distractions (metaclasses), both of which aim squarely not at solving difficult issues in problem space, but to patch for difficulties created by the language itself.


Andrei

Some in this thread have pointed out that D's templates are easier.

But I believe Bjarne is involved in making it so that you can just put "auto" or a concept like Itegral in a function argument and it will automatically become a template.

If that's true even templates will be more concise in C++.