Re: D Logic bug
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.viva64.com/en/b/0583/#ID0E1CAC
Re: Deep nesting vs early returns
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 someone can point me to it?). He nicely described how all that nesting builds up a huge context you need to keep in your brain while trying to reason about the function.
Re: John Regehr on "Use of Assertions"
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 that. You can't just blindly turn it into assume since that may actually impede optimizations: https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
Re: fix C ABI
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 BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445. With the addition of your $500 that would make the bounty $945, which isn't bad. Must be pretty hard to fix though if yebblies couldn't do it.
Re: Messing with betterC and string type.
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
Re: John Regehr on "Use of Assertions"
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 sounds like the right thing. Exactly. You may still catch assert(!fclose(f)) but not other non-obvious functions. Nice trick to find them in C: https://stackoverflow.com/questions/10593492/catching-assert-with-side-effects/35294344#35294344
Re: John Regehr on "Use of Assertions"
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 bugs in C.
Re: D is dead
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 always point to the latest revision. Not sure if it's an official WG21 service though. Anyway, very interesting paper and approach. I'm eager to see how this will work out.
Re: D is dead
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 exception handling" is a bad joke. (Even Chandler Carruth stated that the LLVM basically gives up trying to optimize in the presence of exception handlers.) Herb Sutter has a recent paper out proposing an alternative, completely different, error handling scheme for C++ because of this issue. Are you referring to http://wg21.link/P0709 ?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
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 libraries in order to only mark what should be visible outside the current compilation unit as 'export'. Shouldn't it be sufficient to put an export: at the top of each module to roll back to the old behavior and do the real fix later? Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3! So why not add such an opt-in flag to all compilers, deprecate the old behavior and do the switch at some point.
Re: core.attribute - Remove friction for compiler attributes
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.attribute,
either aliasing or replacing the vendor specific symbols. They
don't need to be functional immediately. There are two things
that I see need to be discussed.
I couldn't agree more.
It's awkward having to write such boilerplate code just to get
something as common as @inline to compile across compilers.
Another example:
https://github.com/JinShil/stm32f42_discovery_demo/blob/d61819015/source/runtime/object.d#L16
And for embedded applications @used, @section(".xy") and @weak
would also be useful.
C++ static exceptions proposal
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.
Re: Shout out to D at cppcon, when talkign about ranges.
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 problems that iterators do. Many algorithms return positions. These all suffer the same problem as find. One algorithm implementation isn’t sufficient; you need bunches of differently-named algorithms that differ only in the subrange they return. As for the political argument: I want ranges in the standard. There is just no way the C++ standardization committee would ever consider a range-only interface.
Re: Shout out to D at cppcon, when talkign about ranges.
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 still trying to grasp all the implications. Ranges are hard. Another one is "odd number of iterators algorithms" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Re: OPTLINK Error 45 Too Much DEBUG Data for Old CodeView format
Just save yourself lots of headaches and abandon the optlink/omf crap with -m64 resp. -m32mscoff.
Re: dmd test coverage
Plenty of not covered lines are actually assert(0)'s.
Re: Microsoft now giving away VS 2013
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 corporate VS users get stuck on legacy versions of VS for a very long time. We still use VS2010 at work for instance, with no plan to upgrade. It would be a shame to lose legacy VS support, but I think the focus should certainly emphasise these future releases. It's perfectly possible to install newer versions side-by-side and even combine the new IDE with the old crap compiler for transitioning, which I've done since the very first CTP. Starting with 2013 the express editions are also fully usable and only lack plugin support. The rest is just excuses.
Re: `alias newSymbol = existingSymbol` or `alias existingSymbol newSymbol`
Let the bikeshedding begin. They treat the style guide like the holy bible.
Re: Linux 64bit Calling Convention
https://github.com/D-Programming-Language/dmd/pull/4092
Re: Arduino and D
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
Re: LDC 0.15.0 alpha1 released! Please help test!
Does this msvc based build output gdb-compatible debugging symbols? No DWARFs in there.
Re: Linux 64bit Calling Convention
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:
a: 1
b: 2
a: 2
b: 1
Unless I'm mistaken, DMD does not respect the C calling
convention on Linux/AMD64.
True.
For extern(D) dmd passes parameters in reverse order on Win64 and
Linux64!
What the heck?
Re: Linux 64bit Calling Convention
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).
Re: Linux 64bit Calling Convention
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 matches the initial custom Win32 D ABI.
Re: Linux 64bit Calling Convention
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.
Re: Consistent bugs with dmd -O -inline in a large project
LDC is 2.065 Already 2.066 in the repo.
Re: template constraint diagnostics
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 interpreter and uses the resulting bool.
Re: Consistent bugs with dmd -O -inline in a large project
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.
template constraint diagnostics
http://youtu.be/qwXq5MqY2ZA?t=33m57s I wish we had diagnostics like that in D.
Re: dsource and WinAPI
the long-term solution is to include the [win32] headers in druntime ™
Re: How do I write __simd(void16*, void16) ?
On Wednesday, 8 October 2014 at 18:56:31 UTC, Etienne wrote: I can't seem to find this function anywhere: __simd(void16*, void16) MOVDQU = void _mm_storeu_si128 ( __m128i *p, __m128i a) MOVDQU = __m128i _mm_loadu_si128 ( __m128i *p) Is there a module by now that allows to directly write Intel intrinsics?
Re: Local functions infer attributes?
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 something as e.g. nogc in the first version and later on add code with allocations.
Re: What's blocking DDMD?
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 magicport\namer.d Error: 'ofmagicport\magicport2.exe' not found
Re: Once in a while, you got to stop complaining and say thank you.
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.
Re: 438-byte Hello, world Win32 EXE in D
And how do ldc and gdc do? =)
Re: Lieutenant needed: build and release process
Since Git 1.8.2 you can bound a submodule to a branch. Ah cool didn't know that.
Re: Lieutenant needed: build and release process
You could also use submodules (or subtrees, haven't tried them yet).
Re: Lieutenant needed: build and release process
with 3 pull request queues Good argument for the separation :)
Re: Installing LDC on Windows
SEH was patented, so llvm doesn't support it. That has changed.
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 21:54:00 UTC, David Nadlinger wrote: On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote: SEH was patented, so llvm doesn't support it. That has changed. Has it? SEH on Win64 is something entirely different from the original (x86) SEH design, and not covered by said patent. Ok 2in1. 1) As far as I know the x86 SEH patent expired in June. 2) For x64 the implementation is very close now: https://github.com/ldc-developers/ldc/issues/166#issuecomment-54522891
Re: LDC 0.14.0 alpha1 released! Please help test!
Thanks for the help with the Win64 version and for providing the binary! :) fwiw A bunch of tests still crash.
Re: LDC 0.14.0 alpha1 released! Please help test!
I also have an experimental Win64 MSVC version. https://github.com/Trass3r/ldc/releases
Re: Optlink Contribution
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 support. Anybody seriously programming on Windows uses VS anyway. But at least for 32 bit http://lld.llvm.org/windows_support.html could be packaged.
Re: 64-bit DMD for windows?
Is there a PR now?
Re: Optlink Contribution
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.
Re: What is the status of DLL programming in D 2.065?
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 should we be using core.runtime.Runtime.loadLibrary()? I think so, though the page is still 32-bit/Optlink centric. http://wiki.dlang.org/Win32_DLLs_in_D Just created a Win64 dll the other day: https://github.com/Trass3r/hooksample But haven't investigated GC/runtime sharing.
Re: Showing a user specified error message when no overloads match
Yeah that's the price we pay for the simplicity. Also most constraints directly or indirectly consist of a complex boolean expressions and you don't get any hint which part failed and why.
Re: Stack trace linux/windows why the difference
On linux more work should be done to get line infos, I'm investigating how to get then. Cheers ! That's the spirit!
function default arguments depending on other arguments
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?
core.stdc.fenv on Win64
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-org-wsl/ci/master/tree/include/fenv.h#l87
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
druntime: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ target phobos: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib That works? So it probably doesn't need the includes set in the makefile.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Nope doesn't. Setting VCDIR and SDKDIR via the make command works.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Setting VCDIR and SDKDIR via the make command works. Works for me. Maybe you need a newer version of make (there was a silent update in 2012, my version is 5.06). Well if you don't set VCDIR you won't get proper include paths. So no clue why it works for you.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? As long as they rely on the MS linker they only need to emit proper debug info into the object files. But that's still TODO: http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
Any other good blog posts / social media comments / pointers I can digest and use? http://planet.dsource.org
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Digger is awesome. Have never heard of it before this talk. Unfortunately it's a huge PITA to get a Win64 build with it cause of those stupid hardcoded \Program Files (x86)\Microsoft Visual Studio 10.0\VC paths. The modified makefiles etc are always reverted by Digger before building.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
You can add the compiler to the make command line with some magic quoting. My build script calls druntime: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ target phobos: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib Isn't the make call hardcoded in Digger?
Re: array initializers
Can you reproduce this?
Re: TypeInfo in the library
Any news on this?
Re: Rosettacode example collection
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.
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
http://youtu.be/Es8st0E5428 Thx alot! Enables me to watch it easily on my tv :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
http://youtu.be/n9RNxUQ0Cyk
array initializers
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 literal type. But not sure what this is supposed to do.
Re: array initializers
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.
Re: array initializers
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. But
bool blub()
{
immutable int[] arr = [0,0,0,0,0,0,0,0];
return arr == [1,1,1,1,1,1,1,1];
}
yields
@.immutablearray = internal constant [8 x i32] zeroinitializer
@.arrayliteral = internal unnamed_addr constant [8 x i32] [i32 1,
i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1]
define i1 @_D13arrayliterals4blubFZb() #0 {
%.gc_mem = tail call { i64, i8* }
@_d_newarrayvT(%object.TypeInfo* @_D11TypeInfo_Ai6__initZ, i64 8)
%.ptr = extractvalue { i64, i8* } %.gc_mem, 1
tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %.ptr, i8*
bitcast ([8 x i32]* @.arrayliteral to i8*), i64 32, i32 1, i1
false)
%tmp27 = tail call i32 @_adEq2({ i64, i8* } { i64 8, i8*
bitcast ([8 x i32]* @.immutablearray to i8*) }, { i64, i8* }
%.gc_mem, %object.TypeInfo* bitcast (%typeid(immutable(int)[])*
@_D12TypeInfo_Ayi6__initZ to %object.TypeInfo*)) #2
%tmp28 = icmp ne i32 %tmp27, 0
ret i1 %tmp28
}
Re: array initializers
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) }
@.constarray = internal global [8 x i32] [i32 0, i32 1, i32 2,
i32 3, i32 4, i32 5, i32 6, i32 7]
define i32 @_D5immut3fooFNaNbZi() #0 {
forbody:
%tmp15 = load i32* getelementptr inbounds ([8 x i32]*
@.constarray, i64 0, i64 0), align 16
%tmp15.1 = load i32* getelementptr inbounds ([8 x i32]*
@.constarray, i64 0, i64 1), align 4
%tmp19.1 = add i32 %tmp15.1, %tmp15
%tmp15.2 = load i32* getelementptr inbounds ([8 x i32]*
@.constarray, i64 0, i64 2), align 8
%tmp19.2 = add i32 %tmp15.2, %tmp19.1
...
while with cast(immutable)[0,1,... :
@_D5immut3aaayAi = constant { i64, i32* } { i64 8, i32*
getelementptr inbounds ([8 x i32]* @.dynarrayStorage, i32 0, i32
0) }
@.dynarrayStorage = internal unnamed_addr constant [8 x i32] [i32
0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7]
define i32 @_D5immut3fooFNaNbZi() #0 {
endfor:
ret i32 28
}
Re: Question about @nogc in D 2.066
http://forum.dlang.org/thread/pxotrowaqcenrpnnw...@forum.dlang.org
Re: Run Microsoft Analyzer over dmd source code
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.
Re: Why is the Win32 boilerplate the way it is?
The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? WinXP is dead :)
Re: Why are breakpoints caught by the runtime?
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 is horrible but what I usually do.
Unfortunately it is read before Dmain and the module
constructors are run so it's tricky to clear on startup.
So you can't even do something like
extern extern (C) __gshared bool rt_trapExceptions;
void main()
{
rt_trapExceptions = false;
asm { int 3; }
}
Strangely enough now my original example triggers the debugger.
Not a clue what changed.
Re: what is going on with cgcs.c:351?
I think it should be possible to run DustMite on some big project like phobos to actually search for such internal errors.
Why are breakpoints caught by the runtime?
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)
int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
Re: Why are breakpoints caught by the runtime?
Win7 x64
Re: Why are breakpoints caught by the runtime?
It is default windows runtime behavior Yeah but couldn't/shouldn't it let breakpoints through?
Re: enum scope
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 anyone know how you would implement this in the compiler?
