http://nwcpp.org/
All are invited.
Now I just have to write the presentation :-(
https://issues.dlang.org/show_bug.cgi?id=13936
Issue ID: 13936
Summary: groupBy must be redone
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
It's like this: ref is a massive problem when it finds it's way
into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we
infer
scope (which we'll probably need to), chances are, the vast
majority
of functions will
On 4 Jan 2015 08:35, Joakim via Digitalmars-d digitalmars-d@puremagic.com
wrote:
This is an idea I've been kicking around for a while, and given the need
for commercial support for D, would perhaps work well here.
The notion is that individual developers could work on patches to fix
bugs or
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
There are a few annoying limitations, such that it uses dmd's error printing
and allocation functions,
On 5/01/2015 2:07 a.m., Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
There are a few annoying limitations, such that it uses dmd's
Rikki Cattermole wrote in message news:m8be2m$1dlp$1...@digitalmars.com...
I saw that. I'm really looking forward to getting my teeth into it and
doing some good old refactoring. Although that will be a while because
of the auto generated thing.
There's plenty of refactoring to be done on
Le 01/01/2015 07:38, Manu via Digitalmars-d a écrit :
I've been working on a pretty comprehensive module for dealing with
colours in various formats and colour spaces and conversions between
all of these.
It seems like a hot area for duplicated effort, since anything that
deals with multimedia
On Sunday, 4 January 2015 at 04:43:17 UTC, Jonathan Marler wrote:
The problem I see is that in almost all cases the
opEquals(Object) method will have to perform a cast back to the
original type at runtime. The problem is this isn't doing any
useful work. The current '==' operator passes the
On Sunday, 4 January 2015 at 03:37:05 UTC, Andrei Alexandrescu
wrote:
By the way, I think `typeid(a) == typeid(b)` is silly. It calls
object.opEquals on the `typeid`s. And if they're not
identical, that in
turn calls object.opEquals on the `typeid`s of the `typeid`s.
That
fortunately hits the
On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 4 Jan 2015 08:35, Joakim via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
This is an idea I've been kicking around for a while, and
given the need
for commercial support for D, would perhaps work well
On Friday, 2 January 2015 at 14:27:11 UTC, Jack wrote:
For newcomers doing the jump from C++ to D and current D users,
wanting to program on windows, the missing windows import files
are like a major step back. In C++ you got the full headers
stuff - ready to use.
The incomplete
On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
It requires a `final bool opEquals(SameClass other)` method to
avoid the virtual call.
`final bool opEquals(Object)` is enough, no?
On Sunday, 4 January 2015 at 05:17:10 UTC, Martin Nowak wrote:
+1 definitely makes sense, can you file an enhancement request
https://issues.dlang.org
https://issues.dlang.org/show_bug.cgi?id=13933
On Sunday, 4 January 2015 at 15:02:39 UTC, anonymous wrote:
On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
It requires a `final bool opEquals(SameClass other)` method to
avoid the virtual call.
`final bool opEquals(Object)` is enough, no?
No, then you'd still need a dynamic
On Sunday, 4 January 2015 at 06:04:38 UTC, Manu via Digitalmars-d
wrote:
I wonder if the code can still run against the builtin GC to
reproduce
the original problem?
OK, will have a look.
Ali, thanks for example, I understood it, but I am still can't
understand how to write code above without passing this as
parameter...
On 01/04/2015 09:31 AM, Joakim wrote:
The notion is that individual developers could work on patches to fix
bugs or add features to ldc/druntime/phobos then sell those closed
patches to paying customers. After enough time has passed, so that
sufficient customers have adequately paid for the
On 4 January 2015 at 14:50, Joakim via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 4 January 2015 at 11:17:08 UTC, Iain Buclaw via Digitalmars-d
wrote:
On 4 Jan 2015 08:35, Joakim via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
This is an idea I've been kicking around
On 01/04/2015 04:50 AM, Mike wrote:
On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:
What changes did you have in mind? When I played with it, it was
mostly using the C-like subset, but I still think it was worth it
because bits like operator overloading and slicing are really
Kiith-Sa wrote in message news:nffxogzwpmayydyom...@forum.dlang.org...
(sorry if you get this question too often)
How is DDMD as a whole going? Is it getting closer or are ongoing DMD
changes slowing it down too much?
It's been sitting still for 8 nearly months because of
On Sunday, 4 January 2015 at 15:15:09 UTC, Martin Nowak wrote:
On Sunday, 4 January 2015 at 15:02:39 UTC, anonymous wrote:
On Sunday, 4 January 2015 at 05:24:09 UTC, Martin Nowak wrote:
It requires a `final bool opEquals(SameClass other)` method
to avoid the virtual call.
`final bool
On Saturday, 27 December 2014 at 09:53:42 UTC, Iain Buclaw wrote:
For a more practical example, I've added an example jit
compiled brainf*** interpreter.
https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d
Another practical example has been published which implements a
made up
This is an idea I've been kicking around for a while, and given
the need for commercial support for D, would perhaps work well
here.
The notion is that individual developers could work on patches to
fix bugs or add features to ldc/druntime/phobos then sell those
closed patches to paying
On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
Two big benefits come out of this approach. Obviously, this
would provide commercial support for paying customers, but the
other big benefit is that it doesn't depend on some company
providing that support. A decentralized group of
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Now it resizes the screen successfully, but I feel like I've failed by
using extern (C) nothrow. Shouldn't Derelict GLFW be providing a D
interface?
Maybe GLFW callback functions can't handled through Derelict GLFW?
Derelict provides direct bindings,
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Maybe GLFW callback functions can't handled through Derelict GLFW?
And just to be clear, because the pointers to the callback functions are
being passed to a C API, they *have* to be extern( C ) -- i.e. they have
to have the same calling convention
Manu:
I've run into this many times in the past too... never really
thought
on it whether it's a problem that could actually be solved.
Sometimes one way to realize you have a problem worth trying to
solve is to push your mind sideways to a more naive state (in my
original post in this
On 03/01/15 15:42, Adam D. Ruppe via Digitalmars-d wrote:
I've heard this a few times before over the years, and it hasn't happened yet.
Perhaps we're not growing at the the necessary rapid rate, but I think new
people try to blend into what they see other people doing, so as long as at any
thanx, i will try it. when the headers go to the release version
of D, than it would be a great time to adapt dlf. maybe one
should do that with these headers of yours wright now.
On Sunday, 4 January 2015 at 14:58:23 UTC, FrankLike wrote:
On Friday, 2 January 2015 at 14:27:11 UTC, Jack
Hey folks,
I've been recently checking out Nim/rod and feel like it takes a
lot of inspiration from D (I think the creator was in the D
community too as some point). How do you think it compares? What
areas does D, in principle, makes it a better choice? To give you
my background, I like
On 2015-01-04 18:10:51 +, Jonathan said:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes a lot of
inspiration from D (I think the creator was in the D community too as
some point). How do you think it compares? What areas does D, in
principle, makes it a better
It's compiling to C, I suppose it should be much easier to port
to other platforms than for example D?
On Sunday, 4 January 2015 at 17:18:22 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 4 January 2015 at 14:50, Joakim via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Annoyance also extends out to maintainers too (I could write a
book
about Where DMD went wrong? Some more of DMD's greatest
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes
a lot of inspiration from D (I think the creator was in the D
community too as some point). How do you think it compares?
What areas does D, in principle,
On Sunday, 4 January 2015 at 19:06:34 UTC, weaselcat wrote:
AFAIK nim has a much better GC implementation for soft
real-time applications because it can be paused.
What about GC.disable?
https://github.com/Laeeth/d_rss/
d_rss: D Programming Language bindings for libmRSS.
http://www.autistici.org/bakunin/libmrss/doc/
mRss is a C library written by Andrea Marchesini for parsing,
writing and
creating RSS/ATOM files or streams.
This library supports:
RSS 0.91 -
On 2015-01-04 14:07, Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
This is very cool :), keep up to good work.
--
/Jacob Carlborg
I've created a dub package for the D version of DMD's lexer,
generated automatically from the C++ source.
very cool.
on a related note, have you considered sharing your translation
tool (c++ - D)? I completely understand if you would rather not
of course.
Laeeth.
Am Sun, 04 Jan 2015 18:25:32 +0100
schrieb Martin Nowak code+news.digitalm...@dawg.eu:
On 01/04/2015 04:50 AM, Mike wrote:
On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe wrote:
What changes did you have in mind? When I played with it, it was
mostly using the C-like subset, but
On Sunday, 4 January 2015 at 17:27:57 UTC, Daniel Murphy wrote:
Kiith-Sa wrote in message
news:nffxogzwpmayydyom...@forum.dlang.org...
(sorry if you get this question too often)
How is DDMD as a whole going? Is it getting closer or are
ongoing DMD changes slowing it down too much?
It's
On 1/3/2015 8:21 PM, Manu via Digitalmars-d wrote:
template function(Arg)
{
@uda(Arg) void function() { ... }
}
Ah, interesting. I've never written a template function like that.
Hmmm, is that how code is rewritten when compiling? If so, why doesn't
it just work already?
The stuff
On Sunday, 4 January 2015 at 15:37:53 UTC, Suliman wrote:
Ali, thanks for example, I understood it, but I am still can't
understand how to write code above without passing this as
parameter...
But now I think that possible is mess architecture of app if I
meet such problem...
On Sunday, 4 January 2015 at 09:02:48 UTC, Mike Parker wrote:
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Maybe GLFW callback functions can't handled through Derelict
GLFW?
And just to be clear, because the pointers to the callback
functions are being passed to a C API, they *have* to be
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes
a lot of inspiration from D (I think the creator was in the D
community too as some point). How do you think it compares?
What areas does D, in principle,
On 1/4/15 3:10 PM, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes a lot of
inspiration from D (I think the creator was in the D community too as
some point). How do you think it compares? What areas does D, in
principle, makes it a better choice? To
On 1/4/2015 5:07 AM, Daniel Murphy wrote:
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
Great! Thank you!
I will say that Nim's documentation is severely lacking, even
compared to D. For example, it took me far more time figuring out
Nim's file io operations.
Thanks I will try it. It seems really cool. Maybe my new
favorite language.
On 5 January 2015 at 01:26, Martin Nowak via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 4 January 2015 at 06:04:38 UTC, Manu via Digitalmars-d wrote:
I wonder if the code can still run against the builtin GC to reproduce
the original problem?
OK, will have a look.
Recall
Ary Borenszweig:
But now to make the code fast you have to annotate things with
pure nothrow @safe to make sure the compiler generates fast
code.
Do you have any proof of this?
Nim has 363 issues accoring to
https://github.com/Araq/Nim/issues . D has 2444 according to
So are Nim
On Sunday, 4 January 2015 at 22:55:52 UTC, bearophile wrote:
Nim has 363 issues accoring to
https://github.com/Araq/Nim/issues . D has 2444 according to
So are Nim developers still in need to find more than two
thousand unknown issues? ;-)
I agree, it's more likely that there are more
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:
On 1/4/15 3:10 PM, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes
a lot of
inspiration from D (I think the creator was in the D community
too as
some point). How do you think it
On Wednesday, 31 December 2014 at 13:11:39 UTC, filcuc wrote:
Hi all,
i'll like to share my project for building the bindings for QML
in both D and Nim programming languages.
The project is young and it's not complete, however at the
current state slots, signals and properties can be exposed
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes
a lot of inspiration from D (I think the creator was in the D
community too as some point). How do you think it compares?
What areas does D, in principle,
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:
There are examples of D code in these two repos:
https://github.com/logicchains/LPATHBench
https://github.com/kostya/benchmarks
Take a look at for example the first one in D and Nim:
On 1/4/2015 1:46 PM, Ary Borenszweig wrote:
There are examples of D code in these two repos:
https://github.com/logicchains/LPATHBench
https://github.com/kostya/benchmarks
Nim is faster than D. And it does so with much less code.
You could write the D version with about the same lines of
On 01/04/2015 07:37 AM, Suliman wrote:
how to write code above without passing this as parameter...
For reference, here is your code:
http://www.everfall.com/paste/id.php?a5pp73ns1e4k
There is nothing fundamentally wrong in a class constructor passing
'this' to an object that it
On 5/01/2015 9:30 a.m., WhatMeWorry wrote:
On Sunday, 4 January 2015 at 09:02:48 UTC, Mike Parker wrote:
On 1/4/2015 1:34 PM, WhatMeWorry wrote:
Maybe GLFW callback functions can't handled through Derelict GLFW?
And just to be clear, because the pointers to the callback functions
are being
On 5/01/2015 2:39 a.m., Daniel Murphy wrote:
Rikki Cattermole wrote in message news:m8be2m$1dlp$1...@digitalmars.com...
I saw that. I'm really looking forward to getting my teeth into it and
doing some good old refactoring. Although that will be a while because
of the auto generated thing.
Walter Bright:
Nim:
for neighbour in nodes[nodeId].neighbours:
D:
foreach(immutable route neighbour; nodes[nodeID].neighbours){
Correctly written D:
foreach (neighbour; nodes[nodeID].neighbours){
I don't agree, the good D way is:
foreach (immutable neighbour;
On 04/01/15 22:46, Ary Borenszweig via Digitalmars-d wrote:
According to the writeup:
https://github.com/logicchains/LPATHBench/blob/master/writeup.md
Nim is faster than D. And it does so with much less code.
Meh, if you compare the code in detail you realize (i) the D example wastes a
lot
On Saturday, January 03, 2015 19:37:16 Andrei Alexandrescu via Digitalmars-d
wrote:
On 1/3/15 7:23 PM, anonymous wrote:
For reference, here is .object.opEquals (according to documentation[1]):
bool opEquals(Object a, Object b)
{
if (a is b) return true;
if (a is null || b
On a subjective note, I've always felt that D gets me as a
developer. This is extremely subjective, but I found that in many
cases I could just write code without consulting documentation
when I was learning the language. Even talking about the
immutable For statement, I discovered this by
On 1/4/2015 1:46 PM, Ary Borenszweig wrote:
Nim is faster than D.
I bet the D version would be significantly faster if you didn't read the file as
a text string, then try breaking it up into an array of lines, then break those
lines up into an array of strings, etc. This is a lot of memory
On Monday, 5 January 2015 at 00:50:57 UTC, Brian Schott wrote:
http://i.imgur.com/k50dFbU.png
Some notes:
1) If you use D-Scanner or DCD on a regular basis, you really
should compile it with gdc or ldc.
2) Everybody can guess which module 14 is.
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
X-axis: Meaningless (Phobos module file names)
Y-axis: Time in hnsecs (Lower is better)
I had to hack the ddmd code to get it compile (more 1337 h4x
were required to compile with LDC than with DMD), so I
On 05/01/15 01:53, Walter Bright via Digitalmars-d wrote:
I bet the D version would be significantly faster if you didn't read the file as
a text string, then try breaking it up into an array of lines, then break those
lines up into an array of strings, etc. This is a lot of memory allocation.
On Monday, 5 January 2015 at 00:54:45 UTC, Walter Bright wrote:
On 1/4/2015 1:46 PM, Ary Borenszweig wrote:
Nim is faster than D.
I bet the D version would be significantly faster if you didn't
read the file as a text string, then try breaking it up into an
array of lines, then break those
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes
a lot of inspiration from D (I think the creator was in the D
community too as some point).
I'm pretty sure that D was not a big inspiration to Nim, even
On Monday, 5 January 2015 at 01:12:29 UTC, Brian Rogoff wrote:
Nim's parametric polymorphism is less powerful than D's I think
(the words 'generic' and 'template' are used differently in the
two communities so I'll try and be extra clear) but Nim has a
powerful macro system and a (still
On 1/4/2015 5:07 PM, weaselcat wrote:
It doesn't time that part
You're right, I overlooked that.
You can also speed things up by noticing that the nodes[] and visited[]
arguments never change, so getLongestPath can be made as a nested function with
those arrays as locals in the enclosing
On Monday, 5 January 2015 at 01:07:07 UTC, weaselcat wrote:
Compiled it with LDC, GDC and DMD seem to choke on the
functional programming and run 4-5x slower.
~1120 ms with my version, ~1210 ms with the 'fast' version
the C++ version compiled with gcc still beats it by about 100ms
on my
On 1/4/15 8:32 PM, Elie Morisse wrote:
On Sunday, 4 January 2015 at 18:10:52 UTC, Jonathan wrote:
- No conditional evaluation of code
It has 'when', which is similar to static if. I would say that's
conditional evaluation of code.
On 1/4/15 9:27 PM, bearophile wrote:
Walter Bright:
Nim:
for neighbour in nodes[nodeId].neighbours:
D:
foreach(immutable route neighbour; nodes[nodeID].neighbours){
Correctly written D:
foreach (neighbour; nodes[nodeID].neighbours){
I don't agree, the good D way is:
foreach
On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:
On 01/04/2015 04:50 AM, Mike wrote:
On Saturday, 3 January 2015 at 14:14:42 UTC, Adam D. Ruppe
wrote:
clip
It's a known issue that certain language constructs require
memory management. That's not a big deal, you can't use C++'s
On 1/4/15 8:17 PM, anonymous wrote:
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:
On 1/4/15 3:10 PM, Jonathan wrote:
Bullshit. dmd is easy to beat. also json parsing? library issue.
If there are library issues (like a slow json parser, or an unusable
one), these should
On Monday, 5 January 2015 at 01:30:08 UTC, Walter Bright wrote:
On 1/4/2015 5:07 PM, weaselcat wrote:
It doesn't time that part
You're right, I overlooked that.
You can also speed things up by noticing that the nodes[] and
visited[] arguments never change, so getLongestPath can be made
as
On Monday, 5 January 2015 at 01:56:20 UTC, Ary Borenszweig wrote:
On 1/4/15 9:27 PM, bearophile wrote:
Walter Bright:
Nim:
for neighbour in nodes[nodeId].neighbours:
D:
foreach(immutable route neighbour;
nodes[nodeID].neighbours){
Correctly written D:
foreach (neighbour;
On 1/4/15 8:17 PM, anonymous wrote:
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:
On 1/4/15 3:10 PM, Jonathan wrote:
Hey folks,
I've been recently checking out Nim/rod and feel like it takes a lot of
inspiration from D (I think the creator was in the D community too as
On 1/4/15 11:09 PM, weaselcat wrote:
On Monday, 5 January 2015 at 01:56:20 UTC, Ary Borenszweig wrote:
On 1/4/15 9:27 PM, bearophile wrote:
Walter Bright:
Nim:
for neighbour in nodes[nodeId].neighbours:
D:
foreach(immutable route neighbour; nodes[nodeID].neighbours){
Correctly
On Monday, 5 January 2015 at 03:01:11 UTC, Daniel Murphy wrote:
Brian Schott wrote in message
news:phwlklufefyocyuli...@forum.dlang.org...
Looks like it's time to spend some more time with perf:
http://i.imgur.com/k50dFbU.png
Nice!
I had to hack the ddmd code to get it compile (more 1337
Also, DMD didn't like the body of the halt() function.
On 1/4/15 6:04 PM, Ary Borenszweig wrote:
On 1/4/15 8:17 PM, anonymous wrote:
On Sunday, 4 January 2015 at 21:46:09 UTC, Ary Borenszweig wrote:
On 1/4/15 3:10 PM, Jonathan wrote:
Bullshit. dmd is easy to beat. also json parsing? library issue.
If there are library issues (like a slow json
On 1/4/15 5:07 PM, weaselcat wrote:
Why does reduce! take the seed as its first parameter btw? It sort of
messes up function chaining.
Mistake. -- Andrei
On Sunday, 4 January 2015 at 17:25:49 UTC, Martin Nowak wrote:
Exceptions on MC sounds like a bad idea,
That is a bias of old. It is entirely dependent on the
application. Many modern uses of microcontrollers are not hard
real-time, and while my work was primarily on ARM
Daniel Murphy wrote in message news:m8bdul$1dke$1...@digitalmars.com...
I've created a dub package for the D version of DMD's lexer, generated
automatically from the C++ source.
github: https://github.com/yebblies/ddmd
dub: http://code.dlang.org/packages/ddmd
I've pushed a new version
On 1/5/15 12:42 AM, Walter Bright wrote:
On 1/4/2015 6:11 PM, Ary Borenszweig wrote:
But the main D developers are using dmd, written in C++. I'm not sure
they have
written large D programs, as big as a compiler (but correct me if I'm
wrong).
Does Javascript count?
On Sunday, 4 January 2015 at 19:50:48 UTC, Johannes Pfau wrote:
One example of many: If you disable ModuleInfo we still happily
compile
module constructors, they'll never be called though. Sure you
can avoid
this if you know about it, but we can't promote D as a
reasonable
replacement for C
On Sun, Jan 04, 2015 at 07:25:28PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 1/4/15 5:07 PM, weaselcat wrote:
Why does reduce! take the seed as its first parameter btw? It sort of
messes up function chaining.
Mistake. -- Andrei
When are we going to fix this?
T
--
Nothing
Are they some extremely simple tutorials on bindings and
wrappers? Something with lots of code examples.
I don't think it's a subject that warrants a tutorial. There's
not that much to it. Consider:
// capi.h
void do_something( const char *str );
// capi.d -- this is a binding
Ary Borenszweig wrote in message news:m8d6g5$hna$1...@digitalmars.com...
Are there proofs of percentage of bugs caused by incorrectly mutating
variables that were supposed to be immutable? I don't remember having
such bug in my life.
Every C++ programmer has hit this bug at some point:
Laeeth Isharc wrote in message
news:vtgirvyjsalkzjvlz...@forum.dlang.org...
Thanks v much - this will be very helpful indeed.
Let me know if you have any questions about it.
On Monday, 5 January 2015 at 03:56:31 UTC, bearophile wrote:
Immutable variables make the code simpler to understand for
programmers and more handy for compilers. The less moving parts
your code has, the better it's for you.
More explanations on request.
Can the compiler automatically make
Vlad Levenfeld:
Can the compiler automatically make variables immutable if it
can prove that they are never changed in some code?
This is very different from what I am saying. The C compilers
don't go to add a const annotation to your source code (but
perhaps the Rust compiler warns about
On 12/31/2014 5:07 PM, H. S. Teoh via Digitalmars-d wrote:
I've yet to locate the cause of this problem, it's an unpleasant task trying
to wade through the layers of make macro hacks in posix.mak to figure
out what went wrong.)
I'm not sympathetic because everyone hated my straightforward (but
Vlad Levenfeld wrote in message
news:xrizfcicbvbkhtpvu...@forum.dlang.org...
Can the compiler automatically make variables immutable if it can prove
that they are never changed in some code?
It can apply the same optimizations, yes.
On 1/5/15 1:54 AM, bearophile wrote:
Vlad Levenfeld:
Can the compiler automatically make variables immutable if it can
prove that they are never changed in some code?
This is very different from what I am saying. The C compilers don't go
to add a const annotation to your source code (but
On Sun, Jan 04, 2015 at 08:56:28PM -0800, Walter Bright via Digitalmars-d wrote:
On 12/31/2014 5:07 PM, H. S. Teoh via Digitalmars-d wrote:
I've yet to locate the cause of this problem, it's an unpleasant task
trying to wade through the layers of make macro hacks in posix.mak to
figure out
bearophile wrote in message news:bwxlgpicmmnvphyiq...@forum.dlang.org...
D:
foreach(immutable route neighbour; nodes[nodeID].neighbours){
Correctly written D:
foreach (neighbour; nodes[nodeID].neighbours){
I don't agree, the good D way is:
foreach (immutable neighbour;
1 - 100 of 120 matches
Mail list logo
