www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++17 is feature complete

reply Enamex <enamex+d outlook.com> writes:
https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/

Added stuff like:
   - a very limited destructuring syntax (structured bindings) 
(use case is for tuples; but likely to use a new reserved 
function name for general struct destructuring (like 'get<>()' or 
something);
   - template arguments that accept constant values of any type 
whatsoever 'template<auto Arg>';
   - 'constexpr if';
   - specified order of evaluation for function calls and any 
syntax with arguments (including built-in operators on primitive 
types).
Jun 26 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:

 https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/

 Added stuff like:
   - a very limited destructuring syntax (structured bindings) 
 (use case is for tuples; but likely to use a new reserved 
 function name for general struct destructuring (like 'get<>()' 
 or something);
   - template arguments that accept constant values of any type 
 whatsoever 'template<auto Arg>';
   - 'constexpr if';
   - specified order of evaluation for function calls and any 
 syntax with arguments (including built-in operators on 
 primitive types).


Please be excited for modules, coming out three years from now 
(plus implementation time).
Jun 26 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 26 June 2016 at 18:16:32 UTC, Jack Stouffer wrote:

 Please be excited for modules, coming out three years from now 
 (plus implementation time).


It is actually a good thing that they delay modules. It is 
difficult to get right, but it is on a separate track so it can 
come before C++Next.

The most important parts of C++17 is related to ironing out 
language quirks and providing library additions: some significant 
improvements to meta-programming, file system support and C11 
support which brings in things like aligned_alloc.

There is a significant signal in reserving the namespace 
"std"+digits, meaning there will be a major standard library 
update in C++Next (related to "ranges").
Jun 26 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:

   - specified order of evaluation for function calls and any 
 syntax with arguments (including built-in operators on 
 primitive types).


But not on the arguments, as that will harm optimization too 
much. I believe this change was triggered by the lack of 
transparency in expressions with more complicated "chaining" of 
function calls/function-objects.

So in "expr1(expr2,expr3)" expr1 is evaluated first, but expr2 
and expr3 can be evaluated in any order. Right?
Jun 26 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type whatsoever
 'template<auto Arg>';


Still adding D features, I see!
Jun 26 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2016 3:32 PM, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


Reading:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html

shows it is something else.
Jun 26 2016
prev sibling next sibling parent mogu <mogucpp 163.com> writes:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type 
 whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


Now cpp has structured bindings although it's a limited version 
of match. So when will DIP32 and match be taken into 
consideration in D?
Jun 26 2016
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type 
 whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


Imitation is the sincerest form of flattery, so when is 
destructuring coming to D?

Also, the `if (init; condition) and switch (init; condition)` 
seems like a very nice idea.
Jun 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 Imitation is the sincerest form of flattery, so when is 
 destructuring coming to D?

 Also, the `if (init; condition) and switch (init; condition)` 
 seems like a very nice idea.


It's from Go,  I don't see much value in it. You can just wrap 
the if in a block:

{
   init;
   if(condition)…
}

That is usually more readable IMO.
Jun 26 2016
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 27 June 2016 at 06:52:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 Imitation is the sincerest form of flattery, so when is 
 destructuring coming to D?

 Also, the `if (init; condition) and switch (init; condition)` 
 seems like a very nice idea.


 It's from Go,  I don't see much value in it. You can just wrap 
 the if in a block:

 {
   init;
   if(condition)…
 }

 That is usually more readable IMO.


No, it's the logical conclusion from the for(init; condition; 
increment) loop and the declare a variable anywhere feature, 
introduced in C++ long time ago.

It's funny that C++ now will introduce it, as I had the same idea 
a couple of weeks ago for C. I'm currently in the process of 
transforming old legacy C code that had all their variables 
declared at the top, to a more modern style, using C99 feature 
taken from C++, i.e. vars only declared and initialized when they 
are used and using for(initdeclaration;...) style.
It appeared quite rapidly that in a lot of cases the if(init; and 
switch(init; would have been nice as it would have brought a lot 
of regularity in the code and it allows to limit the scope of a 
temporary variable really to the section it is used in without 
overloading the code with { and }.

btw: I was first quite skeptical of the gain to be had of that 
scope reduction transformation, but after discovering several 
serious bugs in our code because of scope errors, I am now 
transforming more systematically to that style our 200K lines of 
C code.
Jun 27 2016
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 27 June 2016 at 06:52:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 Imitation is the sincerest form of flattery, so when is 
 destructuring coming to D?

 Also, the `if (init; condition) and switch (init; condition)` 
 seems like a very nice idea.


 It's from Go,  I don't see much value in it. You can just wrap 
 the if in a block:

 {
   init;
   if(condition)…
 }

 That is usually more readable IMO.


I forgot. No it's not more readable, to the contrary. The issue 
is that normally { } introduces an indentation, which is always 
associated with some kind of branching. Adding an indentation 
just for the declaration of a variable is an inconsistency 
annoying to read. I had the case several times in the code I was 
transforming and it had me each time puzzled at where the loop or 
condition was.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 14:57:10 UTC, Patrick Schluter wrote:

 I forgot. No it's not more readable, to the contrary. The issue 
 is that normally { } introduces an indentation, which is always 
 associated with some kind of branching. Adding an indentation 
 just for the declaration of a variable is an inconsistency 
 annoying to read. I had the case several times in the code I 
 was transforming and it had me each time puzzled at where the 
 loop or condition was.


I see your point, but I like to keep conditional clean. Usually 
the expression is long when  I have to check an error code in 
C++. I don't think the following is easy on my eyes and it is not 
at all clear where the destructor is called:

if ( auto file = 
::tool::filesystem::open("/path/to/somewhere/xx"); file != 
nullptr) {
    ...
}  else if(…) {
     ...
} else {
     ...
}

I think this is easier to read, and the location for the 
destruction is obvious:

{
     auto file = ::tool::filesystem::open("/path/to/somewhere/xx");

     if ( file != nullptr ) {
        ...
     }  else if(…) {
        ...
     } else {
        ...
     }
}

In modern C++ one has to think about introducing scopes to gain 
control over where RAII is created and destructed.
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 15:16:19 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 14:57:10 UTC, Patrick Schluter wrote:

 I forgot. No it's not more readable, to the contrary. The 
 issue is that normally { } introduces an indentation, which is 
 always associated with some kind of branching. Adding an 
 indentation just for the declaration of a variable is an 
 inconsistency annoying to read. I had the case several times 
 in the code I was transforming and it had me each time puzzled 
 at where the loop or condition was.


 I see your point, but I like to keep conditional clean. Usually 
 the expression is long when  I have to check an error code in 
 C++. I don't think the following is easy on my eyes and it is 
 not at all clear where the destructor is called:

 if ( auto file = 
 ::tool::filesystem::open("/path/to/somewhere/xx"); file != 
 nullptr) {
    ...
 }  else if(…) {
     ...
 } else {
     ...
 }

 I think this is easier to read, and the location for the 
 destruction is obvious:

 {
     auto file = 
 ::tool::filesystem::open("/path/to/somewhere/xx");

     if ( file != nullptr ) {
        ...
     }  else if(…) {
        ...
     } else {
        ...
     }
 }

 In modern C++ one has to think about introducing scopes to gain 
 control over where RAII is created and destructed.


Modern C++ is a train-wreck, I don't think we should consider D 
features around the flaws of another language.

Luckily we don't have to code with the worry of labyrinth like 
namespaces so deep and bloated that the language needs a special 
keyword to let the compiler know that the following blobby mass 
is a typename.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 15:43:03 UTC, luminousone wrote:

 Modern C++ is a train-wreck, I don't think we should consider D 
 features around the flaws of another language.


RAII is the same in C++, but actually better supported in C++ atm.


 Luckily we don't have to code with the worry of labyrinth like 
 namespaces so deep and bloated that the language needs a 
 special keyword to let the compiler know that the following 
 blobby mass is a typename.


Namespaces tend to be shallow, not deep. "typename" is a syntax 
compatibility issue, not a namespace issue. I don't think I 
understand your argument?

But if D keeps adding syntactical sugar and many ways of doing 
the same thing like C++, it will end up in the same bloated spot 
with no hope of recovery.
Jun 27 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 15:49:20 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 15:43:03 UTC, luminousone wrote:

 Modern C++ is a train-wreck, I don't think we should consider 
 D features around the flaws of another language.


 RAII is the same in C++, but actually better supported in C++ 
 atm.


I meant: Issues around RAII are the same in D as in C++.
Jun 27 2016
prev sibling next sibling parent reply luminousone <rd.hunt gmail.com> writes:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type 
 whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


Now if only they could bring over some of D's superior template 
syntax, all of the <>'s are so damned ugly, Or type reflection 
features(is this even possible in c++?).
Jun 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 Now if only they could bring over some of D's superior template 
 syntax, all of the <>'s are so damned ugly, Or type reflection 
 features(is this even possible in c++?).


Ugh, D's template syntax is far from superior :-(.

What kind of type reflection are you thinking of? C++ has static 
type traits and some very limited dynamic reflection for classes 
with virtual functions, but C++ is nowhere near Python's 
capabilities.

C++ does have a special interest group working on reflection:

https://root.cern.ch/blog/status-reflection-c
Jun 26 2016
parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 06:16:57 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 Now if only they could bring over some of D's superior 
 template syntax, all of the <>'s are so damned ugly, Or type 
 reflection features(is this even possible in c++?).


 Ugh, D's template syntax is far from superior :-(.

 What kind of type reflection are you thinking of? C++ has 
 static type traits and some very limited dynamic reflection for 
 classes with virtual functions, but C++ is nowhere near 
 Python's capabilities.

 C++ does have a special interest group working on reflection:

 https://root.cern.ch/blog/status-reflection-c


D's template syntax is vastly superior to C++...

C++ has post pended vtable pointers on class objects, its 
unlikely good reflection can ever be added to the language, as 
the vtable may be in a different place in every object their is 
no way to access it universally for object type information. Some 
Compile time type reflection might be possible, But I bet it ends 
up being flimsy.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote:

 C++ has post pended vtable pointers on class objects, its 
 unlikely good reflection can ever be added to the language, as 
 the vtable may be in a different place in every object their is 
 no way to access it universally for object type information. 
 Some Compile time type reflection might be possible, But I bet 
 it ends up being flimsy.


Huh? IIRC it is implementation defined in C++. There are C++ 
compilers/tools that provide more extensive reflection, but it is 
not part of the standard beyond simple typeid reflection.
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 15:59:30 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 15:54:16 UTC, luminousone wrote:

 C++ has post pended vtable pointers on class objects, its 
 unlikely good reflection can ever be added to the language, as 
 the vtable may be in a different place in every object their 
 is no way to access it universally for object type 
 information. Some Compile time type reflection might be 
 possible, But I bet it ends up being flimsy.


 Huh? IIRC it is implementation defined in C++. There are C++ 
 compilers/tools that provide more extensive reflection, but it 
 is not part of the standard beyond simple typeid reflection.


C++ post pended vtable pointers, Are not implementation dependent.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote:

 C++ post pended vtable pointers, Are not implementation 
 dependent.


I don't know what «post pended vtable pointers» means. Which 
section of the C++ spec are you referring to?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 16:10:13 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 16:03:44 UTC, luminousone wrote:

 C++ post pended vtable pointers, Are not implementation 
 dependent.


 I don't know what «post pended vtable pointers» means. Which 
 section of the C++ spec are you referring to?

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf


Member name lookup, Virtual functions, some where in their.

When you declare an object,

class a{
   int b;
   int c;
   //** the compiler puts a hidden variable here called the vtable 
pointer **//
   void **vtble;
   virtual void somefunc();
}

All of your virtual functions are referenced from this table; So 
that inherited classes will call the correct function based on 
the type of said object and the overrides in said object.



and D use the first item in the vtable for type information 
generated by the compiler at compile time. Because the vtable is 
in the same place in ALL objects type reflection is very easy to 
implement. In C++ the exact position of the vtable depends on 
what is in the base most class, it might be 8bytes in, maybe 20, 
maybe 200, you just don't know, And certainly the runtime can't 
know.

Granted their are really bloated, slow, and memory chugging ways 
around this, such as storing a list of every allocated object in 
memory somewhere, and having reflection calls search this using 
an objects memory address.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote:

 easy to implement. In C++ the exact position of the vtable 
 depends on what is in the base most class, it might be 8bytes 
 in, maybe 20, maybe 200, you just don't know, And certainly the 
 runtime can't know.


I know what the usual implementation is, but I don't believe it 
is required by the spec. So it is implementation defined and the 
runtime most certainly can know if that is part of the 
requirement. As I said, you don't even need to use a vtable AFAIK.

Can show me the section in the spec where it is required? I can't 
find it.
Jun 27 2016
next sibling parent reply default0 <Kevin.Labschek gmx.de> writes:
Regarding C++ I found this to be a fun read: 
http://yosefk.com/c++fqa/ :-)
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote:

 Regarding C++ I found this to be a fun read: 
 http://yosefk.com/c++fqa/ :-)


A lot of it makes sense... C++ is what happens when you evolve, 
evolve, evolve and evolve a language from a starting-point that 
was not a high level language, desperately trying to hone it into 
high level shoes... Those shoes will never fit perfectly, 
obviously.

It gets even more expansive when you add inn compiler extensions. 
For instance gcc/clang simd extensions is basically taking in 
parts of OpenCL into C++. In order to figure out how they work 
you have to read the OpenCL spec... I only found out today that I 
can do "simd.even" and "simd.odd" to get even and odd elements 
from a simd register in Clang... after implementing it manually 
first. ;-/
Jun 27 2016
parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 18:58:25 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 18:23:11 UTC, default0 wrote:

 Regarding C++ I found this to be a fun read: 
 http://yosefk.com/c++fqa/ :-)


 A lot of it makes sense... C++ is what happens when you evolve, 
 evolve, evolve and evolve a language from a starting-point that 
 was not a high level language, desperately trying to hone it 
 into high level shoes... Those shoes will never fit perfectly, 
 obviously.

 It gets even more expansive when you add inn compiler 
 extensions. For instance gcc/clang simd extensions is basically 
 taking in parts of OpenCL into C++. In order to figure out how 
 they work you have to read the OpenCL spec... I only found out 
 today that I can do "simd.even" and "simd.odd" to get even and 
 odd elements from a simd register in Clang... after 
 implementing it manually first. ;-/


OpenCL is for micro threading, not simd. OpenCL allows you to run 
thousands of instances of the same function in parallel, in 
either the cpu and/or the gpu.

SIMD or single instruction multiple data, is for instruction 
level parallelism,aka vector add op that adds 4 floats to 4 other 
floats in a single cpu instruction.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 19:39:20 UTC, luminousone wrote:

 OpenCL is for micro threading, not simd.


What is your point? Clang++ vector extensions use OpenCL 
semantics, so you need to look up the OpenCL spec to figure out 
what it supports. It is not well-documented in the Clang 
documentation.

Are you trolling me?
Jun 27 2016
parent reply Enamex <enamex+d outlook.com> writes:
On Monday, 27 June 2016 at 19:47:14 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 19:39:20 UTC, luminousone wrote:

 OpenCL is for micro threading, not simd.


 What is your point? Clang++ vector extensions use OpenCL 
 semantics, so you need to look up the OpenCL spec to figure out 
 what it supports. It is not well-documented in the Clang 
 documentation.

 Are you trolling me?


Please, no need to.

Also, C++17 is 'getting' Modules and Concepts Lite later in tech 
specs... that don't even have working drafts according to this 
[https://isocpp.org/std/status] (but have experimental 
implementations in Clang and VC++, at least).
Jun 28 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 28 June 2016 at 18:50:25 UTC, Enamex wrote:

 On Monday, 27 June 2016 at 19:47:14 UTC, Ola Fosheim Grøstad 
 wrote:

 Are you trolling me?


 Please, no need to.


Huh?  What exactly are you trying to convey?


 Also, C++17 is 'getting' Modules and Concepts Lite later in 
 tech specs... that don't even have working drafts according to 
 this [https://isocpp.org/std/status] (but have experimental 
 implementations in Clang and VC++, at least).


Modules is not part of C++17, it is on a separate track. Concepts 
are also not part of C++17.

Maybe it would be a good idea to not complain so much about 
languages you guys don't know much about.  I suggest focusing on 
making D better instead.
Jun 28 2016
parent reply Enamex <enamex+d outlook.com> writes:
On Tuesday, 28 June 2016 at 19:27:36 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 28 June 2016 at 18:50:25 UTC, Enamex wrote:

 Also, C++17 is 'getting' Modules and Concepts Lite later in 
 tech specs... that don't even have working drafts according to 
 this [https://isocpp.org/std/status] (but have experimental 
 implementations in Clang and VC++, at least).


 Modules is not part of C++17, it is on a separate track. 
 Concepts are also not part of C++17.

 Maybe it would be a good idea to not complain so much about 
 languages you guys don't know much about.  I suggest focusing 
 on making D better instead.


That's what I said. They're not in the C++17 spec but we won't be 
waiting for C++Next for them, hopefully.

And I complained about nothing; and know little about _any_ 
language; still so much to learn.
Jun 29 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 29 June 2016 at 16:38:07 UTC, Enamex wrote:

 That's what I said. They're not in the C++17 spec but we won't 
 be waiting for C++Next for them, hopefully.


Grafting a meaningful module system on top of a 40 years old 
language is full of pitfalls and making the wrong choice would be 
a disaster, so I would not expect to see it production in another 
3+ years...

But I don't really have performance issues related to include 
files. It is more of an annoyance, but you can work around it by 
being careful about what you include and how you structure your 
files (break frequently shared stuff into separate files).

What I do like about where C++ is heading is that they have set 
up a study group for game programmers and low latency programming 
(SG14).

D should do the same. :-P
Jun 29 2016
prev sibling parent reply luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 16:48:16 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 16:38:07 UTC, luminousone wrote:

 easy to implement. In C++ the exact position of the vtable 
 depends on what is in the base most class, it might be 8bytes 
 in, maybe 20, maybe 200, you just don't know, And certainly 
 the runtime can't know.


 I know what the usual implementation is, but I don't believe it 
 is required by the spec. So it is implementation defined and 
 the runtime most certainly can know if that is part of the 
 requirement. As I said, you don't even need to use a vtable 
 AFAIK.

 Can show me the section in the spec where it is required? I 
 can't find it.


Its the nature of being compatible with C, it might not be 
explicitly stated in the spec, but the only place to put the 
vtable pointer and stay compatible with C structs is at the end. 
You will notice in D you can't inherit from a struct, this isn't 
merely design choice.
Jun 27 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote:

 Its the nature of being compatible with C, it might not be 
 explicitly stated in the spec, but the only place to put the 
 vtable pointer and stay compatible with C structs is at the end.


No... You are making way too many assumptions.
Jun 27 2016
parent luminousone <rd.hunt gmail.com> writes:
On Monday, 27 June 2016 at 19:34:18 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 27 June 2016 at 19:32:39 UTC, luminousone wrote:

 Its the nature of being compatible with C, it might not be 
 explicitly stated in the spec, but the only place to put the 
 vtable pointer and stay compatible with C structs is at the 
 end.


 No... You are making way too many assumptions.


By all means believe whatever delusion fits your corner of the 
universe.
Jun 27 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type 
 whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


constexpr if looks a lot like static if to me.
Jun 27 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 28/06/2016 2:19 AM, jmh530 wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any type
 whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 constexpr if looks a lot like static if to me.


You're not alone on that one.
Jun 27 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 27 June 2016 at 14:19:16 UTC, jmh530 wrote:

 On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

 On 6/26/2016 10:18 AM, Enamex wrote:

   - template arguments that accept constant values of any 
 type whatsoever
 'template<auto Arg>';


 Still adding D features, I see!


 constexpr if looks a lot like static if to me.


I don't think it is like static if. AFAIK it cannot turn off 
member fields and it cannot turn off static_asserts.  "if 
constexpr" is primarily for preventing instantiation issues, so 
it does not introduce a separate compilation stage like in D.

In C++ this will fail to compile:

if constexpr(false){
     static_assert(false);
}
Jun 27 2016
prev sibling parent Enamex <enamex+d outlook.com> writes:
Some updates:
https://www.reddit.com/r/cpp/comments/4rj7us/trip_report_c_standards_meeting_in_oulu_june_2016/

Especially interesting are the mentions of 'accepted' 
features/proposals for 'C++20', including:
- `operator.` (opDispatch) which /might/ even make it into C++17 
given push by some international body; also includes some facets 
of `alias this` as it's hoped to be a core part of some of the 
reflection proposals [1]
- designated initializers (from C) (D's static initializers but 
tied to struct names and usable anywhere `MyStruct{ field2: 0, 
field1: 'a' }`;

and some requiring 'further thought' like:
- discriminated unions (even full-blown pattern matching); [2]
- 'overload sets as function arguments' (basically the delegate 
pattern in D for passing a lazily determined member function 
pointer (or an untyped closure in general));
- contracts ('expects = in' and 'ensures = out()' but they take 
one big boolean expression; a bit more complicated than in D, but 
they're adding them in, not taking them out) [3]
- 'parameter packs outside templates' which could go several ways 
from being basically native tuples with dedicated syntax, to 
almost (? not sure about differences in the proposal's 
specification vs behavior in D) the same thing as alias tuples in 
D now. [4]

I tried to focus on stuff already in D and stuff people are 
asking to add to D and the differences between the languages in 
them. I'll stop if it's deemed too off-topic :/

[1] http://wg21.link/p0252
     http://wg21.link/p0352
     http://wg21.link/p0060
[2] http://wg21.link/p0095r1
[3] 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4415.pdf
[4] 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html
Jul 07 2016