On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
That's why shouldn't compose it like that.
It's been a constant source of bugs in C/C++ code:
https://www.viv
On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu
wrote:
Kate Gregory makes a good argument on something I've often
commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682
Sean Parent covered early exits years ago in an excellent talk I
just can't find anymore (maybe someo
On Wednesday, 5 September 2018 at 19:35:46 UTC, Meta wrote:
I think the only sane way to use asserts as an optimization
guide is when the program will abort if the condition does not
hold.
Which is the usual behavior of assert.
I'm all for using them to optimize but it's not clear how to do
t
On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote:
On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc
wrote:
https://issues.dlang.org/show_bug.cgi?id=19179
https://issues.dlang.org/show_bug.cgi?id=5570
https://issues.dlang.org/show_bug.cgi?id=13957
According to BountyS
On Friday, 7 September 2018 at 08:26:11 UTC, Kagamin wrote:
You can sort of have custom literals like in C++
String s(object.string t){ return String(t); }
foo("this".s);
Awesome :D
On Sunday, 2 September 2018 at 21:12:39 UTC, Nick Sabalausky
(Abscissa) wrote:
This does make me think of one thing: Shouldn't assert
expressions be required to be pure? (even if only weakly pure)
Not sure how much practical problems that would create, but at
least in theory it certainly sound
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright
wrote:
Note the "may or may not be evaluated." We've debated this here
before. I'm rather pleased that John agrees with me on this.
It shouldn't allow side-effects then though.
https://run.dlang.io/is/P6VnYd
Also a common source of b
On Friday, 24 August 2018 at 09:52:20 UTC, Walter Bright wrote:
On 8/24/2018 1:45 AM, Trass3r wrote:
Are you referring to http://wg21.link/P0709 ?
Yes. (please don't use link shorteners, they tend to go poof)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf
I expect it to
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
Back to throwing constructors.
1) They are expensive, adding considerable hidden bloat in the
form of finally blocks, one for each constructing field. These
unwinding frames defeat optimization. The concept of "zero-cost
except
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote:
Possible Solution: Make all globals hidden by default unless
'export'.
Same mess as in C++. But there you have -fvisibility=hidden at
least to fix it.
Side effects: Everyone will be spending weeks to months fixing
their librari
On Tuesday, 20 October 2015 at 07:57:29 UTC, Marco Leise wrote:
For a while now GDC and LDC have supported a variety of their
backend's attributes, like inlining or compiling a specific
function with SSE4 in an otherwise generic x64 build.
I think we should unify those into a common core.attri
http://wg21.link/P0709
Interesting read. Looks like they want to bake something like
llvm::Expected into the language. I wonder if D shares all
these dynamic exceptions issues.
In any case it should become relevant if they really change the C
ABI as well.
Here's the original discussion with Eric's elaborate answer:
http://ericniebler.com/2014/02/21/introducing-iterables/#comment-403
Because I want to leverage the vast amount of iterator-based
code already written, and because in my experience, I don’t
find that ranges as primitives solve all the
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:
Yes, this is an explanation. Thanks. So the argument being C++
customs. Now that you mention it, this seems to be the argument
in Eric's D4128 paper, too.
I was hoping for a somewhat deeper reasoning. Out of curiously,
I am sti
Plenty of "not covered" lines are actually assert(0)'s.
On Thursday, 13 November 2014 at 09:36:26 UTC, Manu via
Digitalmars-d wrote:
On 13 November 2014 10:57, Walter Bright wrote:
This is good news for D! It lowers the bar for writing 64 bit
D code on
Windows, and it also enables us to abandon support for
versions of VS prior
to 2013.
Many, many
Let the bikeshedding begin.
They treat the style guide like the holy bible.
https://github.com/D-Programming-Language/dmd/pull/4092
my work has stalled as I try to find a way to make the
experience more polished, and less like patchwork.
It's a shame this went nowhere:
https://issues.dlang.org/show_bug.cgi?id=12270
Yes it's clearly stated on the ABI page (and sane).
Nobody ever noticed cause it's hard to spot this in assembly.
But it was very salient and disturbing in llvm IR.
Looking at the code extern(D) is in the _revfunc list in optabgen.
Which seems to cause params to be reversed independent of the
architecture in FuncDeclaration::toObjFile // Reverse params[]
entries.
Meaning Linux x32 would also be affected.
This totally smells like a remnant as the code matc
On Thursday, 28 February 2013 at 02:02:09 UTC, Walter Bright
wrote:
On 2/27/2013 5:03 PM, Maxime Chevalier wrote:
Unless I'm mistaken, DMD does not respect the C calling
convention on Linux/AMD64.
To use the C calling convention, specify "extern (C)" for the
function.
This is about extern(D
On Thursday, 28 February 2013 at 01:03:08 UTC, Maxime Chevalier
wrote:
I did some further testing:
void foo(int a, int b)
{
writefln("a: %s", a);
writefln("b: %s", b);
}
unittest
{
foo(1, 2);
asm
{
mov RDI, 1;
mov RSI, 2;
call foo;
}
}
Produces:
LDC is 2.065
Already 2.066 in the repo.
What should I do? Am I stuck with not using -O and -inline for
now, hoping that things will improve in the future?
Step 1) DustMite the heck out of it and create a bug report.
Step 2) Start using ldc/gdc for release builds if possible.
I don't think it would be too difficult. You are analyzing an
expression that evaluates to false, and it wouldn't take much
to dig down to find out which subexpressions cause the false to
occur.
I think it's not that straightforward in dmd as it simply
delegates the constraint to the interpre
http://youtu.be/qwXq5MqY2ZA?t=33m57s
I wish we had diagnostics like that in D.
On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote:
Also, inferring everything is quite
expensive and we want D to compile fast.
Doesn't the compiler have to do that anyway?
I'd expect a proper compiler to check if my code is actually what
I claim it is. It's quite easy to mark somet
https://auto-tester.puremagic.com/?projectid=10
Just windows left now.
Looks like a dash is missing?
ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d
magicport\scanner.d magicport\tokens.d magicport\parser.d
magicport\dprinter.d magicport\typenames.d magicport\visitor.d
Btw was there any specific commit / release that reduced
memory concumption or it was a gradual improvement?
No idea.
One could use Digger to generate a graph of SDC build times over
time like in the DConf talk.
Since Git 1.8.2 you can bound a submodule to a branch.
Ah cool didn't know that.
with 3 pull request queues
Good argument for the separation :)
You could also use submodules (or subtrees, haven't tried them
yet).
What makes it craziest is that there's a COFF32 branch lying
around that nobody merges:
http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
Same procedure as every year.
Is there a PR now?
I don't think dmd comes with a COFF64 linker now, users are
just told to install Visual Studio or the Windows SDK for a
linker. No reason you can't do the same with COFF32. Optlink
can stick around with OMF for a couple releases. I suspect
nobody would use it when given the choice of COFF32
On Saturday, 26 July 2014 at 07:53:54 UTC, Matt wrote:
Are we able to create DLLs easily enough in D now? Do we still
need to tell our D DLLs to share their GCs with the calling
EXE? And is the wiki page fully up to date on the matter? If
not where can we find the up to date information? Or sho
On linux more work should be done to get line infos, I'm
investigating how to get then.
Cheers !
That's the spirit!
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it
also allow this?
The implementation doesn't seem to be correct.
Could anybody versed in this look into it?
version(Windows)
{
private extern __gshared fenv_t _FE_DFL_ENV;
fenv_t* FE_DFL_ENV = &_FE_DFL_ENV;
}
There's no such symbol in the libcmt and it fails to link.
http://sourceforge.net/p/mingw/mingw
Any other good blog posts / social media comments / pointers I
can digest and use?
http://planet.dsource.org
Any news on this?
Can you reproduce this?
Somebody (I think bearophile) mentioned a while back that they
had a folder with all the D solutions from Rosettacode.
Yeah that would indeed be nice to have.
And
private immutable int[] aaa = [0,1,2,3,4,5,6,7];
int foo() pure nothrow
{
int sum;
foreach (int i; aaa)
sum += i;
return sum;
}
@_D5immut3aaayAi = constant { i64, i32* } { i64 8, i32*
getelementptr inbounds ([8 x i32]* @.constarray, i32 0, i32 0) }
@.
auto foo() {
immutable int[] arr = [0, 1, 0, 3];
return arr;
}
---
produces (with optimizations on, but just for brevity)
---
define { i64, i32* } @_D4test3fooFZyAi() #0 {
ret { i64, i32* } { i64 4, i32* getelementptr inbounds ([4 x
i32]* @.immutablearray, i32 0, i32 0) }
}
---
Indeed.
By the way, LDC already does this today (even without
optimizations turned on).
My ldc doesn't.
I had to cast(immutable) to actually get it to put the data as a
constant.
And even then it's still copied to the GC heap.
If you have
immutable int[] arr = [0,1,0,3];
Couldn't the type of the literal be inferred as immutable?
Then you could put the data into read-only memory, and maybe even
elide the copy to the heap?
The immutable arr type is even passed to
ArrayLiteralExp::inferType but doesn't influence the lit
Is there a way to disable exceptions with MSVC like
-fno-exceptions for GCC to help get rid of the associated false
positives?
Sure, no /EHsc and /D_HAS_EXCEPTIONS=0 for its STL.
On Monday, 16 June 2014 at 01:23:28 UTC, Daniel Murphy wrote:
"Trass3r" wrote
Is there any good reason to catch that?
I really want the debugger to fire up.
I know, I hate this. You can disable it by changing
rt_trapExceptions in dmain2.d in druntime to false and
rebuilding druntime, which
It is default windows runtime behavior
Yeah but couldn't/shouldn't it let breakpoints through?
Win7 x64
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C)
int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern (C
On Thursday, 26 January 2012 at 01:06:46 UTC, Trass3r wrote:
When writing C bindings I usually create lots of aliases via a
string mixin to pull enum members into the enclosing scope so
it's compatible to C.
Would it be wise to let the compiler do this automatically for
extern(C) enums?
Does
54 matches
Mail list logo
