On 2012-01-05 00:31, F i L wrote:
bearophile wrote:
deadalnix:
I do agree with Andrei. Those are 2 orthogonals problems. The
optimization problem is clearly something that can be improved in D
ABI. Then, returning a tuple could be improved using thoses rules.
I agree.
The multiple retur v
On 2012-01-05 00:21, bearophile wrote:
Walter:
The only reason to use classes in D is for polymorphic behavior - and that means
virtual functions.
I don't agree, in some cases I use final class instances instead of
heap-allocated structs even when I don't need polymorphic behaviour just to
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
that C is not actually a systems language? No."
This is
2012/1/5 Raivo F.
> 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 necessar
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 necessary opengl32.lib file, however, luckily
On 12/29/2011 02:15 AM, Caligo wrote:
This is somewhat of a serious question: If there is a God (I'm not
saying there isn't, and I'm not saying there is), what language would he
choose to create the universe? It would be hard for us mortals to
imagine, but would it resemble a functional progra
On 01/03/2012 11:29 PM, Nick Sabalausky wrote:
"bcs" wrote in message
news:je0pl8$218s$1...@digitalmars.com...
On 01/03/2012 02:46 AM, Russel Winder wrote:
My proposal for a talk at ACCU 2012 showing that D and Go prove that the
C++11 standard may well be the eulogy for C++ has been accepted.
On 1/4/12 7:41 PM, Manfred Nowak wrote:
Andrei Alexandrescu wrote:
only apply to portable C++2003 code
and all
1) products derived from such code,
Yes.
2) portable code in general, if similar argument chains can be
built up.
No, because a language's specification can be refine
On Thursday, 5 January 2012 at 01:36:44 UTC, bearophile wrote:
Walter:
What is dangerous is (in C++) the ability to override a
non-virtual function, and the use of non-virtual destructors.
There is something left that I'd like to see D care more about,
method hiding:
class Foo {
string
On Wednesday, 4 January 2012 at 08:33:12 UTC, Alex Rønne
Petersen wrote:
On 03-01-2012 21:54, Iain Buclaw wrote:
Vim already comes with D syntax highlighting, however
buggy/out of date. :-)
One thing I've wanted to work on, but never had the time for
was
intelli-sense support.
Lots of pat
This isn't strictly true because it would make implementing a mutex in C
impossible. The more detailed answer is that the C/C++ (pre-0x) don't specify a
way to do this, so it's compiler and platform-dependent.
Sent from my iPhone
On Jan 4, 2012, at 4:55 PM, Manfred Nowak wrote:
> Sean Kelly
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 2 can't possibly match.
---
As for all your other replies, thanks, it all makes more
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 2 can't possibly
match.
Test it. in
On 01/05/2012 02:19 AM, Timon Gehr wrote:
All function templates are matched individually according to IFTI rules
and from the matching ones, the most specialised is chosen. Error if no
such function template exists.
Oops, this was incomplete: After the matching, first select all function
te
Andrei Alexandrescu wrote:
> only apply to portable C++2003 code
... and all
1) products derived from such code,
2) portable code in general, if similar argument chains can be
built up.
-manfred
Walter:
> What is dangerous is (in C++) the
> ability to override a non-virtual function, and the use of non-virtual
> destructors.
There is something left that I'd like to see D care more about, method hiding:
class Foo {
string name = "c1";
static void foo() {}
}
class Bar : Foo {
On 4 January 2012 09:39, Manu wrote:
> This conversation has meandered into one very specific branch, but I just
> want to add my 2c to the OP.
> I agree, I want D to be a useful systems language too. These are my issues
> to that end:
>
> * __forceinline ... I wasn't aware this didn't exist... a
On 01/05/2012 01:47 AM, Peter Alexander wrote:
I've had a look through the spec, as well as TDPL. Andrei's book
mentions nothing about template specialization, and the website is
scarce on the details. In particular, nothing is mentioned about the
interplay between specialization and overloading
On 1/4/12 6:55 PM, Manfred Nowak wrote:
Sean Kelly wrote:
to ensure a correct result.
According to Andrei's paper, there is no ensurance of a correct
result possible. If optimizations reduce runtime, then not only MTBF
will be reduced, but some problems might turn out to be incomputable
on th
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 polymorphic type, and the
language can't help with that.
On Wed, Jan 4, 2012 at 6:12 PM, Sean Kelly wrote:
> On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote:
>
>> On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly wrote:
>>>
>>>
>>> This assumes that there is no existing monitor for the object. At best
>>> you'll get a memory leak here.
>>
>> Then is there an
On 1/4/2012 3:26 PM, Manu wrote:
Is this true? Surely the REAL reason to use classes is to allocate using the GC?
Aren't struct's allocated on the stack, and passed to functions by value? Do I
need to start using the ref keyword to use GC allocated structs?
struct S { ... }
S* s = new S(); //
On 5/01/12 12:42 AM, 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 they have received
Sean Kelly wrote:
> to ensure a correct result.
According to Andrei's paper, there is no ensurance of a correct
result possible. If optimizations reduce runtime, then not only MTBF
will be reduced, but some problems might turn out to be incomputable
on that "optimized machine". Nobody will know i
On 1/4/2012 3:21 PM, bearophile wrote:
The only reason to use classes in D is for polymorphic behavior - and that
means virtual functions.
I don't agree, in some cases I use final class instances instead of
heap-allocated structs even when I don't need polymorphic behaviour just to
avoid pointe
On Jan 4, 2012, at 4:47 PM, Peter Alexander wrote:
> I've had a look through the spec, as well as TDPL. Andrei's book mentions
> nothing about template specialization, and the website is scarce on the
> details. In particular, nothing is mentioned about the interplay between
> specialization an
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 they have received only a tiny
amount of love. Are you ab
I've had a look through the spec, as well as TDPL. Andrei's book
mentions nothing about template specialization, and the website is
scarce on the details. In particular, nothing is mentioned about the
interplay between specialization and overloading -- something that is
very often misunderstood
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 deprecated when
multiple return values are introduced as a bit of built-in syntax
On Jan 4, 2012, at 3:26 PM, Manu wrote:
>
> If a library makes liberal (and completely unnecessary) virtual calls to the
> point where it performs too poorly on some architecture; lets say ARM, or PPC
> (architectures that will suffer far more than x86 form virtual calls), I can
> no longer use
On 01/05/2012 12:54 AM, Manu wrote:
On 5 January 2012 01:40, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:
On 01/05/2012 12:26 AM, Manu wrote:
You just missed a big discussion on IRC about this, where I
think I made
some fair points that people actually agreed with.
On Jan 4, 2012, at 2:55 PM, Andrew Wiley wrote:
> On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly wrote:
>>
>>
>> This assumes that there is no existing monitor for the object. At best
>> you'll get a memory leak here.
>
> Then is there any way to safely use this sort of idiom? Putting it on
> th
On Sat, 17 Dec 2011 08:47:43 +0100, Andrew Wiley
wrote:
I was looking through Jonathan Davis's pull request to remove static
constructors from std.datetime, and I realized that I don't know
whether Double Checked Locking is legal under D's memory model, and
what the requirements for it to wor
On 5 January 2012 01:40, Timon Gehr wrote:
> On 01/05/2012 12:26 AM, Manu wrote:
>
>> You just missed a big discussion on IRC about this, where I think I made
>> some fair points that people actually agreed with.
>>
>>On 1/4/2012 10:53 AM, Manu wrote:
>>
>>Oh, and virtual-by-default..
On 01/05/2012 12:26 AM, Manu wrote:
You just missed a big discussion on IRC about this, where I think I made
some fair points that people actually agreed with.
On 1/4/2012 10:53 AM, Manu wrote:
Oh, and virtual-by-default... completely unacceptable for a
systems language.
>
> Manu:
>
> > * vector type ... D has exactly no way to tell the compiler to allocate
> > 128bit vector registers, load/store, and pass then to/from functions.
> That
> > is MOST of the register memory on virtually every modern processor, and D
> > can't address it... wtf?
>
> Currently the buil
bearophile wrote:
deadalnix:
I do agree with Andrei. Those are 2 orthogonals problems. The
optimization problem is clearly something that can be improved
in D ABI. Then, returning a tuple could be improved using
thoses rules.
I agree.
The multiple retur value problem is syntaxic sugar. It
On 4 January 2012 16:28, Andrei Alexandrescu
wrote:
> On 1/4/12 3:39 AM, Manu wrote:
>
>> * __forceinline ... I wasn't aware this didn't exist... and yes,
>> despite all this discussion, I still depend on this all the time. People
>> are talking about implementing forceinline by immitating macros
Definitely!
+1
On Tue, Jan 3, 2012 at 11:18 PM, Andrei Alexandrescu
wrote:
> On 1/3/12 12:57 PM, Alex Rønne Petersen wrote:
>>
>> On 03-01-2012 16:44, Martin Nowak wrote:
>>>
>>> On Tue, 03 Jan 2012 15:39:34 +0100, Alex Rønne Petersen
>>> wrote:
>>>
On 03-01-2012 13:36, Trass3r wrote:
On 5 January 2012 01:17, Timon Gehr wrote:
> On 01/04/2012 07: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. W
You just missed a big discussion on IRC about this, where I think I made
some fair points that people actually agreed with.
On 1/4/2012 10:53 AM, Manu wrote:
>
>> Oh, and virtual-by-default... completely unacceptable for a systems
>> language.
>> most functions are NOT virtual, and finding the fa
Walter:
> The only reason to use classes in D is for polymorphic behavior - and that
> means
> virtual functions.
I don't agree, in some cases I use final class instances instead of
heap-allocated structs even when I don't need polymorphic behaviour just to
avoid pointer syntax (there is also
On 01/04/2012 07: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 virtuals, there's good
On 1/4/2012 10:53 AM, 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.
The only reason to use classes in D is for polymorphic b
On 5 January 2012 00:22, Manu wrote:
> > The multiple retur value problem is syntaxic sugar. It may be
>> > interesting, but not #1 priority.
>>
>> I don't agree. In this moment of the D development it's still more
>> important to design D well than to squeeze every bit of performance out of
>> t
On 4 January 2012 16:23, Andrei Alexandrescu
wrote:
> On 1/4/12 2:36 AM, Manu wrote:
>
>> Regardless, I'd like to put a strong +1 towards proper multiple return
>> values. The point is NOT just to have the syntactical feature (ie.
>> struct return value semantics via tuples). The point is a langua
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 virtuals, there's good chance I may not be able to
use said l
On Wed, Jan 4, 2012 at 2:12 PM, Sean Kelly wrote:
> On Dec 23, 2011, at 8:49 PM, Andrew Wiley wrote:
>
>> On Fri, Dec 23, 2011 at 8:33 PM, Andrew Wiley
>> wrote:
>>> On Fri, Dec 23, 2011 at 1:25 AM, Somedude
>>> wrote:
On windows XP with DMD 2.057, I get
Queue1: deadlock
Queue2:
Weird, it does not segfault here. Could it be some buggy Curl build?
--
Dejan Lekic - http://dejan.lekic.org
On 04.01.2012 17:26, Dejan Lekic wrote:
Weird, it does not segfault here. Could it be some buggy Curl build?
Could be. I've gotten similar segfaults on windows using wrong builds.
Nobody stops you to fill the gap with your own code...
--
Dejan Lekic - http://dejan.lekic.org
On Monday, 2 January 2012 at 16:21:16 UTC, bls wrote:
WHY PostGres ? Callback notifications/ Server-side events ...
not available in MySQL. (which you prefer in your framework)
Aye, I've done some postgres, but since my main work app
uses mysql I haven't spent a lot of time on it.
While basic
http://ubuntuforums.org/showthread.php?p=11558146
Andrei
On 1/4/12 10:06 AM, Vladimir Panteleev wrote:
On Wednesday, 4 January 2012 at 15:54:26 UTC, Andrei Alexandrescu wrote:
http://ubuntuforums.org/showthread.php?p=11558146
Curious: do you have a Google Alert set up for "D programming language"?
Yes.
Andrei
On Wednesday, 4 January 2012 at 15:54:26 UTC, Andrei Alexandrescu
wrote:
http://ubuntuforums.org/showthread.php?p=11558146
Curious: do you have a Google Alert set up for "D programming
language"?
On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu
wrote:
Hmmm, I see that the other way around. D CTFE-generated macros
are much easier to debug because you can actually print the
code before mixing it in. If it looks like valid code... great.
Paging Don Clugston: would it be f
On 1/4/12 2:36 AM, Manu wrote:
Regardless, I'd like to put a strong +1 towards proper multiple return
values. The point is NOT just to have the syntactical feature (ie.
struct return value semantics via tuples). The point is a language
guarantee that the architecture will do its best job to retur
On 1/4/12 3:39 AM, Manu wrote:
* __forceinline ... I wasn't aware this didn't exist... and yes,
despite all this discussion, I still depend on this all the time. People
are talking about implementing forceinline by immitating macros using
mixins crazy? Here's a solid reason I avoid mixins o
Did a quick test, dmd compiles fine with -gnu++0x -fpermissive (gcc 4.6.1)
Can anyone try with dmc?
On Tuesday, 3 January 2012 at 18:49:35 UTC, Martin Nowak wrote:
For real performance bottlenecks one should always examine the
assembly. For most code inlining hardly ever matters for the
runtime of your program and focusing on efficient algorithms is
most important.
What really baffles me is
On Mon, 02 Jan 2012 17:16:13 -, bls wrote:
On 01/01/2012 12:22 AM, Jimmy Cao wrote:
GUI library for Windows. Pretty easy to use.
... and should be named Forms4D
Or DForms (like WinForms from C#), or perhaps DFormed :p
I definitely like this library. Pretty straight OOP, Each DOTNET F
Manu:
> * vector type ... D has exactly no way to tell the compiler to allocate
> 128bit vector registers, load/store, and pass then to/from functions. That
> is MOST of the register memory on virtually every modern processor, and D
> can't address it... wtf?
Currently the built-in vector operat
On 01/04/2012 07:08 PM, deadalnix wrote:
Le 01/01/2012 23:46, Timon Gehr a écrit :
On 01/01/2012 11:36 PM, deadalnix wrote:
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The
On 01/04/2012 11:31 PM, Timon Gehr wrote:
Code for which no tests exist is neither correct nor incorrect.
Assertions are a neat way to detect parts of the application whose
implementation is incomplete.
Another major use of them is the checked documentation of assumptions,
mainly in method pr
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 that C is not actually a systems language? No."
> This is absurd... are you saying that you exp
On 04.01.2012 15:33, Vladimir Panteleev wrote:
On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu wrote:
Hmmm, I see that the other way around. D CTFE-generated macros are
much easier to debug because you can actually print the code before
mixing it in. If it looks like valid co
On 01/04/12 16:31, Artur Skawina wrote:
> Functions attributes seems like it could be an easy, backward compatible
> addition:
>
> @attr(attributes...)
>
> then define some obvious generic attributes like "inline" (which is
> (always|force)_inline, as it's the only one that makes sense), "noinl
Le 04/01/2012 16:54, Andrei Alexandrescu a écrit :
http://ubuntuforums.org/showthread.php?p=11558146
Andrei
I do not use ubuntu anymore. But the version of gdc in ubuntu's
repository has been bugguy for a long time, and still may be bugguy.
I did mention that in the newgroup as well as on u
Am 04.01.2012 17:26, Dejan Lekic wrote:
Weird, it does not segfault here. Could it be some buggy Curl build?
Just installed libcurl from the repos and also got a segfault.
System: Ubuntu 11.10 32bit, dmd 2.057
the versions of libcurl3 and libcurl4-openssl-dev 7.21.6-3ubuntu3, the
version st
Le 04/01/2012 15:23, Andrei Alexandrescu a écrit :
On 1/4/12 2:36 AM, Manu wrote:
Regardless, I'd like to put a strong +1 towards proper multiple return
values. The point is NOT just to have the syntactical feature (ie.
struct return value semantics via tuples). The point is a language
guarantee
Le 01/01/2012 23:46, Timon Gehr a écrit :
On 01/01/2012 11:36 PM, deadalnix wrote:
Le 31/12/2011 19:13, Timon Gehr a écrit :
On 12/31/2011 06:32 PM, Chad J wrote:
On 12/30/2011 05:27 PM, Timon Gehr wrote:
On 12/30/2011 10:36 PM, deadalnix wrote:
The #1 quality of a programmer is to act like
On 1/4/12 11:03 AM, simendsjo wrote:
On 04.01.2012 17:26, Dejan Lekic wrote:
Weird, it does not segfault here. Could it be some buggy Curl build?
Could be. I've gotten similar segfaults on windows using wrong builds.
You folks may want to reply to that thread (e.g. inviting the OP here
fo
>
> > The multiple retur value problem is syntaxic sugar. It may be
> > interesting, but not #1 priority.
>
> I don't agree. In this moment of the D development it's still more
> important to design D well than to squeeze every bit of performance out of
> the reference implementation.
>
> Example:
On Dec 19, 2011, at 7:18 AM, Manfred_Nowak wrote:
> Regan Heath wrote:
>> after reading Andrei's link I'm not so sure..
>
> If Andrei's conclusions are correct, then they are correct even for
> - the compilers under which an OS is compiled and
> - the hardware on which the OS runs.
>
> I.e. if t
deadalnix:
> I do agree with Andrei. Those are 2 orthogonals problems. The
> optimization problem is clearly something that can be improved in D ABI.
> Then, returning a tuple could be improved using thoses rules.
I agree.
> The multiple retur value problem is syntaxic sugar. It may be
> int
On Dec 23, 2011, at 8:49 PM, Andrew Wiley wrote:
> On Fri, Dec 23, 2011 at 8:33 PM, Andrew Wiley
> wrote:
>> On Fri, Dec 23, 2011 at 1:25 AM, Somedude wrote:
>>> On windows XP with DMD 2.057, I get
>>> Queue1: deadlock
>>> Queue2: works
>>> Queue3: works
>>
>> Yes, I posted another (much short
On Dec 23, 2011, at 8:33 PM, Andrew Wiley wrote:
> On Fri, Dec 23, 2011 at 1:25 AM, Somedude wrote:
>> On windows XP with DMD 2.057, I get
>> Queue1: deadlock
>> Queue2: works
>> Queue3: works
>
> Yes, I posted another (much shorter) post describing the issue with
> Queue1. In short, since Queue
I think this idea needs further consideration.
Summarizing the earlier discussion, there were four schools of
thought:
1. This is a good idea.
2. This is a good idea, but let's use github branches.
3. This is a good idea, but let's use newsgroup postings.
4. This is a good idea, but let's use
On 03-01-2012 23:34, Manu wrote:
myArray.popFront ... a property!?
no.
Indeed. .dup and .idup on arrays are ridiculous as well.
I don't know who thought this was a good idea.
- Alex
On 03-01-2012 21:54, Iain Buclaw wrote:
On 3 January 2012 20:34, Jesse Phillips wrote:
On Tuesday, 3 January 2012 at 14:30:43 UTC, Alex Rønne Petersen wrote:
On 03-01-2012 01:48, Andrej Mitrovic wrote:
Just found this:
https://github.com/he-the-great/d.vim
That is the one people should
"bcs" wrote in message
news:je0pl8$218s$1...@digitalmars.com...
> On 01/03/2012 02:46 AM, Russel Winder wrote:
>> My proposal for a talk at ACCU 2012 showing that D and Go prove that the
>> C++11 standard may well be the eulogy for C++ has been accepted.
>> http://accu.org/index.php/conferences/a
On 2012-01-03 22:46, Sean Kelly wrote:
__thread is supported under Lion via Clang.
Yeah, yeah I know, sorry. I'm keep forgetting that. But we're currently
not using that and we're still rolling our own implementation.
--
/Jacob Carlborg
This conversation has meandered into one very specific branch, but I just
want to add my 2c to the OP.
I agree, I want D to be a useful systems language too. These are my issues
to that end:
* __forceinline ... I wasn't aware this didn't exist... and yes, despite
all this discussion, I still depe
I only base my expectation on the fact that D is an open source language
maintained by a community that comes from many other areas of programming,
has a tendency to respond to user feedback, and generally seems to do it's
best to cherry pick the best bits from virtually every other language I can
Lovely! Precisely what I hoped to hear :P
On 4 January 2012 01:39, Jonathan M Davis wrote:
> On Wednesday, January 04, 2012 00:34:48 Manu wrote:
> > myArray.popFront ... a property!?
> >
> > no.
>
> And it won't compile that way if you compile with -property. It's just that
> properties used to
85 matches
Mail list logo
