On 2011-10-21 07:00, Kagamin wrote:
Jacob Carlborg Wrote:
Even if one would use Phobos, Tango still have things to offer over
Phobos. For example, support for OpenSSL, cryptographic, a net library
that doesn't depend on external libraries and a better XML library.
Hmm... does phobos offer
On 2011-10-20 20:16, SiegeLord wrote:
Eric Poggel (JoeCoder) Wrote:
That's what I do now with Tango 1.
But if every library I used required separate installation steps
(instead of just pitting it in the repository), there would be about a
dozen to install. I want to keep things as simple as
On 10/20/2011 10:00 PM, Kagamin wrote:
Jacob Carlborg Wrote:
Even if one would use Phobos, Tango still have things to offer over
Phobos. For example, support for OpenSSL, cryptographic, a net library
that doesn't depend on external libraries and a better XML library.
Hmm... does Phobos offer
On 21.10.2011 05:24, Robert Jacques wrote:
On Thu, 20 Oct 2011 09:11:27 -0400, Don nos...@nospam.com wrote:
[snip]
I'd like to get to the situation where those overloads can be added
without breaking peoples code. The draconian possibility is to disallow
them in all cases: integer types never
Naturally, as with all my posts, I'm not referring to x86 :)
L1 is rarely ~1 cycle access, there are even a few architectures that can't
write to L1 at all, and I've never come in contact with a compiler that can
do anything useful with the const keyword in C. That said __restrict is
fundamentally
Just need to vent a little about this...
This is very nice:
class Foo
{
string doSomething(string str)
{ return ...; }
void blah(int[] arr, string[] defines)
{
auto a = arr .filter!a10() .map!a*2() .reduce!a+b();
auto b = defines.map!`--define=~a`() .join( )
On 2011-10-20 19:36, Steven Schveighoffer wrote:
On Thu, 20 Oct 2011 12:26:29 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-20 16:20, Steven Schveighoffer wrote:
On Thu, 20 Oct 2011 10:07:12 -0400, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
D's runtime type info is very
On 2011-10-20 22:29, Marco Leise wrote:
Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg d...@me.com:
On 2011-10-20 11:38, Gor Gyolchanyan wrote:
Not a compiler (we have 3), only a front-end. Preferably in D itself
and preferably as modular as possible (e.g. not everyone needs the
semantic
On 2011-10-20 23:49, Peter Alexander wrote:
On 20/10/11 8:37 PM, Martin Nowak wrote:
It just took me over one hour to find out the unthinkable.
foreach(c; str) will deduce c to immutable(char) and doesn't care about
unicode.
Now there is so many unicode transcoding happening in the language
On 20-10-2011 14:13, Don wrote:
On 20.10.2011 13:12, Manu wrote:
On 20 October 2011 11:02, Don nos...@nospam.com
mailto:nos...@nospam.com wrote:
On 20.10.2011 09:47, Manu wrote:
Many architectures do not support real, and therefore it should
never be
used implicitly by the language.
That would be great! that ides evaluates to:
--boilerplate;
On Thu, Oct 20, 2011 at 7:02 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/20/11 6:53 AM, kenji hara wrote:
I think std.conv.to should provide the *safe natural conversion*.
Field-to-field conversion seems not
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like the methods being virtual by default, but with ability to
make them final.
On Fri, Oct 21, 2011 at 10:29 AM, Jacob Carlborg d...@me.com
I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C facade to use a C back-end.
On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg d...@me.com wrote:
On 2011-10-20 22:29, Marco Leise wrote:
Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg
On Thu, 20 Oct 2011 22:37:56 +0300, Martin Nowak d...@dawgfoto.de wrote:
It just took me over one hour to find out the unthinkable.
foreach(c; str) will deduce c to immutable(char) and doesn't care about
unicode.
Now there is so many unicode transcoding happening in the language that
it
Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan
gor.f.gyolchan...@gmail.com:
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like the methods being virtual by default, but with ability
On 21/10/11 7:27 AM, Nick Sabalausky wrote:
Just need to vent a little about this...
This is very nice:
auto a = arr
.filter!a10()
.map!a*2()
.reduce!a+b();
Can't you do
auto a = pipe!(filter!a10, map!a*2, reduce!a+b);
???
Still not quite
On Tue, 18 Oct 2011 06:01:37 +0300, Walter Bright
newshou...@digitalmars.com wrote:
On 10/17/2011 5:56 PM, so wrote:
On Tue, 18 Oct 2011 03:52:13 +0300, Nick Sabalausky a@a.a wrote:
Thats would mean that every D compiler would have to *also* be a C
compiler.
Indeed, but i see nothing
Consider the following program:
class A(uint N) {}
void foo(uint N)(A!N) {}
void main()
{
auto a = new A!1; // compiles
foo(new A!1); // error
foo(new A!1u); // compiles
foo(cast(A!1u)
On Thu, 20 Oct 2011 00:26:58 +0300, Nick Sabalausky a@a.a wrote:
so s...@so.so wrote in message
news:op.v3ivsvb8mpw3zg@localhost.localdomain...
On Tue, 18 Oct 2011 03:32:17 +0300, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
Translating C header
files to D is a pain and time consuming, and
On 21 October 2011 09:00, Don nos...@nospam.com wrote:
On 21.10.2011 05:24, Robert Jacques wrote:
On Thu, 20 Oct 2011 09:11:27 -0400, Don nos...@nospam.com wrote:
[snip]
I'd like to get to the situation where those overloads can be added
without breaking peoples code. The draconian
Automatic removal of RTTI (as well as automatic removal if method
virtuality) could have very unpleasant effects in modular
architectures.
Consider this use case:
// Base.dll
class Base
{
string method() { return Base; }
}
// Derived.dll
class Derived: Base
{
string method() { return
That's because implicit casts in D are much more strict, then those in C/C++.
Such seemingly intuitive cats, e.g. from long to int are not performed
due to potential loss of data.
Casting from int to uint has the same effect of potential loss of data.
Probably, the compile-time versions of those
On Friday, October 21, 2011 11:57:50 Gor Gyolchanyan wrote:
That's because implicit casts in D are much more strict, then those in
C/C++. Such seemingly intuitive cats, e.g. from long to int are not
performed due to potential loss of data.
Casting from int to uint has the same effect of
Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
gor.f.gyolchan...@gmail.com:
I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C facade to use a C back-end.
On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg d...@me.com wrote:
On
That's ALL you can do in C. fill structs and call functions
(fundamental type manipulation doesn't count).
My personal research shows the following use cases of C macros (sorted
by popularity in descending order):
1. enum
2. alias (most notably, conditionally compiled ones)
3. CTFE function
4.
Unlike long - int conversions, signed - unsigned conversions are
narrowing in both ways.
If anything, those conversions should be even more strict.
On another note, i had this thought about fundamental types.
What i thought about is, making fundamental types a library solution.
What? Are you out
On 21.10.2011 02:31, Tobias Brandt wrote:
Consider the following program:
class A(uint N) {}
void foo(uint N)(A!N) {}
void main()
{
auto a = new A!1; // compiles
foo(new A!1); // error
foo(new A!1u);
On Fri, 21 Oct 2011 06:39:56 +0200, Walter Bright
newshou...@digitalmars.com wrote:
On 10/20/2011 8:58 PM, Jonathan M Davis wrote:
And why would you iterate over a string with foreach without decoding it
unless you specifically need to operate on code units (which I would
expect to
be
On Fri, 21 Oct 2011 02:20:48 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, October 20, 2011 16:57 Martin Nowak wrote:
At least it was your ∞ that revealed my bug.
The ∞ in PosInfInterval (or NegInfInterval), I presume (I don't know
where
else I've used ∞)? I'd
On Friday, October 21, 2011 11:52:25 Martin Nowak wrote:
On Fri, 21 Oct 2011 02:20:48 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, October 20, 2011 16:57 Martin Nowak wrote:
At least it was your ∞ that revealed my bug.
The ∞ in PosInfInterval (or NegInfInterval), I
Indeed, macros is a language in itself.
Then again it all boils down to type manipulation and function calls.
Not sure if it is doable but a special operator like __cmacro might be
an answer.
#define FUN(a, b)
#define DATA
could be accessed like:
__cmacro(FUN, a, b);
On 21 October 2011 10:01, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Friday, October 21, 2011 11:57:50 Gor Gyolchanyan wrote:
That's because implicit casts in D are much more strict, then those in
C/C++. Such seemingly intuitive cats, e.g. from long to int are not
performed due to
On Friday, October 21, 2011 12:20:02 Tobias Brandt wrote:
On 21 October 2011 10:01, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Friday, October 21, 2011 11:57:50 Gor Gyolchanyan wrote:
That's because implicit casts in D are much more strict, then those in
C/C++. Such seemingly intuitive
On 10/21/11 12:20 PM, Tobias Brandt wrote:
Obviously, the conversion does happen implicitly, otherwise
'new A!1' wouldn't compile (A expects a uint as parameter).
But then, why are A!1 and A!1u different types?
Because of a compiler bug, and contrary to the other answers, implicit
conversion
2011/10/21 Don nos...@nospam.com:
On 21.10.2011 02:31, Tobias Brandt wrote:
Consider the following program:
class A(uint N) {}
void foo(uint N)(A!N) {}
void main()
{
auto a = new A!1; // compiles
foo(new A!1); //
On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like the methods being virtual by default, but with
On Fri, 21 Oct 2011 06:10:30 +0200, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-10-21 03:47:55 +, Sam Hu samhudotsa...@gmail.com said:
Greetings!
I once downloaded from this NG the xml library for D2,but now I can
not find that link again.I am wondering is there any
On Fri, 21 Oct 2011 00:43:20 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 10/20/2011 9:06 PM, Jonathan M Davis wrote:
It's this very problem that leads some people to argue that string
should be
its own type which holds an array of code units (which can be accessed
when
On 2011-10-21 09:20, Gor Gyolchanyan wrote:
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like the methods being virtual by default, but with ability to
make them final.
I would like some
On 2011-10-21 09:22, Gor Gyolchanyan wrote:
I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C facade to use a C back-end.
As a fist step DDMD is only converted to D with minimal changes. The
next step is to make it more D-like when
This will defeat the philosophy of D, which stands for core
correctness, simplicity, maintainability and flexibility.
A much better solution would be to implement the AST macros, which
were discussed in a video-talk a long time ago by Walter and Andrei,
for which the macro keyword was reserved.
On 2011-10-21 09:35, Marco Leise wrote:
Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan
gor.f.gyolchan...@gmail.com:
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like the methods being
On 2011-10-21 10:07, Marco Leise wrote:
Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
gor.f.gyolchan...@gmail.com:
I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C facade to use a C back-end.
On Fri, Oct 21, 2011 at 10:34 AM,
On 2011-10-21 10:32, Gor Gyolchanyan wrote:
That's ALL you can do in C. fill structs and call functions
(fundamental type manipulation doesn't count).
My personal research shows the following use cases of C macros (sorted
by popularity in descending order):
1. enum
2. alias (most notably,
I guess it's quite difficult for a compiler to recognize the differences
between these use cases.
Well, that's because C macros suck big-time.
I don't see any other solution to the C-to-D translation problem.
On 2011-10-21 13:07, Steven Schveighoffer wrote:
On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Actually, the best idea would be to enable full reflection (much more
complete, then what we have now) by default and allow to remove it on
demand.
Just like
On 2011-10-21 11:11:49 +, Martin Nowak d...@dawgfoto.de said:
On Fri, 21 Oct 2011 06:10:30 +0200, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-10-21 03:47:55 +, Sam Hu samhudotsa...@gmail.com said:
Greetings!
I once downloaded from this NG the xml library for D2,but now
Walter Bright wrote:
On 10/17/2011 5:56 PM, so wrote:
On Tue, 18 Oct 2011 03:52:13 +0300, Nick Sabalausky a@a.a wrote:
Thats would mean that every D compiler would have to *also* be a C
compiler.
Indeed, but i see nothing wrong with it, like i see nothing wrong with
inline
asm, C never
Michel Fortin Wrote:
On 2011-10-21 03:47:55 +, Sam Hu samhudotsa...@gmail.com said:
Greetings!
I once downloaded from this NG the xml library for D2,but now I can not
find that link again.I am wondering is there any updates on this
library,if yes,could you please provide me
On 21 October 2011 10:53, Manu turkey...@gmail.com wrote:
On 21 October 2011 09:00, Don nos...@nospam.com wrote:
On 21.10.2011 05:24, Robert Jacques wrote:
On Thu, 20 Oct 2011 09:11:27 -0400, Don nos...@nospam.com wrote:
[snip]
I'd like to get to the situation where those overloads can be
On Fri, 21 Oct 2011 02:19:03 -0400, Manu turkey...@gmail.com wrote:
Naturally, as with all my posts, I'm not referring to x86 :)
Naturally, stating that upfront would drastically improve our understanding and
weighting of your arguments. :)
L1 is rarely ~1 cycle access, there are even a few
On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-21 13:07, Steven Schveighoffer wrote:
On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Actually, the best idea would be to enable full reflection (much more
complete, then
On 2011-10-21 16:17, Steven Schveighoffer wrote:
On Fri, 21 Oct 2011 08:07:57 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-21 13:07, Steven Schveighoffer wrote:
On Fri, 21 Oct 2011 03:20:09 -0400, Gor Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Actually, the best idea would be to
On Fri, 21 Oct 2011 10:54:47 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-21 16:17, Steven Schveighoffer wrote:
This can still be done. If you have the compile-time type you can always
forcefully generate the run time info (I would expect such a feature
when RTTI is fully developed).
If it comes down to it, someone can volunteer to help debug the code by
comparing it to the GPL'd library in areas where the spec seems to be
incorrect and completing the spec. I can help with this if you really
need it, I'd love to see native D support for MySQL, as it's my DB of
choice ;)
On 21/10/11 3:26 AM, Walter Bright wrote:
On 10/20/2011 2:49 PM, Peter Alexander wrote:
The whole mess is caused by conflating the idea of an array with a
variable
length encoding that happens to use an array for storage. I don't
believe there
is any clean and tidy way to fix the problem
Martin Nowak d...@dawgfoto.de writes:
Incidentally this has brought me a nice idea.
You need to combine the foreach loop 'bug' with the ability to alter
the index variable
(http://d.puremagic.com/issues/show_bug.cgi?id=6652).
Then you can construct a terrifically fast, still correct, utf8
Hi,
I've the code (see below) which produces an exception (SyncException Unable to wait
for condition)
unless synchronized is used when waiting on condition (Fedora Linux, 32 bit,
DMD 2.055).
Do I do something wrong? Using synchronized when accessing anything that is
synchronization object
On Friday, October 21, 2011 11:11 Peter Alexander wrote:
On 21/10/11 3:26 AM, Walter Bright wrote:
On 10/20/2011 2:49 PM, Peter Alexander wrote:
The whole mess is caused by conflating the idea of an array with a
variable
length encoding that happens to use an array for storage. I don't
On 10/21/2011 2:51 AM, Martin Nowak wrote:
You have a good point here. I would have immediately thrown out the loop AFTER
profiling.
What hits me here is that I had an incorrect program with built-in unicode aware
strings.
This is counterintuitive to correct unicode handling throughout the std
On 10/21/2011 4:14 AM, Steven Schveighoffer wrote:
Making such a string type would be terribly inefficient. It would make D
completely uncompetitive for processing strings.
I don't think it would. Do you have any proof to support this?
I've done string processing code, and done a lot of
On 10/20/2011 09:37 PM, Martin Nowak wrote:
It just took me over one hour to find out the unthinkable.
foreach(c; str) will deduce c to immutable(char) and doesn't care about
unicode.
Now there is so many unicode transcoding happening in the language
In the standard library. Not in the
Am 21.10.2011, 13:50 Uhr, schrieb Jacob Carlborg d...@me.com:
On 2011-10-21 10:07, Marco Leise wrote:
Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan
gor.f.gyolchan...@gmail.com:
I wouldn't call it D. It looks like C, which smells like D. But the
point is good. It's possible to make a C
Hi,
Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
information for class and struct members.
Example:
import std.stdio;
class Foo
{
static void PrintHello()
{
writeln(Hello);
}
}
void main()
{
auto info =
On 21-10-2011 21:07, Vladimir Panteleev wrote:
Hi,
Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
information for class and struct members.
Example:
import std.stdio;
class Foo
{
static void PrintHello()
{
writeln(Hello);
}
}
void main()
{
auto info =
Am 21.10.2011 21:07, schrieb Vladimir Panteleev:
Hi,
Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
information for class and struct members.
Example:
import std.stdio;
class Foo
{
static void PrintHello()
{
writeln(Hello);
}
}
void main()
{
auto info =
On 10/21/11 1:38 PM, Walter Bright wrote:
On 10/21/2011 2:51 AM, Martin Nowak wrote:
You have a good point here. I would have immediately thrown out the
loop AFTER
profiling.
What hits me here is that I had an incorrect program with built-in
unicode aware
strings.
This is counterintuitive to
On 10/21/11 1:39 PM, Walter Bright wrote:
On 10/21/2011 4:14 AM, Steven Schveighoffer wrote:
Making such a string type would be terribly inefficient. It would make D
completely uncompetitive for processing strings.
I don't think it would. Do you have any proof to support this?
I've done
On Fri, 21 Oct 2011 21:11:14 +0300, Peter Alexander
peter.alexander...@gmail.com wrote:
Of course, people will still need to understand UTF-8. I don't think
that's a problem. It's unreasonable to expect the language to do the
thinking for you. The problem is that we have people that *do*
On Fri, 21 Oct 2011 21:38:39 +0300, Jonathan M Davis jmdavisp...@gmx.com
wrote:
In another post in this thread, Walter said in reference to post on
essentially this idea: Making such a string type would be terribly
inefficient. It would make D completely uncompetitive for processing
On Fri, 21 Oct 2011 09:00:48 -0400, Manu turkey...@gmail.com wrote:
On 21 October 2011 10:53, Manu turkey...@gmail.com wrote:
On 21 October 2011 09:00, Don nos...@nospam.com wrote:
[snip]
1: Seems reasonable for literals; Integer literals and expressions should
use range propagation to use
It would still allow function hijacking.
void func(double v); exists...
func(2);
then someone comes along and adds func(float v); .. It will now hijack the
call.
That's what you mean right?
On Oct 22, 2011 1:45 AM, Robert Jacques sandf...@jhu.edu wrote:
On Fri, 21 Oct 2011 09:00:48 -0400, Manu
The main problem with this approach is how to support different versions of a
library, or of OS. It quickly becomes difficult to support anything but the
latest, or a fixed version.
It works beautifully for mature libs.
I still cannot avoid thinking that a C frontend automatically generating D
so:
IMO people are spoiled by dynamic languages
We should aim to something *better* than dynamic languages, where possible. If
you have to do certain things (even slow ones), there's no point in making
them harder than necessary in D.
Python is a good language, but it's not perfect, and in a
On Oct 21, 2011, at 4:20 PM, Fawzi Mohamed wrote:
The main problem with this approach is how to support different versions of a
library, or of OS. It quickly becomes difficult to support anything but the
latest, or a fixed version.
It works beautifully for mature libs.
I still cannot
Andrei Alexandrescu:
Latching on the notion that a problem is unsolvable is highly nocive because
it sets
up the mind for failing to not only look for solutions, but also to see
and understand them when they're in the open.
Right. Experimental psychology has confirmed this some decades
On Sat, 22 Oct 2011 02:28:28 +0300, bearophile bearophileh...@lycos.com
wrote:
so:
IMO people are spoiled by dynamic languages
We should aim to something *better* than dynamic languages, where
possible. If you have to do certain things (even slow ones), there's
no point in making them
On 10/21/2011 4:32 PM, Fawzi Mohamed wrote:
On Oct 21, 2011, at 4:20 PM, Fawzi Mohamed wrote:
The main problem with this approach is how to support different versions of
a library, or of OS. It quickly becomes difficult to support anything but
the latest, or a fixed version. It works
On 10/21/2011 12:41 AM, so wrote:
You are right, i forgot about macros, Is it only this or is there anything else?
The only other thing is what does one do about 'char' - make it a byte, ubyte,
or char D type?
On 10/21/2011 5:29 AM, Piotr Szturmaj wrote:
It's portable, BSD licensed and implements all of C90, C99 and C++98
specifications.
Preprocessing the text is not the problem. The problem is determining a D
translation of the macros.
On Fri, 21 Oct 2011 17:15:02 -0400, Alex Rønne Petersen xtzgzo...@gmail.com
wrote:
On 21-10-2011 21:07, Vladimir Panteleev wrote:
Hi,
Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
information for class and struct members.
Example:
import std.stdio;
class Foo
{
On Sat, 22 Oct 2011 01:28:28 +0200, bearophile bearophileh...@lycos.com
wrote:
so:
IMO people are spoiled by dynamic languages
We should aim to something *better* than dynamic languages, where
possible. If you have to do certain things (even slow ones), there's
no point in making them
On Fri, 21 Oct 2011 17:23:17 -0400, Daniel Gibson metalcae...@gmail.com wrote:
Am 21.10.2011 21:07, schrieb Vladimir Panteleev:
Hi,
Igor Stepanov has created a patch for DMD and Druntime which adds RTTI
information for class and struct members.
Example:
import std.stdio;
class Foo
{
static
On Fri, 21 Oct 2011 19:04:43 -0400, Manu turkey...@gmail.com wrote:
It would still allow function hijacking.
void func(double v); exists...
func(2);
then someone comes along and adds func(float v); .. It will now hijack the
call.
That's what you mean right?
Hijacking is what happends when
Daniel Murphy , dans le message (digitalmars.D.learn:30139), a écrit :
bearophile bearophileh...@lycos.com wrote in message
news:j7jepi$prp$1...@digitalmars.com...
Daniel Murphy:
2)
immutable(int[]) fun() { return new int[]; } // conversion happens here
immutable x = fun();
Bearophile's
bearophile Wrote:
I have many strings and I want to use as associative array kay a sorted
concat of two strings (it's a signature of the two strings):
import std.algorithm;
void main() {
string a = red;
string b = green;
int[string] aa;
//aa[(a ~ b).sort] = 1;
Am 21.10.2011, 06:31 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Friday, October 21, 2011 06:22:43 Marco Leise wrote:
Hi! I've been part of the team behind http://aichallenge.org/. We just
started our next challenge about 30 minutes ago.
This will be the first time that DMD 2.054 is
I'm trying to create a proxy dll( a dll forwarding all it's functions to
another dll)
I renamed the dll I want to replace (let's call him foo) to oldfoo.dll
then I created the import library oldfoo.lib and created oldfoo.def with as
syntax
LIBRARY oldfoo
IMPORTS
internalbar=oldfoo.bar
great, I'm going to try it out.
I've been looking for something fun to do while improving programming skill
for ages and this looks great :)
On Friday, October 21, 2011 16:51 simendsjo wrote:
Is this a temporary restriction?
class C {
invariant() { }
auto f() {
return 1;
}
}
Error: function C.f post conditions are not supported if the return type
is inferred
http://d.puremagic.com/issues/show_bug.cgi?id=5039
== Quote from Trass3r (u...@known.com)'s article
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
chisophu...@gmail.com:
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
article
Right now D isn't ready to be used in this fashion
It looks there's a more-or-less functional kernel
On 22.10.2011 02:06, Jonathan M Davis wrote:
On Friday, October 21, 2011 16:51 simendsjo wrote:
Is this a temporary restriction?
class C {
invariant() { }
auto f() {
return 1;
}
}
Error: function C.f post conditions are not supported if the return type
is inferred
On Saturday, October 22, 2011 01:20:05 Sean Silva wrote:
== Quote from Trass3r (u...@known.com)'s article
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
chisophu...@gmail.com:
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
article
Right now D isn't ready to be used in
In the language definition http://d-programming-language.org/struct.html, it
says:
Struct assignment t=s is defined to be semantically equivalent to:
t = S.opAssign(s);
where opAssign is a member function of S:
S* opAssign(S s)
{ ... bitcopy *this into tmp ...
... bitcopy s
You _can_ use D with no to minimal GC, but you have to be very careful. A good
chunk of the standard library would be completely unusable without the GC
(primarily anything which might allocate or append to an array), you have to
be very careful when using arrays (since appending to them
On Saturday, October 22, 2011 04:12:36 Sean Silva wrote:
You _can_ use D with no to minimal GC, but you have to be very careful.
A good chunk of the standard library would be completely unusable
without the GC (primarily anything which might allocate or append to an
array), you have to be
http://d.puremagic.com/issues/show_bug.cgi?id=6819
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=6733
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||ice-on-valid-code
http://d.puremagic.com/issues/show_bug.cgi?id=6733
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
CC||bra...@puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=6733
--- Comment #4 from Don clugd...@yahoo.com.au 2011-10-21 01:04:13 PDT ---
(In reply to comment #3)
I just bisected it down to:
commit 4c9661fa9fbd427909a334133dfc7f3869e47c31
Author: Walter Bright wal...@walterbright.com
Date: Thu Jun
1 - 100 of 110 matches
Mail list logo
