On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
[...]
There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher
wrote:
On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
things that would actually help (like IDE
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher
wrote:
I like that. Feature freeze D until *all* bug reports are
closed.
While that would mean no more features for several years, I
think it would benefit the language in the long run, both
internally (less discussions about
On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
things that would actually help (like IDE support) do not get
any attention.
+1, though I'd go for bug-fixing over
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
On Tuesday, 15 August 2017 at 20:17:40 UTC, ag0aep6g wrote:
On 08/15/2017 08:55 PM, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something
On 08/15/2017 08:55 PM, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something similar to that.
Maybe something like this:
int func()
On Tuesday, 15 August 2017 at 19:24:00 UTC, Daniel Kozak wrote:
int func() { return 5; }
int func() return 5;
was a typo in all my previous posts :)
On Tuesday, 15 August 2017 at 19:04:32 UTC, Daniel Kozak wrote:
On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
C++17 will have this feature:
int func() return 5;
with(auto x = func()) if (condition(x))
do_something_with(x);
else
do_something_else_with(x);
this would
On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something similar to
that.
Maybe something like
On 6/6/2017 8:06 PM, Ali Çehreli wrote:
On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
> But it is pretty well known that enum'ing an array can have it allocate
> wherever it is used.
One of the most effective examples is comparing .ptr with (seemingly) itself:
void main() {
enum
On Wednesday, 7 June 2017 at 03:06:34 UTC, Ali Çehreli wrote:
On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
> But it is pretty well known that enum'ing an array can have
it allocate
> wherever it is used.
One of the most effective examples is comparing .ptr with
(seemingly) itself:
On 06/06/2017 08:06 PM, Ali Çehreli wrote:
> enum e = [ 1 ];
> static assert(e.ptr != e.ptr);
> I'm surprised that e.ptr is usable at compile time.
Sorry to notice this late but printing that ptr exposes the copy-paste
behavior of enums:
pragma(msg, e.ptr);
Outputs
&[1][0]
On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
> But it is pretty well known that enum'ing an array can have it allocate
> wherever it is used.
One of the most effective examples is comparing .ptr with (seemingly)
itself:
void main() {
enum e = [ 1 ];
static assert(e.ptr !=
On 6/6/17 8:28 PM, Yuxuan Shui wrote:
On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
I would not have expected enum b = sort(a) to trigger an allocation.
auto b, yes, of course (and the disassembly from that is not much
On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
I would not have expected enum b = sort(a) to trigger an
allocation. auto b, yes, of course (and the disassembly from
that is not much different). So I'd love to see a blog
On Sat, 2017-06-03 at 18:03 +0100, Russel Winder wrote:
> Björn Fahller has done compile time sort in C++17 here http://playful
> pr
> ogramming.blogspot.co.uk/2017/06/constexpr-quicksort-in-c17.html
>
> Surely D can do better?
It may be worthy of note that I stated on Björn's Google+ posting of
On Tuesday, 6 June 2017 at 08:00:11 UTC, Era Scarecrow wrote:
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
I'd say this deserves a blog post but it would be too short.
Actually i wouldn't mind a vlog or some short presentations on
a variety of subjects. Maybe even
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
I'd say this deserves a blog post but it would be too short.
Actually i wouldn't mind a vlog or some short presentations on a
variety of subjects. Maybe even continuations of presentations
that could have been at the
On Saturday, 3 June 2017 at 22:00:56 UTC, Ali Çehreli wrote:
On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
> I'd say this deserves a blog post but it would be too short.
I made many good friends at C++Now. Some of them know Atila
from CppCon and other C++ conferences. (Beer involved. :)
On 2017-06-04 08:18, H. S. Teoh via Digitalmars-d wrote:
Ah, but if you want your function to work both at CTFE and runtime, then
why write `if (__ctfe)` in the first place? :-D
Unless, of course, you're optimizing for runtime with something that's
incompatible with CTFE, like inline assembly
On Sunday, 4 June 2017 at 10:39:09 UTC, rikki cattermole wrote:
Should be a way, since you can pass arg directly via ldc to ld.
But I would expect it to have done it by default anyway.
It is indeed done by default on Windows and Linux. If you dump
the object code before it gets to the linker,
On Sunday, 4 June 2017 at 14:13:24 UTC, Ola Fosheim Grøstad wrote:
On Sunday, 4 June 2017 at 10:27:14 UTC, Vittorio Romeo wrote:
I see. Is there any argument that can be passed to ldc in
order to strip the unused symbols?
Doesn't the strip command work?
Oh wait, you didn't mean symbols, you
On Sunday, 4 June 2017 at 10:27:14 UTC, Vittorio Romeo wrote:
I see. Is there any argument that can be passed to ldc in order
to strip the unused symbols?
Doesn't the strip command work?
On 04/06/2017 11:27 AM, Vittorio Romeo wrote:
On Sunday, 4 June 2017 at 10:21:16 UTC, rikki cattermole wrote:
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; //
On Sunday, 4 June 2017 at 10:21:16 UTC, rikki cattermole wrote:
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3 -release -betterC -flto=full)?
You can see the result on
On Sat, 2017-06-03 at 19:12 +, Steven Schveighoffer via
Digitalmars-d wrote:
> On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
> wrote:
> > On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
> > > Björn Fahller has done compile time sort in C++17 here
> > >
On Sunday, 4 June 2017 at 07:49:36 UTC, Jonathan M Davis wrote:
Be careful, or Mike will start hounding you to write the actual
article. ;)
- Jonathan M Davis
It's already written! And I'm looking for reviewers [1] so I can
get it in shape in time to publish Monday.
[1]
On Saturday, June 03, 2017 22:38:24 H. S. Teoh via Digitalmars-d wrote:
> On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d
wrote:
> > On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
> > > I'd say this deserves a blog post but it would be too short.
> >
> > I made many
On Sun, Jun 04, 2017 at 06:08:28AM +, Stanislav Blinov via Digitalmars-d
wrote:
> On Sunday, 4 June 2017 at 05:38:24 UTC, H. S. Teoh wrote:
>
> > And if you need a particular functionality both at compile-time and
> > during runtime, there's no need to write it twice in two different
> >
On Sunday, 4 June 2017 at 05:38:24 UTC, H. S. Teoh wrote:
And if you need a particular functionality both at compile-time
and during runtime, there's no need to write it twice in two
different sublanguages. You just write one function once, and
call it from both CTFE and at runtime. It Just
On Sunday, 4 June 2017 at 05:12:13 UTC, Jonathan M Davis wrote:
As the enum has no address, it can't store anything. So,
_anything_ that's an enum is going to be effectively
copy-pasted everywhere that it's used. The compiler is smart
enough to just copy-past the result and not the
On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
>
> > I'd say this deserves a blog post but it would be too short.
>
> I made many good friends at C++Now. Some of them know Atila from
> CppCon and other C++
On Sunday, June 04, 2017 04:47:56 Mike Parker via Digitalmars-d wrote:
> On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
> > On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
> >> I would not have expected enum b = sort(a) to trigger an
> >> allocation. auto b, yes, of course
On Sunday, 4 June 2017 at 04:47:56 UTC, Mike Parker wrote:
On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
I thought that assigning the result of a function call to an
enum would force a compile-time evaluation of the function, so
I would expect enum b = call(lit) to be
On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
I would not have expected enum b = sort(a) to trigger an
allocation. auto b, yes, of course (and the disassembly from
that is not much different). So I'd love to see a blog
On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
I would not have expected enum b = sort(a) to trigger an
allocation. auto b, yes, of course (and the disassembly from
that is not much different). So I'd love to see a blog post
explaining it.
I don't think I can do a full-on blog
On Sunday, 4 June 2017 at 03:28:32 UTC, Andrei Alexandrescu wrote:
On 06/03/2017 07:41 PM, jmh530 wrote:
On Saturday, 3 June 2017 at 22:18:06 UTC, Timon Gehr wrote:
There is no mistake. (But 'auto' is redundant.)
void main() {
import std.algorithm, std.stdio;
enum a = [ 3, 1, 2,
On Saturday, 3 June 2017 at 23:41:37 UTC, jmh530 wrote:
On Saturday, 3 June 2017 at 22:18:06 UTC, Timon Gehr wrote:
There is no mistake. (But 'auto' is redundant.)
void main() {
import std.algorithm, std.stdio;
enum a = [ 3, 1, 2, 4, 0 ];
enum b = sort(a);// static is not CT
On 06/03/2017 07:41 PM, jmh530 wrote:
On Saturday, 3 June 2017 at 22:18:06 UTC, Timon Gehr wrote:
There is no mistake. (But 'auto' is redundant.)
void main() {
import std.algorithm, std.stdio;
enum a = [ 3, 1, 2, 4, 0 ];
enum b = sort(a);// static is not CT !
static
On Saturday, 3 June 2017 at 20:29:04 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 20:18:59 UTC, Basile B. wrote:
On Saturday, 3 June 2017 at 18:45:56 UTC, Jacob Carlborg wrote:
On 2017-06-03 20:31, Russel Winder via Digitalmars-d wrote:
But is this sort guaranteed to happen at
On Saturday, 3 June 2017 at 22:18:06 UTC, Timon Gehr wrote:
There is no mistake. (But 'auto' is redundant.)
void main() {
import std.algorithm, std.stdio;
enum a = [ 3, 1, 2, 4, 0 ];
enum b = sort(a);// static is not CT !
static assert(b[0] == 0); // does not pass with
On 03.06.2017 22:16, Basile B. wrote:
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer wrote:
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17
On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
> I'd say this deserves a blog post but it would be too short.
I made many good friends at C++Now. Some of them know Atila from CppCon
and other C++ conferences. (Beer involved. :) ) They told me Atila would
routinely tell them during C++
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here
http://playfulpr
On Saturday, 3 June 2017 at 21:04:16 UTC, ag0aep6g wrote:
On 06/03/2017 10:29 PM, Stanislav Blinov wrote:
Meep. Wrong :)
Static initializers for static variables and constants are
evaluated at compile time, initializing them with runtime
values is a compile-time error.
Meep. Meep. I
On 06/03/2017 10:29 PM, Stanislav Blinov wrote:
Meep. Wrong :)
Static initializers for static variables and constants are evaluated at
compile time, initializing them with runtime values is a compile-time
error.
Meep. Meep. I wouldn't say you're wrong, but there's nitpicking to be done.
On Saturday, 3 June 2017 at 20:18:59 UTC, Basile B. wrote:
On Saturday, 3 June 2017 at 18:45:56 UTC, Jacob Carlborg wrote:
On 2017-06-03 20:31, Russel Winder via Digitalmars-d wrote:
But is this sort guaranteed to happen at compile time rather
than
runtime?
Yes. It's the context that
On Saturday, 3 June 2017 at 18:45:56 UTC, Jacob Carlborg wrote:
On 2017-06-03 20:31, Russel Winder via Digitalmars-d wrote:
But is this sort guaranteed to happen at compile time rather
than
runtime?
Yes. It's the context that decides if it occurs at compile time
or at runtime.
Something
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here
http://playfulpr
On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer
wrote:
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here
http://playfulpr
On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
wrote:
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here
http://playfulpr
ogramming.blogspot.co.uk/2017/06/constexpr-quicksort-in-c17.html
Surely D can do better?
On 2017-06-03 20:31, Russel Winder via Digitalmars-d wrote:
But is this sort guaranteed to happen at compile time rather than
runtime?
Yes. It's the context that decides if it occurs at compile time or at
runtime.
Something declared as "static" or "enum" requires that the value can be
On Saturday, 3 June 2017 at 18:31:37 UTC, Russel Winder wrote:
On Sat, 2017-06-03 at 13:32 -0400, Andrei Alexandrescu via
Digitalmars- d wrote:
[…]
There is nothing to do really. Just use standard library sort.
void main() {
import std.algorithm, std.stdio;
enum a = [ 3, 1, 2,
On Sat, 2017-06-03 at 13:32 -0400, Andrei Alexandrescu via Digitalmars-
d wrote:
> […]
>
> There is nothing to do really. Just use standard library sort.
>
> void main() {
> import std.algorithm, std.stdio;
> enum a = [ 3, 1, 2, 4, 0 ];
> static auto b = sort(a);
>
On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
Björn Fahller has done compile time sort in C++17 here http://playfulpr
ogramming.blogspot.co.uk/2017/06/constexpr-quicksort-in-c17.html
Surely D can do better?
There is nothing to do really. Just use standard library sort.
void
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
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
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
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
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
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
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
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
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.
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,
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,
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
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
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?
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
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
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
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
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
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
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
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';
Still adding D features, I see!
constexpr if
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
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
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';
Still adding D features, I see!
constexpr if looks a lot like static
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';
Still adding D features, I see!
constexpr if looks a lot like static if to me.
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';
Still adding D features, I see!
Imitation is the
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';
Still adding D features, I see!
Now if only
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';
Still adding D features, I see!
Now if only they could bring over some of D's superior template
syntax,
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';
Still adding D features, I see!
Imitation is the sincerest form of flattery, so when is
destructuring
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';
Still adding D features, I see!
Now cpp has structured bindings although it's a limited version
of
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';
Still adding D features, I see!
Reading:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html
shows it is
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type whatsoever
'template';
Still adding D features, I see!
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
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
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
https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/
Mentions D.
On Friday, 29 January 2016 at 10:43:08 UTC, Ola Fosheim Grøstad
wrote:
https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/
Mentions D.
Since it is in danish, let me quickly translate the informative
sections:
Bjarne Stroustrup (translated from danish): The safety
On Friday, 29 January 2016 at 11:08:41 UTC, Ola Fosheim Grøstad
wrote:
On garbage collection:
Bjarne Stroustrup (translated from danish): Yes, programming
language creators and researchers have always been fascinated
by garbage collection. I think that is a mistake: GC is not
general - it
1 - 100 of 204 matches
Mail list logo
