Re: More on multiple return values [was: Re: Multiple return values]

+1 no comments :-) On Thu, Jan 5, 2012 at 4:32 AM, bearophile wrote: > I don't like 'out' function arguments, from a logic point of view they feel > unnatural and backwards (while 'ref' arguments are meaningful from a computer > science point of view). I'd even like to see 'out' arguments depr

Re: System programming in D (Was: The God Language)

> > Here's one I'm working on right now (C++). >> Base class for a UI system, surely one of the most heavily polymorphic >> types of code one can imagine. >> > > Apparently that is not true. > > > >> Count the virtuals... http://pastebin.com/dLUVvFsL >> > > 9/~65 approx 1:6. > So why give preceden

Re: Multiple return values

Jacob Carlborg wrote: C#, Java and similar language doesn't support free functions like D does. Then they have to resort to "hacks" like static methods, i.e. Console.WriteLine. D's free functions and simple module design are definitely points in it's favor. However that wasn't really my point

Re: System programming in D (Was: The God Language)

On Wed, Jan 4, 2012 at 12:53 PM, Manu wrote: > Oh, and virtual-by-default... completely unacceptable for a systems > language. most functions are NOT virtual, and finding the false-virtuals > while optimising will be extremely tedious and time consuming. Worse, if > libraries contain false virtual

Re: System programming in D (Was: The God Language)

On 5 January 2012 02:42, bearophile wrote: > Manu: > > > I'm not referring to vector OPERATIONS. I only refer to the creation of a > > type to identify these registers... > > Please, try to step back a bit and look at this problem from a bit more > distance. D has vector operations, and so far th

Re: Multiple return values

On Thu, Jan 5, 2012 at 2:47 AM, F i L wrote: > Jacob Carlborg wrote: >> >> C#, Java and similar language doesn't support free functions like D does. >> Then they have to resort to "hacks" like static methods, i.e. >> Console.WriteLine. > > > D's free functions and simple module design are definite

Re: Specialization - Major hole in the spec?

On 5/01/12 1:53 AM, Timon Gehr wrote: On 01/05/2012 03:01 AM, Peter Alexander wrote: On 5/01/12 1:19 AM, Timon Gehr wrote: foo!int(0); // 1 Matches both 1 and 2. 2 is strictly more specialized, therefore 2 is chosen. Mistake on your side. It chooses 1 because I have specified T to be int so

Re: System programming in D (Was: The God Language)

> > The thing I'm most worried about is people forgetting to declare 'final:' >> on a >> class, or junior programmers who DON'T declare final, perhaps because >> they don't >> understand it, or perhaps because they have 1-2 true-virtuals, and the >> rest are >> just defined in the same place... Thi

Re: System programming in D (Was: The God Language)

On 5 January 2012 03:06, Walter Bright wrote: > On 1/4/2012 4:30 PM, Sean Kelly wrote: > >> If a library is written without consideration to what is virtual and what >> is >> not, its performance will be the least of your problems. >> > > I agree. Such is a massive failure in designing a polymorp

Re: simple OpenGL app

Guess you just tried 'dmd test.d'? You need to pass all source files.. or use a tool like rdmd (included with dmd). Also that package is from 2010. I think your best bet is Derelict2: http://www.dsource.org/projects/derelict

Re: System programming in D (Was: The God Language)

On 01/05/12 08:19, Jacob Carlborg wrote: > On 2012-01-04 16:31, Artur Skawina wrote: >> On 01/04/12 10:39, Manu wrote: >>> Walter made an argument "The same goes for all those language extensions >>> you mentioned. Those are not part of Standard C. They are vendor >>> extensions. Does that mean t

Re: CURL question on ubuntuforums.org

"Joshua Reusch" wrote in message news:je26q8$19oo$1...@digitalmars.com... > > OT: Why does dmd ignore the pragma(lib, ...) in the etc.c.curl module > while rdmd seems to recognize it? What I think is happening: The pragma(lib, ...) causes DMD's -deps=filename option to include the library fil

Re: Multiple return values

Andrew Wiley wrote: You're pointing out two completely different things here. C# PascalCases methods and D camelCases them. That's a completely seperate issue from the actual names. I think you're reading too much into what I wrote, I wasn't talking about the case or modules vs static methods.

Re: Double Checked Locking

Andrei Alexandrescu wrote: > specification can be refined 1) I do not see such refinements for D. 2) If there is _no_ requirement for such refinements to be used "manually": which theory enables the compiler to detect the prerequisites for the refinements automatically? 3) If there _is_ a requi

Re: System programming in D (Was: The God Language)

On 01/05/12 02:34, Iain Buclaw wrote: > Code that gdc emits is incompatible with the standard D compiler, if > that's what you want to call it, and any vendor extensions won't > contribute to that being more of the case. > > Regardless, there is little reason to want to use a forced inline with >

Re: simple OpenGL app

On 01/05/2012 12:00 AM, Raivo F. wrote: Hi! I'm new to D programming language, altough have solid background in other languages. Currently I struggle with setting up simple OpenGL application. I found D/OpenGL package called GLAD: http://code.google.com/p/glapid/ First, it didn't include nec

Re: System programming in D (Was: The God Language)

On 5 January 2012 03:34, Iain Buclaw wrote: > Regardless, there is little reason to want to use a forced inline with > gdc. Just like in c++ when you define all methods in the class > definition, gdc considers all methods as candidates for inlining. > Similarly, when -inline is passed, the same

Re: System programming in D (Was: The God Language)

About your junior comment, are virtuals really the biggest thing you should worry about? There are infinitely many things a newbie programmer will screw up (think linear algorithms, excessive memory allocation, hardcoded, non-modular and thread-unsafe code, etc). I think virtual calls are likely to

Re: System programming in D (Was: The God Language)

On 2012-01-05 10:54, Artur Skawina wrote: On 01/05/12 08:19, Jacob Carlborg wrote: On 2012-01-04 16:31, Artur Skawina wrote: On 01/04/12 10:39, Manu wrote: Walter made an argument "The same goes for all those language extensions you mentioned. Those are not part of Standard C. They are vendor

Re: CURL question on ubuntuforums.org

On 2012-01-05 11:00, Nick Sabalausky wrote: "Joshua Reusch" wrote in message news:je26q8$19oo$1...@digitalmars.com... OT: Why does dmd ignore the pragma(lib, ...) in the etc.c.curl module while rdmd seems to recognize it? What I think is happening: The pragma(lib, ...) causes DMD's -deps=fi

Re: System programming in D (Was: The God Language)

Btw, I think people are having a misconception on what it means that D is a systems-programming language. It doesn't mean that D by default generates the fastest code and trades safety for performance, it means it *allows* you to write such code. But you need to be aware of what you're coding.

Re: System programming in D (Was: The God Language)

On Thursday, 5 January 2012 at 13:40:20 UTC, Jacob Carlborg wrote: The pragma is a standard way to expose non-standard features. You just need to wrap it in version statements because the compiler will otherwise complain about unrecognized pragmas. If that's a good thing or not, I don't know.

Re: CURL question on ubuntuforums.org

On 05/01/2012 13:41, Jacob Carlborg wrote: On 2012-01-05 11:00, Nick Sabalausky wrote: "Joshua Reusch" wrote in message news:je26q8$19oo$1...@digitalmars.com... OT: Why does dmd ignore the pragma(lib, ...) in the etc.c.curl module while rdmd seems to recognize it? What I think is happening:

Re: System programming in D (Was: The God Language)

On 5 January 2012 15:44, Andrej Mitrovic wrote: > About your junior comment, are virtuals really the biggest thing you > should worry about? Sure it's not the biggest thing, it's one of numerous things. You'll notice a listed a whole bunch of things in my post, and this isn't my thread, these w

Re: Specialization - Major hole in the spec?

On 01/05/2012 10:14 AM, Peter Alexander wrote: On 5/01/12 1:53 AM, Timon Gehr wrote: On 01/05/2012 03:01 AM, Peter Alexander wrote: On 5/01/12 1:19 AM, Timon Gehr wrote: foo!int(0); // 1 Matches both 1 and 2. 2 is strictly more specialized, therefore 2 is chosen. Mistake on your side. It c

Re: System programming in D (Was: The God Language)

On 01/05/2012 10:02 AM, Manu wrote: ... Also, D is NOT a good compiler, it's a rubbish compiler with respect to code generation. [snip.] D is not a compiler, it is a language. Furthermore it is not true that DMDs backend is rubbish and there are already more backends than just the DMC backend

Compiler for multiple languages, including D

http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 Andrei

Re: Compiler for multiple languages, including D

2012/1/5 Andrei Alexandrescu > http://l33ts.org/forum/Thread-**my-online-multiple-language-** > compiler?pid=575304#pid575304 > > Andrei > Good, but what is the point in having an online compiler? I can't th

Re: Compiler for multiple languages, including D

On Thursday, 5 January 2012 at 16:04:58 UTC, Andrei Alexandrescu wrote: http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 That looks ... pretty useless, at least right now. Let's not make this newsgroup a trash dump for every single mention about D on the

Re: Double Checked Locking

On 1/5/12 4:16 AM, Manfred Nowak wrote: Andrei Alexandrescu wrote: specification can be refined 1) I do not see such refinements for D. The shared qualifier is meant to guarantee sequential consistency. This is not yet implemented. 2) If there is _no_ requirement for such refinements to

Re: Compiler for multiple languages, including D

On 1/5/12 10:10 AM, Vladimir Panteleev wrote: On Thursday, 5 January 2012 at 16:04:58 UTC, Andrei Alexandrescu wrote: http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 That looks ... pretty useless, at least right now. Let's not make this newsgroup a tra

Re: The God Language

On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote: http://pastebin.com/AtuzJqh0 I thought this topic was about a mix of Go (Google Language) and D.

Re: Compiler for multiple languages, including D

On 05/01/2012 16:04, Andrei Alexandrescu wrote: http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 Andrei Dunno about anyone else, but I wouldn't trust anyone "compiling" code for you then letting you download it. How can you be sure they're not injectin

Re: Some Issues With Synchronized

It's just like ctors of invariant classes being invariant. Initialization should be exempt from the rules surrounding other accesses. Sent from my iPhone On Jan 4, 2012, at 5:06 PM, Andrew Wiley wrote: > On Wed, Jan 4, 2012 at 6:12 PM, Sean Kelly wrote: >> On Jan 4, 2012, at 2:55 PM, Andrew

Re: System programming in D (Was: The God Language)

> > D is not a compiler, it is a language. Furthermore it is not true that > DMDs backend is rubbish and there are already more backends than just the > DMC backend. > Sorry, I was generalising a little general in that claim. And where I say 'rubbish', I was drawing comparison to the maturity of C

Re: System programming in D (Was: The God Language)

On 1/5/12 10:49 AM, Manu wrote: I make this argument in support of the language expressing optimal constructs with ease and by default, rather than expressing some concept that feels nice to programmers, but puts a burden on the whole-program-optimiser to fix. For example, virtual-by-default RELI

Re: Compiler for multiple languages, including D

Andrei Alexandrescu: > http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 Please keep showing the interesting links you find about D :-) I don't agree with Vladimir Panteleev this time. Bye, bearophile

Re: Compiler for multiple languages, including D

On Thursday, 5 January 2012 at 18:06:33 UTC, bearophile wrote: Andrei Alexandrescu: http://l33ts.org/forum/Thread-my-online-multiple-language-compiler?pid=575304#pid575304 Please keep showing the interesting links you find about D :-) I don't agree with Vladimir Panteleev this time. Maybe t

Re: System programming in D (Was: The God Language)

On 5 January 2012 19:35, Andrei Alexandrescu wrote: > On 1/5/12 10:49 AM, Manu wrote: > >> I make this argument in support of the language expressing optimal >> constructs with ease and by default, rather than expressing some concept >> that feels nice to programmers, but puts a burden on the >> w

x64 call instruction E8 00 00 00 00?

I can't wrap my brain around how the calls in dmd's x64 output code work. According to http://siyobik.info/main/reference/instruction/CALL it is a call relative to the next instruction (RIP). And objdump prints just that. <_D4test3fooFZi>: 0: 48 c7 c0 01 00 00 00mov

Re: x64 call instruction E8 00 00 00 00?

On Thu, 05 Jan 2012 19:29:06 +0100, Trass3r wrote: > I can't wrap my brain around how the calls in dmd's x64 output code > work. According to http://siyobik.info/main/reference/instruction/CALL > it is a call relative to the next instruction (RIP). objdump shows the address as 0 because the offse

Re: System programming in D (Was: The God Language)

On Jan 5, 2012, at 10:02 AM, Manu wrote: > > That said, this is just one of numerous issues myself and the OP raised. I > don't know why this one became the most popular for discussion... my > suspicion is that is because this is the easiest of my complaints to dismiss > and shut down ;) It's

Re: x64 call instruction E8 00 00 00 00?

Thanks for shedding some light on this. I wonder though why disassembling "works" in some cases and sometimes not: int foo() { asm { naked; mov RAX, 1; } } void main() { int i = foo(); } yields <_Dmain>: 0: 55

Re: System programming in D

Manu writes: > It's rare to step through optimised code. You tend to debug and step in debug/ > unoptimised builds, where inline functions are usually not even inlined, and > code flow still looks natural, and easy to follow.. This saves lots of time. > C/C++ macros present the same problem of not

Re: System programming in D (Was: The God Language)

> A language defined 128bit SIMD type would be fine for basically all > architectures. Even though they support different operations on these > registers, the size and allocation patterns are always the same across all > architectures; 128 bits, 16byte aligned, etc. This allows at minimum > platfo

Re: System programming in D (Was: The God Language)

On 5 January 2012 21:41, Sean Kelly wrote: > On Jan 5, 2012, at 10:02 AM, Manu wrote: > > > > That said, this is just one of numerous issues myself and the OP raised. > I don't know why this one became the most popular for discussion... my > suspicion is that is because this is the easiest of my

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:33, a wrote: > > > A language defined 128bit SIMD type would be fine for basically all > > architectures. Even though they support different operations on these > > registers, the size and allocation patterns are always the same across > all > > architectures; 128 bits, 16byt

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:16 AM, Manu wrote: On 5 January 2012 03:06, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 1/4/2012 4:30 PM, Sean Kelly wrote: If a library is written without consideration to what is virtual and what is not, its performance will be the least of y

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:13 AM, Manu wrote: In 15 years I have never once overridden a non-virtual function, assuming it was virtual, and wondering why it didn't work... have you? Yes, I have. With a complex inheritance hierarchy, I was doing the optimization thing and removing 'virtual' from members tha

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:02 AM, Manu wrote: My argument is that even IF the compiler some day attempts to make vector optimisations to float[4] arrays, the raw hardware should be exposed first, and allow programmers to use it directly. This starts with a language defined (platform independant) v128 type.

Re: Compiler for multiple languages, including D

1) Hosted on someone's personal computer. 2) Person can't even make the effort to make a proper English post about it. 3) Posted on a forum that's dedicated to warez and making viruses. 4) Expect to download a binary file from the above. Seriously? -_- On 05/01/2012 10:04 AM, Andrei Alexandrescu

Re: System programming in D (Was: The God Language)

On Jan 5, 2012, at 12:36 PM, Manu wrote: > On 5 January 2012 21:41, Sean Kelly wrote: > On Jan 5, 2012, at 10:02 AM, Manu wrote: > > > > That said, this is just one of numerous issues myself and the OP raised. I > > don't know why this one became the most popular for discussion... my > > suspic

Re: System programming in D (Was: The God Language)

> > That is the case with overriding a non-virtual function - the compiler > will compile it anyway, and most of the time it will work. That's what > makes it so eeevil. I saw today, or last night, someone suggesting a keyword to make non-virtual override explicit, and error otherwise. Which actu

Re: System programming in D (Was: The God Language)

On Jan 5, 2012, at 1:03 PM, Manu wrote: > That is the case with overriding a non-virtual function - the compiler will > compile it anyway, and most of the time it will work. That's what makes it so > eeevil. > > I saw today, or last night, someone suggesting a keyword to make non-virtual > ove

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:47, Walter Bright wrote: > On 1/5/2012 1:02 AM, Manu wrote: > >> My argument is that even IF the compiler some day attempts to make vector >> optimisations to float[4] arrays, the raw hardware should be exposed >> first, and >> allow programmers to use it directly. This start

Re: Specialization - Major hole in the spec?

On 5/01/12 3:11 PM, Timon Gehr wrote: On 01/05/2012 10:14 AM, Peter Alexander wrote: On 5/01/12 1:53 AM, Timon Gehr wrote: On 01/05/2012 03:01 AM, Peter Alexander wrote: On 5/01/12 1:19 AM, Timon Gehr wrote: foo!int(0); // 1 Matches both 1 and 2. 2 is strictly more specialized, therefore 2

Re: System programming in D (Was: The God Language)

On 1/5/2012 8:49 AM, Manu wrote: I also wonder if the D language provides some opportunities for optimisation that aren't expressible in other languages, There are some. One that is currently being exploited by the optimizer and back end is the existence of pure functions. and therefore may

Re: System programming in D (Was: The God Language)

On 1/5/2012 10:02 AM, Manu wrote: That said, this is just one of numerous issues myself and the OP raised. I don't know why this one became the most popular for discussion... my suspicion is that is because this is the easiest of my complaints to dismiss and shut down ;) That's a common phenome

Re: System programming in D (Was: The God Language)

On 1/5/2012 3:58 AM, Manu wrote: How is this possible, when all functions are virtual, without whole program optimisation? Only public non-final class member functions are virtual. Furthermore, as in C++, the compiler can sometimes determine that a virtual function is being called directly, a

Re: System programming in D (Was: The God Language)

On 1/5/2012 6:06 AM, Manu wrote: It would also be generally nice if these concerns were acknowledged rather than brushed off. I'm not making problems for the sake of conversation. These are real issues that I encounter in my daily work. I do appreciate your effort in making these issues known t

Re: Specialization - Major hole in the spec?

On Thursday, 5 January 2012 at 15:11:13 UTC, Timon Gehr wrote: On 01/05/2012 10:14 AM, Peter Alexander wrote: In any case, it is surely a bug. I have *explicitly* specified that T must be int, yet it has called a version with T == float. No it has called a version with T : float. ":" means "

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:22 PM, Manu wrote: Love to. I'll give it some thorough thought. There's more details than I think most would expect... I know the devil is in the details :-) Anyhow, please start a new topic for that one. This thread is getting too large.

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:03, Sean Kelly wrote: > > I think they are all language requests. They could be implemented by 3rd > party compilers, but these things are certainly nice to standardise in the > language, or you end up with C, which is a mess I'm trying to escape. > > It's a grey area I suppo

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:30, Walter Bright wrote: > On 1/5/2012 8:49 AM, Manu wrote: > >> I also wonder if the D language provides some opportunities for >> optimisation >> that aren't expressible in other languages, >> > > There are some. One that is currently being exploited by the optimizer and >

Re: System programming in D (Was: The God Language)

On 5 January 2012 20:36, Manu wrote: > On 5 January 2012 21:41, Sean Kelly wrote: >> >> On Jan 5, 2012, at 10:02 AM, Manu wrote: >> > >> > That said, this is just one of numerous issues myself and the OP raised. >> > I don't know why this one became the most popular for discussion... my >> > susp

Re: System programming in D (Was: The God Language)

On Jan 5, 2012, at 1:42 PM, Manu wrote: > Most C compilers also don't allow program optimisation/rescheduling around > inline asm blocks, this makes them useless, and I'll bet GDC suffers the same > problem right now(…?) Not sure about GDC. At one time, I pushed for keeping "volatile" alive so

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:34, Walter Bright wrote: > On 1/5/2012 3:58 AM, Manu wrote: > >> How is this possible, when all functions are virtual, without whole >> program >> optimisation? >> > > Only public non-final class member functions are virtual. Furthermore, as > in C++, the compiler can sometim

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:50, Iain Buclaw wrote: > > * inline asm supporting pseudo regs - As an extension of using the > vector > > hardware, I'll need inline asm, and inline assembly without pseudo regs > is > > pretty useless... it's mandatory that the compiler shedule the register > > allocation

Re: System programming in D (Was: The God Language)

On 5 January 2012 16:49, Manu wrote: >> D is not a compiler, it is a language. Furthermore it is not true that >> DMDs backend is rubbish and there are already more backends than just the >> DMC backend. > > > Sorry, I was generalising a little general in that claim. And where I say > 'rubbish', I

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:53, Sean Kelly wrote: > I recall Walter rejecting the idea because compilers shouldn't optimize > across asm blocks. This should probably be revisited at some point. > It's proven then, inline asm blocks break the optimiser... they are officially useless. This is why all C

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:01, Manu wrote: > On 5 January 2012 23:50, Iain Buclaw wrote: >> >> >   * inline asm supporting pseudo regs - As an extension of using the >> > vector >> > hardware, I'll need inline asm, and inline assembly without pseudo regs >> > is >> > pretty useless... it's mandatory th

Re: System programming in D (Was: The God Language)

So regarding my assumptions about translating the D front end expressions to GCC? Is that all simpler than I imagine? Do you think GDC generates optimal code comparable to C code? What about pure functions, can you make good on optimisations like caching results of pure functions, moving them outs

Re: System programming in D (Was: The God Language)

On 01/05/12 22:50, Iain Buclaw wrote: > I don't think D enforces any sort of aliasing rules, but it would be > nice to turn on strict aliasing though... -fstrict-aliasing is already turned on by default in gdc... artur

Re: System programming in D (Was: The God Language)

On 6 January 2012 00:10, Iain Buclaw wrote: > The reasoning behind is more so that you can write asm statements on > all architectures, not just x86. And with GDC being a frontend of GCC, > seems a natural thing to support (this has actually been in GDC since > 2004, so I'm not sure why you shoul

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:11, Manu wrote: > So regarding my assumptions about translating the D front end expressions to > GCC? Is that all simpler than I imagine? > Do you think GDC generates optimal code comparable to C code? > > What about pure functions, can you make good on optimisations like cach

Re: System programming in D (Was: The God Language)

On 6 January 2012 00:17, Iain Buclaw wrote: > On 5 January 2012 22:11, Manu wrote: > > So regarding my assumptions about translating the D front end > expressions to > > GCC? Is that all simpler than I imagine? > > Do you think GDC generates optimal code comparable to C code? > > > > What about

Re: System programming in D (Was: The God Language)

On Thursday, 5 January 2012 at 21:05:07 UTC, Sean Kelly wrote: On Jan 5, 2012, at 1:03 PM, Manu wrote: That is the case with overriding a non-virtual function - the compiler will compile it anyway, and most of the time it will work. That's what makes it so eeevil. I saw today, or last night,

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:16, Manu wrote: > On 6 January 2012 00:10, Iain Buclaw wrote: >> >> The reasoning behind is more so that you can write asm statements on >> all architectures, not just x86. And with GDC being a frontend of GCC, >> seems a natural thing to support (this has actually been in GD

Re: Compiler for multiple languages, including D

On 05/01/2012 18:11, Vladimir Panteleev wrote: Maybe the knowledge that it takes 3 lines of PHP code to create something like this was a factor in my reply. How long are these 3 lines of PHP code that constitute a complete compiler for four different languages? Or is it really not an onlin

Re: System programming in D (Was: The God Language)

On Jan 5, 2012, at 2:08 PM, Manu wrote: > On 5 January 2012 23:53, Sean Kelly wrote: > I recall Walter rejecting the idea because compilers shouldn't optimize > across asm blocks. This should probably be revisited at some point. > > It's proven then, inline asm blocks break the optimiser... th

Re: System programming in D (Was: The God Language)

On 5/01/12 7:41 PM, Sean Kelly wrote: On Jan 5, 2012, at 10:02 AM, Manu wrote: That said, this is just one of numerous issues myself and the OP raised. I don't know why this one became the most popular for discussion... my suspicion is that is because this is the easiest of my complaints to d

Re: System programming in D (Was: The God Language)

On 5 January 2012 22:22, Manu wrote: > On 6 January 2012 00:17, Iain Buclaw wrote: >> >> On 5 January 2012 22:11, Manu wrote: >> > So regarding my assumptions about translating the D front end >> > expressions to >> > GCC? Is that all simpler than I imagine? >> > Do you think GDC generates optim

Re: Compiler for multiple languages, including D

On Thursday, 5 January 2012 at 22:53:10 UTC, Stewart Gordon wrote: Or is it really not an online compiler, but rather an online interface to a collection of compilers that the author has on his computer? Um... yes. What did you expect? o_O

Re: Specialization - Major hole in the spec?

On 5/01/12 9:37 PM, Trass3r wrote: On Thursday, 5 January 2012 at 15:11:13 UTC, Timon Gehr wrote: On 01/05/2012 10:14 AM, Peter Alexander wrote: In any case, it is surely a bug. I have *explicitly* specified that T must be int, yet it has called a version with T == float. No it has called a v

Re: Method hiding

Jesse Phillips: > > class Foo { > > string name = "c1"; > > static void foo() {} > > } > > class Bar : Foo { > > string name = "c2"; > > static void foo() {} // silent method hiding > > } > > void main() {} > > Should we just disallow this? Sometimes it's an useful idiom, and probably so

Re: System programming in D (Was: The God Language)

On 5/01/12 10:17 PM, Iain Buclaw wrote: On 5 January 2012 22:11, Manu wrote: So regarding my assumptions about translating the D front end expressions to GCC? Is that all simpler than I imagine? Do you think GDC generates optimal code comparable to C code? What about pure functions, can you ma

Re: System programming in D (Was: The God Language)

On 5/01/12 10:17 PM, Iain Buclaw wrote: On 5 January 2012 22:11, Manu wrote: So regarding my assumptions about translating the D front end expressions to GCC? Is that all simpler than I imagine? Do you think GDC generates optimal code comparable to C code? What about pure functions, can you ma

Re: Specialization - Major hole in the spec?

On Jan 5, 2012, at 3:22 PM, Peter Alexander wrote: > > On the T:int line it says "T must be int type", not "T must implicitly > convert to int". > > Where did you read that : means implicitly converts to? I can't find it > anywhere on the site, or in TDPL. That's how "is" expressions work. I

Re: System programming in D (Was: The God Language)

On 5 January 2012 23:40, Peter Alexander wrote: > On 5/01/12 10:17 PM, Iain Buclaw wrote: >> >> On 5 January 2012 22:11, Manu  wrote: >>> >>> So regarding my assumptions about translating the D front end expressions >>> to >>> >>> GCC? Is that all simpler than I imagine? >>> Do you think GDC gener

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:58 PM, Manu wrote: On 5 January 2012 23:34, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 1/5/2012 3:58 AM, Manu wrote: How is this possible, when all functions are virtual, without whole program optimisation? Only public non-final class me

Re: System programming in D (Was: The God Language)

On 1/5/2012 2:57 PM, Sean Kelly wrote: For the record, some compilers do optimize across asm blocks. It's simply DMD/DMC that doesn't. Though the lack of "volatile" makes doing this unsafe in D as a general rule. dmd does keep track of register usage within asm blocks.

Re: System programming in D (Was: The God Language)

Peter Alexander: > void foo(int x) > { > int[10] a; > foreach (ref e; a) > e = bar(x); > } > > If bar is pure then you can safely transform this into: > > void foo(int x) > { > int[10] a; > auto barx = bar(x); > foreach (ref e; a) > e = barx; > } If ba

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:03 PM, Manu wrote: That is the case with overriding a non-virtual function - the compiler will compile it anyway, and most of the time it will work. That's what makes it so eeevil. I saw today, or last night, someone suggesting a keyword to make non-virtual override ex

Re: System programming in D (Was: The God Language)

On 1/5/2012 1:43 PM, Manu wrote: On 5 January 2012 23:30, Walter Bright mailto:newshou...@digitalmars.com>> wrote: On 1/5/2012 8:49 AM, Manu wrote: I also wonder if the D language provides some opportunities for optimisation that aren't expressible in other languages,

Re: Specialization - Major hole in the spec?

On Thursday, 5 January 2012 at 23:11:31 UTC, Peter Alexander wrote: http://dlang.org/templates-revisited.html Each can have default values, and type parameters can have (a limited form of) constraints: class B { ... } in

Re: Specialization - Major hole in the spec?

I think another good question is alias this (and thus also our future library typedef). Should 'void foo(T:void*)(T int)' really reject a 'struct A {void* b; alias b this;}'? Don't think so.

Re: System programming in D (Was: The God Language)

On 6 January 2012 00:03, Walter Bright wrote: > On 1/5/2012 1:43 PM, Manu wrote: >> >> On 5 January 2012 23:30, Walter Bright > >> > wrote: >> >>    On 1/5/2012 8:49 AM, Manu wrote: >> >>        I also wonder if the D language provides some opportunities for >> o

Re: Specialization - Major hole in the spec?

On 01/06/2012 12:22 AM, Peter Alexander wrote: On 5/01/12 9:37 PM, Trass3r wrote: On Thursday, 5 January 2012 at 15:11:13 UTC, Timon Gehr wrote: On 01/05/2012 10:14 AM, Peter Alexander wrote: In any case, it is surely a bug. I have *explicitly* specified that T must be int, yet it has called a

Re: Specialization - Major hole in the spec?

On Friday, January 06, 2012 01:47:03 Timon Gehr wrote: > On 01/06/2012 12:22 AM, Peter Alexander wrote: > > On 5/01/12 9:37 PM, Trass3r wrote: > >> On Thursday, 5 January 2012 at 15:11:13 UTC, Timon Gehr wrote: > >>> On 01/05/2012 10:14 AM, Peter Alexander wrote: > In any case, it is surely a

Re: Method hiding

On Thursday, 5 January 2012 at 23:12:21 UTC, bearophile wrote: Override usage is going to be (hopefully soon) compulsory in D (currently you need -w to see an error). So that code without both static and override is going to be refused :-) Bye, bearophile I guess the question I was getting a

  1   2   >