On 2012-04-16 02:33, Jonathan M Davis wrote:
It definitely looks like a bug. Whether it returns Foo or Object should have no
effect on constness, and since f is a member variable of Foo, and the this
pointer/reference is const, bar is going to have to return a const reference
to it, which the se
On Monday, 16 April 2012 at 04:05:35 UTC, Ary Manzana wrote:
On 4/16/12 12:00 PM, F i L wrote:
On Monday, 16 April 2012 at 03:25:15 UTC, bearophile wrote:
F i L:
I should be able to tackle something like adding a compiler
flag to
default FP variables to zero. If I write the code, would
anyon
On 4/16/12 12:00 PM, F i L wrote:
On Monday, 16 April 2012 at 03:25:15 UTC, bearophile wrote:
F i L:
I should be able to tackle something like adding a compiler flag to
default FP variables to zero. If I write the code, would anyone
object to having a flag for this?
I strongly doubt Walter &
On Monday, 16 April 2012 at 03:25:15 UTC, bearophile wrote:
F i L:
I should be able to tackle something like adding a compiler
flag to default FP variables to zero. If I write the code,
would anyone object to having a flag for this?
I strongly doubt Walter & Andrei will accept this in the ma
F i L:
I should be able to tackle something like adding a compiler
flag to default FP variables to zero. If I write the code,
would anyone object to having a flag for this?
I strongly doubt Walter & Andrei will accept this in the main DMD
trunk.
Bye,
bearophile
Actually, all of this discussion has made me think that having a
compiler flag to change FP values to zero as default would be a
good idea.
Basically my opinion is largely influenced by a couple things.
That is:
- I believe a lot of good programmers are used to using zero for
default. Winni
Jerome BENOIT wrote:
Just because mathematical equations behave differently with
zero doesn't change the fact that zero _conceptually_
represents "nothing"
You are totally wrong: here we are dealing with key concept of
the group theory.
Zero is the starting place for any (daily used) scale.
Forums are messing up, so I'll try and respond in sections.
I'm trying to figure out how to achieve folder deletion times
close to the times achieved with the parallel rmd after myDefrag
sortByName on a folder. It takes less than 3.5 secs for a 2G
layout that has been sorted, and with the rmd configured so that
it also works on a sorted list. This is a
On Sunday, April 15, 2012 21:20:23 sclytrack wrote:
> this( const size_t step) const
> {
> this.step = step;
> }
>
>
> Error: cannot modify const/immutable/inout expression this.step
>
>
> Is this the expected behavior? Thanks.
const and immutable postblit const
On Sunday, April 15, 2012 17:57:27 Jacob Carlborg wrote:
> class Foo
> {
> Foo f;
>
> Foo bar () const
> {
> return f;
> }
> }
>
> The above code results in the compile error:
>
> Error: cannot implicitly convert expression (this.f) of type const(Foo)
> to test.Foo
>
On 04/15/2012 01:27 PM, jerro wrote:
- Return 0 from main() for successful exit, anything else by
convention means some sort of error.
Why not just declare main return type to be void?
That's much better. :) D takes care of doing the right thing in that case.
Ali
On 04/15/2012 02:23 PM, Kevin Cox wrote:
On Apr 15, 2012 4:30 AM, "Joseph Rushton Wakeling"
mailto:joseph.wakel...@webdrake.net>> wrote:
> ... the compiler accepts it. Whether that's because it's acceptably
pure, or because the compiler just doesn't detect this case of impurity,
is another mat
Le 15/04/2012 23:41, Somedude a écrit :
> Le 15/04/2012 23:33, Ashish Myles a écrit :
>> On Sun, Apr 15, 2012 at 5:16 PM, Somedude wrote:
>
> Oh right, sorry for this. It's a bit confusing.
Now apart from comparing the generated asm, I don't see.
Le 15/04/2012 23:33, Ashish Myles a écrit :
> On Sun, Apr 15, 2012 at 5:16 PM, Somedude wrote:
>> Le 15/04/2012 09:23, ReneSac a écrit :
>>> On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling wrote:
> On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton Wakeling
> wrot
Le 15/04/2012 20:40, Russel Winder a écrit :
> On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote:
> [...]
>> (my old GDC needs the explicit "function", no idea if newer
>> frontends still require that)
>
> OK, works for me with GDC as well, DMD is broken! I'll file a bug
> report.
>
It work
On Sun, Apr 15, 2012 at 5:16 PM, Somedude wrote:
> Le 15/04/2012 09:23, ReneSac a écrit :
>> On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling wrote:
On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton Wakeling
wrote:
> GDC has all the regular gcc optimization
Le 15/04/2012 09:23, ReneSac a écrit :
> On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling wrote:
>>> On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton Wakeling
>>> wrote:
GDC has all the regular gcc optimization flags available IIRC. The
>>
>
>
I notice the 2D arra
On Saturday, 14 April 2012 at 10:48:16 UTC, Luis Panadero
Guardeño wrote:
What is the status of "shared" types ?
I try it with gdmd v4.6.3
And I not get any warring/error when I do anything over a
shared variable
without using atomicOp. It's normal ?
shared ushort ram[ram_size];
ram
On 15/04/2012 21:07, Trass3r wrote:
Am 15.04.2012, 21:20 Uhr, schrieb sclytrack :
this( const size_t step) const
{
this.step = step;
}
Error: cannot modify const/immutable/inout expression this.step
Is this the expected behavior? Thanks.
Yep.
No it's not:
import std.stdio;
struct foo
- Return 0 from main() for successful exit, anything else by
convention means some sort of error.
Why not just declare main return type to be void?
Am 15.04.2012, 21:20 Uhr, schrieb sclytrack :
this( const size_t step) const
{
this.step = step;
}
Error: cannot modify const/immutable/inout expression this.step
Is this the expected behavior? Thanks.
Yep.
On 04/15/2012 11:39 AM, Xan wrote:
> On Sunday, 15 April 2012 at 11:23:37 UTC, John Chapman wrote:
>> On Sunday, 15 April 2012 at 11:16:43 UTC, Xan wrote:
>>>
>>> int main(string [] args)
>>> {
>>> auto alg = Algorisme!(int,int);
>>
>> Should be:
>> auto alg = new Algorisme!(int, int);
>>
>>> alg.
this( const size_t step) const
{
this.step = step;
}
Error: cannot modify const/immutable/inout expression this.step
Is this the expected behavior? Thanks.
On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote:
[...]
> (my old GDC needs the explicit "function", no idea if newer
> frontends still require that)
OK, works for me with GDC as well, DMD is broken! I'll file a bug
report.
--
Russel.
===
On Sunday, 15 April 2012 at 11:23:37 UTC, John Chapman wrote:
On Sunday, 15 April 2012 at 11:16:43 UTC, Xan wrote:
int main(string [] args)
{
auto alg = Algorisme!(int,int);
Should be:
auto alg = new Algorisme!(int, int);
alg.nom = "Doblar";
alg.versio = 1;
alg.funcio = (i
On 04/15/2012 03:03 AM, Luis Panadero Guardeño wrote:
Auto response :
the main thread ends, and It signal func to end, so It never receive
any message from clock. I fix it, doing that main sleep 1000 seconds
after sending func Tid to clock
This too should work at the end of main():
thread
class Foo
{
Foo f;
Foo bar () const
{
return f;
}
}
The above code results in the compile error:
Error: cannot implicitly convert expression (this.f) of type const(Foo)
to test.Foo
But if I change "bar" to:
Object bar () const
{
return f;
}
I don't get any error
On 04/15/12 15:55, Russel Winder wrote:
> On Sat, 2012-04-14 at 23:25 +0200, Artur Skawina wrote:
> [...]
>>
>> 'threads' is a (lazy) range;
>>
>>auto threads = array(map ! ( ( int a ) {
>>void delegate ( ) f ( ) {
>> return delegate ( ) { writeln ( a )
On Sat, 2012-04-14 at 23:27 +0200, Somedude wrote:
[...]
> This works:
>
> int main ( immutable string[] args ) {
>
> auto threadgroup = new ThreadGroup();
>
> void delegate ( ) f (int a ) {
> return delegate ( ) { writeln ( a ) ; } ;
> }
>
> for ( int n = 0; n < 10; n++ ) {
> t
On Sat, 2012-04-14 at 17:10 -0400, Matt Soucy wrote:
[...]
> If you merge the two foreach loops into one, doing t.start();t.join();
> it doesn't have this issue. Also, when I run your code repeatedly the
> number of successful numbers printed changes a lot.
> I'm assuming that you're trying to jo
On Sat, 2012-04-14 at 23:25 +0200, Artur Skawina wrote:
[...]
>
> 'threads' is a (lazy) range;
>
>auto threads = array(map ! ( ( int a ) {
>void delegate ( ) f ( ) {
> return delegate ( ) { writeln ( a ) ; } ;
>}
>retu
Jonathan M Davis wrote:
On Saturday, April 14, 2012 20:47:20 Piotr Szturmaj wrote:
struct CommonInputRange(E)
{
@property bool delegate() empty;
@property E delegate() front;
void delegate() popFront;
}
front returns an element in the range. In your case, it's returning a
de
Artur Skawina wrote:
On 04/15/12 03:01, Piotr Szturmaj wrote:
Artur Skawina wrote:
@property is for functions masquerading as data, i'm not sure extending it
to pointers and delegates would be a good idea. What you are asking for is
basically syntax sugar for:
struct CommonInputRange(E)
On 04/15/12 03:01, Piotr Szturmaj wrote:
> Artur Skawina wrote:
>> @property is for functions masquerading as data, i'm not sure extending it
>> to pointers and delegates would be a good idea. What you are asking for is
>> basically syntax sugar for:
>>
>> struct CommonInputRange(E)
>> {
>>
On Apr 15, 2012 4:30 AM, "Joseph Rushton Wakeling" <
joseph.wakel...@webdrake.net> wrote:
> ... the compiler accepts it. Whether that's because it's acceptably
pure, or because the compiler just doesn't detect this case of impurity, is
another matter. The int k is certainly mutable from outside t
On Sunday, 15 April 2012 at 11:16:43 UTC, Xan wrote:
int main(string [] args)
{
auto alg = Algorisme!(int,int);
Should be:
auto alg = new Algorisme!(int, int);
alg.nom = "Doblar";
alg.versio = 1;
alg.funcio = (int a) {return 2*a};
Should be:
alg.funcio = (int a)
hi,
I have this code:
import std.conv, std.stdio, std.stream, std.string;
import std.socket, std.socketstream;
import std.datetime;
class Algorisme(U,V) {
string nom;
uint versio;
V delegate (U) funcio;
}
int main(string [] args)
{
auto alg = Algorisme!(int,int);
alg.nom =
Auto response :
the main thread ends, and It signal func to end, so It never receive
any message from clock. I fix it, doing that main sleep 1000 seconds
after sending func Tid to clock
Luis Panadero Guardeño wrote:
> I'm trying to implement a clock thread that sends messages and get
> blocked
I'm trying to implement a clock thread that sends messages and get
blocked when the message queue it's full.
So I try this:
void func() {
int n;
while (1) {
receive( (int i) { writeln(n, " : Received the number ", i); n++;}
);
}
}
void clock() {
receive((Tid tid) {
while (1) {
On 15.04.2012 12:29, Joseph Rushton Wakeling wrote:
On 15/04/12 09:23, ReneSac wrote:
What really amazes me is the difference between g++, DMD and GDC in
size of
the executable binary. 100 orders of magnitude!
I have remarked it in another topic before, with a simple "hello
world". I need
to up
On 15/04/12 10:29, Joseph Rushton Wakeling wrote:
... the compiler accepts it. Whether that's because it's acceptably pure, or
because the compiler just doesn't detect this case of impurity, is another
matter. The int k is certainly mutable from outside the scope of the function,
so AFAICS it _sh
On 15/04/12 09:23, ReneSac wrote:
What really amazes me is the difference between g++, DMD and GDC in size of
the executable binary. 100 orders of magnitude!
I have remarked it in another topic before, with a simple "hello world". I need
to update there, now that I got DMD working. BTW, it is 2
On Sunday, 15 April 2012 at 02:56:21 UTC, Joseph Rushton Wakeling
wrote:
On Saturday, 14 April 2012 at 19:51:21 UTC, Joseph Rushton
Wakeling wrote:
GDC has all the regular gcc optimization flags available
IIRC. The ones on the
GDC man page are just the ones specific to GDC.
I'm not talking abou
44 matches
Mail list logo
