On Mon, 27 Apr 2015 08:23:26 +, ponce wrote:
Bringing D in the workplace often bring incredible resistance and
arguments.
I've heard it all over the years:
- D is like C#, why use it?
- D can't be scripted (yes it can)
- D isn't fast enough
- D isn't much used and is 10 years old,
On Sunday, 26 April 2015 at 19:13:33 UTC, ponce wrote:
On Sunday, 26 April 2015 at 14:28:11 UTC, Baz wrote:
On Sunday, 26 April 2015 at 12:04:20 UTC, Laeeth Isharc wrote:
On Sunday, 26 April 2015 at 09:26:11 UTC, ponce wrote:
On Wednesday, 22 April 2015 at 19:51:23 UTC, ponce wrote:
I
On Monday, 27 April 2015 at 07:45:30 UTC, Laeeth Isharc wrote:
On Sunday, 26 April 2015 at 19:13:33 UTC, ponce wrote:
Lesson taken: should have put a less aggressive title.
Not necessarily. The people who complain loudly constitute a
tiny subset of those who are ultimately influenced. One
On Wednesday, 22 April 2015 at 19:51:23 UTC, ponce wrote:
I should put in in a d-idioms anyway.
http://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?
On Sunday, 26 April 2015 at 12:04:20 UTC, Laeeth Isharc wrote:
On Sunday, 26 April 2015 at 09:26:11 UTC, ponce wrote:
On Wednesday, 22 April 2015 at 19:51:23 UTC, ponce wrote:
I should put in in a d-idioms anyway.
http://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?
excellent.
On Sunday, 26 April 2015 at 09:26:11 UTC, ponce wrote:
On Wednesday, 22 April 2015 at 19:51:23 UTC, ponce wrote:
I should put in in a d-idioms anyway.
http://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?
excellent.
I linked it here: http://wiki.dlang.org/Coming_From
On Sunday, 26 April 2015 at 14:28:11 UTC, Baz wrote:
On Sunday, 26 April 2015 at 12:04:20 UTC, Laeeth Isharc wrote:
On Sunday, 26 April 2015 at 09:26:11 UTC, ponce wrote:
On Wednesday, 22 April 2015 at 19:51:23 UTC, ponce wrote:
I should put in in a d-idioms anyway.
On 4/24/2015 11:51 PM, Iain Buclaw via Digitalmars-d wrote:
I wonder just how large... IIRC I think the limit on ubyte arrays is 1M?
A large enough value can not just case stack overflow, but can cause the stack
pointer to be anywhere in the address space.
I don't know of a limit on ubyte
On 4/22/15 1:36 PM, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the initialisation has a significant performance impact?
The boring example
On Saturday, 25 April 2015 at 21:26:25 UTC, Andrei Alexandrescu
wrote:
On 4/22/15 1:36 PM, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the
On 4/25/15 3:23 PM, John Colvin wrote:
On Saturday, 25 April 2015 at 21:26:25 UTC, Andrei Alexandrescu wrote:
On 4/22/15 1:36 PM, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they
On 25 Apr 2015 01:25, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/24/2015 5:59 AM, John Colvin wrote:
one reason why it might be faster is that e.g. gcc can produce code like
this:
#includealloca.h
void bar(char* a);
void foo(unsigned int n)
{
char *a =
Walter Bright wrote in message news:mhc7am$942$1...@digitalmars.com...
Everyone hated it :-) but me.
And by that Walter means the interface was highly unsafe and he didn't want
to change it.
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than malloc/free.
That's not necessarily true. But in any case, go ahead and use it if you like.
Just prepare to benchmark and be disappointed :-)
On Friday, 24 April 2015 at 08:16:40 UTC, Walter Bright wrote:
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than malloc/free.
That's not necessarily true. But in any case, go ahead and use
it if you like. Just prepare to benchmark and be
On Friday, 24 April 2015 at 12:34:19 UTC, ponce wrote:
On Friday, 24 April 2015 at 08:16:40 UTC, Walter Bright wrote:
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than
malloc/free.
That's not necessarily true. But in any case, go ahead and use
it
On Friday, 24 April 2015 at 08:16:40 UTC, Walter Bright wrote:
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than malloc/free.
That's not necessarily true. But in any case, go ahead and use
it if you like. Just prepare to benchmark and be
On 4/24/2015 10:27 AM, deadalnix wrote:
On Friday, 24 April 2015 at 08:16:40 UTC, Walter Bright wrote:
On 4/24/2015 12:23 AM, John Colvin wrote:
Except of course that alloca is a lot cheaper than malloc/free.
That's not necessarily true. But in any case, go ahead and use it if you like.
Just
On 4/24/2015 5:59 AM, John Colvin wrote:
one reason why it might be faster is that e.g. gcc can produce code like this:
#includealloca.h
void bar(char* a);
void foo(unsigned int n)
{
char *a = (char*)alloca(n);
bar(a);
}
foo:
movl%edi, %eax
pushq%rbp
addq$46,
On Friday, 24 April 2015 at 01:54:11 UTC, Walter Bright wrote:
On 4/23/2015 3:11 PM, deadalnix wrote:
For arbitrary large, you can always do something like :
Item* itemPtr = (arbitrarylarge thresold)
? alloca(arbitrarylarge)
: GC.alloc(arbitrarylarge);
One extra check compared to a heap
On Wednesday, 22 April 2015 at 22:26:45 UTC, John Colvin wrote:
On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are
On 23 April 2015 at 16:28, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 22 April 2015 at 22:26:45 UTC, John Colvin wrote:
On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim Grøstad wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even
On Thursday, 23 April 2015 at 14:29:01 UTC, Ola Fosheim Grøstad
wrote:
Can you give a specific example where all 3 points are
satisfied?
Not sure why you would need it, plenty of cases where compilers
will fail. E.g. queues between threads (like real time threads)
where you allocate in one
On Thursday, 23 April 2015 at 14:50:26 UTC, John Colvin wrote:
There are cases where you might really need to grab an extra
1-5%, at which point you are hand optimising and = void is a
reasonable tool.
Well, it can be a lot more than 1-5% in special situations if you
hand over a small header
On Thursday, 23 April 2015 at 14:55:42 UTC, Iain Buclaw wrote:
There are two states each local variable can be assigned.
1. Used
2. Read
int a = 1; // a = Used
return a; // a = Read
printf(%d\n, a); // a = Read
int b = a; // b = Used, a = Read
int c = void; // c = Unused
If a variable is
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size stack-allocated associative
arrays. In D you can't even allocate safely a
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated
On Thursday, 23 April 2015 at 20:40:36 UTC, John Colvin wrote:
scopeBuffer), but in practice it's not a big win over just
stack allocating the maximum size all the time (again, like
scopeBuffer).
If you have a random distribution of sizes then allocating the
maximum will use twice as much
On Thursday, 23 April 2015 at 18:37:47 UTC, Walter Bright wrote:
On 4/23/2015 1:10 AM, bearophile wrote:
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size
stack-allocated
On Thursday, 23 April 2015 at 01:45:14 UTC, deadalnix wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
On Wednesday, 22 April 2015 at 20:29:49 UTC, Walter Bright wrote:
On 4/22/2015 12:51 PM, ponce wrote:
I didn't appreciate how important default initialization was before
having to
fix a non-deterministic, release-only, time-dependent bug in a video
encoder
some months ago. Just because of
Walter Bright:
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada (and probably Rust too),
??
In Ada standard library you have safe fixed-size stack-allocated
associative arrays. In D you can't even allocate safely a
dynamically-sized 1D array on the stack, and
On 4/23/2015 2:54 PM, weaselcat wrote:
Is there a reason scopebuffer isn't part of the documentation?
Everyone hated it :-) but me.
On 4/23/2015 3:11 PM, deadalnix wrote:
For arbitrary large, you can always do something like :
Item* itemPtr = (arbitrarylarge thresold)
? alloca(arbitrarylarge)
: GC.alloc(arbitrarylarge);
One extra check compared to a heap allocation is not going to make things
terrible, and it is
I'd missed this post on reddit:
http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpx41ix
On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
D is just another of those “Let's put everything on the
heap”-languages that do then of course need GC.
what's up with people constantly equating garbage collection to
being the same as java?
On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
I'd missed this post on reddit:
http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpx41ix
Thanks for the mention. I must have forgotten some. I should put
in in a d-idioms
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the initialisation has a significant performance
On Wednesday, 22 April 2015 at 20:29:49 UTC, Walter Bright wrote:
On 4/22/2015 12:51 PM, ponce wrote:
I didn't appreciate how important default initialization was
before having to
fix a non-deterministic, release-only, time-dependent bug in a
video encoder
some months ago. Just because of 2
On Wed, 22 Apr 2015 19:32:46 +, weaselcat wrote:
On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote:
D is just another of those âLet's put everything on the heapâ-languages
that do then of course need GC.
what's up with people constantly equating garbage collection to
On Wednesday, 22 April 2015 at 21:59:48 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and
weaselcat:
On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright
wrote:
D is just another of those “Let's put everything on the
heap”-languages that do then of course need GC.
what's up with people constantly equating garbage collection to
being the same as java?
In D you don't put
On Wednesday, 22 April 2015 at 20:36:12 UTC, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the initialisation has a significant performance
On 4/22/2015 1:36 PM, John Colvin wrote:
Is it even possible to contrive a case where
1) The default initialisation stores are technically dead and
2) Modern compilers can't tell they are dead and elide them and
3) Doing the initialisation has a significant performance impact?
And you can
On 4/22/2015 2:58 PM, bearophile wrote:
D is less stack-friendly than Ada
(and probably Rust too),
??
On 4/22/2015 12:51 PM, ponce wrote:
I didn't appreciate how important default initialization was before having to
fix a non-deterministic, release-only, time-dependent bug in a video encoder
some months ago. Just because of 2 uninitialized variables (C++ doesn't require
member initialization in
On Wednesday, 22 April 2015 at 22:41:33 UTC, Walter Bright wrote:
And you can still initialize with '= void'.
This was my tip of the week two TWID's ago!
http://arsdnet.net/this-week-in-d/apr-12.html
On 4/22/2015 3:52 PM, Adam D. Ruppe wrote:
On Wednesday, 22 April 2015 at 22:41:33 UTC, Walter Bright wrote:
And you can still initialize with '= void'.
This was my tip of the week two TWID's ago!
http://arsdnet.net/this-week-in-d/apr-12.html
Yup!
49 matches
Mail list logo
