Am Wed, 24 Jul 2013 02:13:50 +0200
schrieb Andrej Mitrovic :
> On 7/23/13, Johannes Pfau wrote:
> > Does anyone know why this code is not working?
> > http://dpaste.dzfl.pl/b89e7b3f
>
> Add 'static' to getAttribute and it will work. I know, it's weird, and
> I've seen this sort of workaround use
Le 23/07/2013 14:26, JS a écrit :
http://dpaste.dzfl.pl/27ca3fbd
The code compiles fine on my computer. On DPaste there is all kinds of
errors(when fixing one other errors pop up.
I am compiling to 32-bit binary and that is the only real difference I
can see, but surely it wouldn't result in su
I basically ended up doing what Jacob suggested.
To deal with the extra members from "mixin Signal" by using the compiles
trait to avoid the normal case for them.
Thanks for the help.
Paul
On 7/23/13, Johannes Pfau wrote:
> Does anyone know why this code is not working?
> http://dpaste.dzfl.pl/b89e7b3f
Add 'static' to getAttribute and it will work. I know, it's weird, and
I've seen this sort of workaround used before. I think it's a compiler
bug.
Jaehunt:
I mean when function has "T[]" in the front, how am I calling
it?
If it's a sorting routine, then it probably sorts data in-place,
so it's more clear to not return data. If the function copies
inside the input data before sorting it, then it's right to
return the result.
That's why
On Tuesday, 23 July 2013 at 22:39:20 UTC, Jaehunt wrote:
On Tuesday, 23 July 2013 at 22:27:40 UTC, bearophile wrote:
Jaehunt:
I am new to programming.
D is a large language, it will take lot of work and time to
learn it.
my function is look like "T[] sort(T)(T[] A) {}".
What is main()
On Tuesday, 23 July 2013 at 22:27:40 UTC, bearophile wrote:
Jaehunt:
I am new to programming.
D is a large language, it will take lot of work and time to
learn it.
my function is look like "T[] sort(T)(T[] A) {}".
What is main() look like to use the function?
Take a look at the Rosett
Jaehunt:
I am new to programming.
D is a large language, it will take lot of work and time to learn
it.
my function is look like "T[] sort(T)(T[] A) {}".
What is main() look like to use the function?
Take a look at the RosettaCode site, it contains hundreds of
small D programs of many
I am new to programming.
my function is look like "T[] sort(T)(T[] A) {}".
What is main() look like to use the function?
If you know sites about dealing with syntax, please leave the
links.
Thanks.
On Saturday, 20 July 2013 at 22:33:00 UTC, bearophile wrote:
Carl Sturtivant:
What is the conflict exactly?
Perhaps it's a bug fixed in GIT head. As workaround try:
this()(string s)
OK, but now I don't know how to call a templated constructor.
void main() {
A x = A!3(99);
}
added
Does anyone know why this code is not working?
http://dpaste.dzfl.pl/b89e7b3f
It seems calling "enum a = __traits(getAttributes, Class.member);" is OK
without an instance. But if I wrap the __traits call into another
template with alias parameter like this:
---
auto getAttribute(alias tar
On Tuesday, 23 July 2013 at 17:06:37 UTC, Dicebot wrote:
On Tuesday, 23 July 2013 at 17:03:52 UTC, John Colvin wrote:
Sorry, I should have been more clear. It's the first case that
seems weird to me.
Why? '*aptr' is 'a' pretty much by definition of pointer
dereferencing.
To be honest, I was
On Tuesday, 23 July 2013 at 19:14:26 UTC, H. S. Teoh wrote:
On Tue, Jul 23, 2013 at 08:54:12PM +0200, Jesse Phillips wrote:
On Tuesday, 23 July 2013 at 16:22:38 UTC, JS wrote:
>On Tuesday, 23 July 2013 at 16:15:03 UTC, Jesse Phillips
>wrote:
>>On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote
On Tue, Jul 23, 2013 at 08:54:12PM +0200, Jesse Phillips wrote:
> On Tuesday, 23 July 2013 at 16:22:38 UTC, JS wrote:
> >On Tuesday, 23 July 2013 at 16:15:03 UTC, Jesse Phillips wrote:
> >>On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote:
> >>>I don't think you understand(or I've already got conf
On Tuesday, 23 July 2013 at 16:22:38 UTC, JS wrote:
On Tuesday, 23 July 2013 at 16:15:03 UTC, Jesse Phillips wrote:
On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote:
I don't think you understand(or I've already got confused)...
I'm trying to use B has a mixin(I don't think I made this
clear
Am Mon, 22 Jul 2013 19:28:10 +0200
schrieb Marco Leise :
> Am Fri, 19 Jul 2013 21:43:38 +0200
> schrieb Johannes Pfau :
>
> > Am Fri, 19 Jul 2013 12:38:45 +0200
> > schrieb Marco Leise :
> >
> > Would be nice to know if this is working with gdc or ldc. In theory
> > it should work as we use gcc'
On 07/23/2013 10:00 AM, Namespace wrote:
Did I miss something or is this a bug?
import std.stdio;
struct Rect(T) {
public:
bool intersects(ref const Rect!T rhs, ShortRect* overlap = null) {
return false;
}
}
alias FloatRect = Rect!float;
alias ShortRect = Rect!short;
v
On Sunday, 21 July 2013 at 17:24:11 UTC, JS wrote:
This seems to be a somewhat efficient string splitter
http://dpaste.dzfl.pl/4307aa5f
I probably shouldn't have done this, but I wanted to know what
that abomination actually does, so I reduced it (code below). In
the end, all it does is acce
On 07/23/2013 09:22 AM, JS wrote:
> On Tuesday, 23 July 2013 at 16:15:03 UTC, Jesse Phillips wrote:
>> On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote:
>>> I don't think you understand(or I've already got confused)...
>>>
>>> I'm trying to use B has a mixin(I don't think I made this clear). I
On Tuesday, July 23, 2013 18:34:51 John Colvin wrote:
> void foo(ref int a)
> {
> a = 5;
> }
>
> void main()
> {
> int a = 0;
> int* aptr = &a;
>
> foo(*aptr);
> assert(a == 5);
>
> a = 0;
>
> int b = *aptr;
> foo(b);
> assert(b == 5);
> assert(a == 0);
> }
>
> The fact that adding an explicit
On Tuesday, 23 July 2013 at 16:40:53 UTC, Adam D. Ruppe wrote:
There's nothing weird there because int b is a new variable, so
assigning to it would not affect a in any case.
Sorry, I should have been more clear. It's the first case that
seems weird to me.
On Tuesday, 23 July 2013 at 17:03:52 UTC, John Colvin wrote:
Sorry, I should have been more clear. It's the first case that
seems weird to me.
Why? '*aptr' is 'a' pretty much by definition of pointer
dereferencing.
Did I miss something or is this a bug?
import std.stdio;
struct Rect(T) {
public:
bool intersects(ref const Rect!T rhs, ShortRect* overlap = null)
{
return false;
}
}
alias FloatRect = Rect!float;
alias ShortRect = Rect!short;
void main() {
}
print:
tpl_b
There's nothing weird there because int b is a new variable, so
assigning to it would not affect a in any case.
void foo(ref int a)
{
a = 5;
}
void main()
{
int a = 0;
int* aptr = &a;
foo(*aptr);
assert(a == 5);
a = 0;
int b = *aptr;
foo(b);
assert(b == 5);
assert(a == 0);
}
The fact that adding an e
On Tuesday, 23 July 2013 at 16:15:03 UTC, Jesse Phillips wrote:
On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote:
I don't think you understand(or I've already got confused)...
I'm trying to use B has a mixin(I don't think I made this
clear). I can't use it as a normal function. e.g., I can't
On Tuesday, 23 July 2013 at 14:03:01 UTC, JS wrote:
I don't think you understand(or I've already got confused)...
I'm trying to use B has a mixin(I don't think I made this
clear). I can't use it as a normal function. e.g., I can't seem
to do mixin(B(t)). If I could, this would definitely solve
On 07/23/2013 08:05 AM, Dicebot wrote:
> On Tuesday, 23 July 2013 at 03:14:17 UTC, Ali Çehreli wrote:
>> 1) There shouldn't be warnings at all; what we call warnings should be
>> errors.
>>
>> I agree with that completely.
>
> Not really. At least my (and, as far as I understand, Jonathan) point
On Tuesday, 23 July 2013 at 03:14:17 UTC, Ali Çehreli wrote:
1) There shouldn't be warnings at all; what we call warnings
should be errors.
I agree with that completely.
Not really. At least my (and, as far as I understand, Jonathan)
point of view is that warnings should be either error or s
On Tue, Jul 23, 2013 at 09:39:05AM +0200, David wrote:
> > There are some floats that can go even smaller than this, but they
> > are "denormal" and may incur a large runtime overhead (they are
> > intended to prevent underflow / minimize loss of precision in
> > certain computations involving very
On Monday, 22 July 2013 at 16:48:56 UTC, Jesse Phillips wrote:
On Sunday, 21 July 2013 at 07:22:08 UTC, JS wrote:
void foo(T...)(T t)
{
pragma(msg, B(t));
}
void main() {
foo("x", "a", "b");
din.getc();
}
does work. I need to have B generate compile time code so it
is efficient
On Tuesday, 23 July 2013 at 12:59:11 UTC, monarch_dodra wrote:
On Tuesday, 23 July 2013 at 12:26:31 UTC, JS wrote:
http://dpaste.dzfl.pl/27ca3fbd
The code compiles fine on my computer. On DPaste there is all
kinds of errors(when fixing one other errors pop up.
I am compiling to 32-bit binary
On Tuesday, 23 July 2013 at 12:26:31 UTC, JS wrote:
http://dpaste.dzfl.pl/27ca3fbd
The code compiles fine on my computer. On DPaste there is all
kinds of errors(when fixing one other errors pop up.
I am compiling to 32-bit binary and that is the only real
difference I can see, but surely it
http://dpaste.dzfl.pl/27ca3fbd
The code compiles fine on my computer. On DPaste there is all
kinds of errors(when fixing one other errors pop up.
I am compiling to 32-bit binary and that is the only real
difference I can see, but surely it wouldn't result in such
errors?
The first error:
On 2013-07-23 12:59, Artur Skawina wrote:
We can. :)
enum attrs = __traits... // `auto` would work too.
I can't remember that working for me, but perhaps it does.
Just be careful and remember the `typeof(attrs)` part if/when
using staticIndexOf with types - it might otherwise return bog
On 07/23/13 08:38, Jacob Carlborg wrote:
> static bool doesFieldSync (string field) ()
> {
> alias attrs = TypeTuple!(__traits(getAttributes, mixin("FileData." ~
> field)));
> return staticIndexOf!(Sync, attrs) != -1;
> }
>
> The important things here are that __traits(getAttributes) retu
> There are some floats that can go even smaller than this, but they are
> "denormal" and may incur a large runtime overhead (they are intended to
> prevent underflow / minimize loss of precision in certain computations
> involving very small quantities, and aren't supposed to be used in
> normal c
Ali Çehreli:
1) There shouldn't be warnings at all; what we call warnings
should be errors.
I agree with that completely.
Unfortunately the real world is not made of just black or white
situations. There are various valid reasons to have some
warnings. Sometimes the language change, and de
38 matches
Mail list logo