Timo Gransch wrote:

> I compile a programm using
> 
> ldmd -g -debug test.d
> 
> Then I try to debug using gdb with the D patches:
> 
> (gdb) list
> 1	../sysdeps/x86_64/elf/start.S: No such file or directory.
> in ../sysdeps/x86_64/elf/start.S

On x86-32 that gives me a listing of the main function defined in the D runtime - but I am using a debug runtime. Does inserting a breakpoint in your code and running to that work?

Kagamin wrote:
> I found recently that properly designed C++ code can live happily
> without all that esoteric macro/template crap and can be pretty
> readable and understandable even using nasty antipatterns. This being
> achieved simply by using C++ subset that is supported on various
> platforms. Code that does the job instead of casting black magic.

The D compiler source doesn't use any templates, rtti, or clever macro hacks. Whether it's well designed or not, I'll let others decide. It is written in a "D-ish" style.

Walter Bright wrote:
> The D compiler source doesn't use any templates, rtti, or clever macro hacks. Whether it's well designed or not, I'll let others decide. It is written in a "D-ish" style.

I ported part of the DMDFE to Java, and found it quite well-designed (with the exception of the frequent use of globals). The gotos make it more readable IMO (compare the original to the Java version where gotos are replaced with exceptions, replaced with duplicated code, emulated with a bunch of booleans, or refactored into separate functions taking 7+ arguments).

However, the DMDFE's organization relies on being able to declare class member functions separately from where they're defined, which is impossible in D (hint, hint, nudge, nudge).

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:gvml4m$2lg0$2@digitalmars.com...
> Kagamin wrote:
>> I found recently that properly designed C++ code can live happily without all that esoteric macro/template crap and can be pretty readable and understandable even using nasty antipatterns. This being achieved simply by using C++ subset that is supported on various platforms. Code that does the job instead of casting black magic.
>
> The D compiler source doesn't use any templates, rtti, or clever macro hacks. Whether it's well designed or not, I'll let others decide. It is written in a "D-ish" style.

As someone who's (deliberately) barely touched C++ in about ten years, I found it surprisingly easy to find my way around. Although I did find it strange that there seemed to be a fair amount of duplicated code (at least WRT to error/warning reporting anyway).

Robert Fraser:
> However, the DMDFE's organization relies on being able to declare class member functions separately from where they're defined, which is impossible in D (hint, hint, nudge, nudge).

This current characteristics of D classes makes them a bit simpler to read/understand/use.
Can you tell me (and/or show a small example) where you think such separation may improve some D code?

Bye,
bearophile

Christian Kamm schrieb:

> On x86-32 that gives me a listing of the main function defined in the D runtime -

On Arch Linux/32 (using the official ldc binary), list prints the source code of the compiled file, just the way it's supposed to.

(gdb) list
1	import tango.io.Console;
2
3	int main(char[][] args)
4	{
5	    for (int i = 0; i < args.length; i++)
6	    {
7	        Cout(args[i] ~ "\n");
8	    }
9
10	    return 0;

> but I am using a debug runtime. Does inserting a breakpoint in your code and running to that work?

Back on x86-64 again:

(gdb) break main
Breakpoint 1 at 0x409150
(gdb) run
Starting program: /home/timo/tmp/testd/test
[Thread debugging using libthread_db enabled]
[New Thread 0x7fb54f2456f0 (LWP 7001)]
[Switching to Thread 0x7fb54f2456f0 (LWP 7001)]

Breakpoint 1, 0x0000000000409150 in main ()
Current language:  auto; currently asm
(gdb) step
Single stepping until exit from function main,
which has no line number information.
0x000000000040a830 in _STI_monitor_staticctor ()
(gdb) step
Single stepping until exit from function _STI_monitor_staticctor,
which has no line number information.
0x0000000000409183 in main ()


If I try to run list after that, the error message is different:

(gdb) list
1	/build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S: No such file
or directory.
	in /build/buildd/glibc-2.9/build-tree/amd64-libc/csu/crtn.S

Thanks and best regards,
Timo

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gvmtt5$5os$1@digitalmars.com...
> Robert Fraser:
>> However, the DMDFE's organization relies on being able to declare class member functions separately from where they're defined, which is impossible in D (hint, hint, nudge, nudge).
>
> This current characteristics of D classes makes them a bit simpler to
> read/understand/use.
> Can you tell me (and/or show a small example) where you think such
> separation may improve some D code?
>

Yea, I haven't seen anything yet about lifting the one-to-one module-to-file mapping that would make breaking bud/rebuild-like tools worthwhile. But I'd be interested in hearing any arguments in favor of doing so.

Op Thu, 28 May 2009 03:08:45 +0200 schreef Tomas Lindquist Olsen <tomas.l.olsen@gmail.com>:

> * put the code under version control, that could simplify pulling
> fixes into our tree.

You could setup a seperate branch with the DMD source, extract source tarball, commit.
Then merge the DMDFE branch into the LDC branches.

I dont know how to do this in hg, but i guess its very similar to git.

Or is it already done this way?

Kagamin wrote:
> 
> I found recently that properly designed C++ code can live happily without all that esoteric macro/template crap and can be pretty readable and understandable even using nasty antipatterns. This being achieved simply by using C++ subset that is supported on various platforms. Code that does the job instead of casting black magic.

The problem is trying to get an entire team to code that way.

Timo Gransch wrote:
> Christian Kamm schrieb:
>> but I am using a debug runtime. Does inserting a breakpoint in your code and running to that work?
> 
> Back on x86-64 again:
> 
> (gdb) break main
> Breakpoint 1 at 0x409150

Since there's main and _Dmain and I don't know how the GDB patches interact with breakpoint setting, can you try to make a breakpoint on the first line of your D main function (i.e. b myfile.d:15) and run to that?

I'm now also subscribed to D.debugger and saw your post there. Let's move the discussion.