Am Tue, 10 Dec 2013 08:29:02 +0100
schrieb "Kenji Hara" :
> This is an intended behavior. An array literal has dynamic array
> type *by default*.
> But all of literals in D behave as polymorphic.
>
> char c = 'A'; // character literal has char type by default
> dchar d = 'A'; // but it may be
On Tuesday, December 10, 2013 08:29:02 Kenji Hara wrote:
> On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> >> On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> >> > On Tuesday, December 10, 2013 07:47:38 FreeS
On Tuesday, December 10, 2013 08:41:25 Joseph Rushton Wakeling wrote:
> On 10/12/13 06:33, Jonathan M Davis wrote:
> > It's still essentially a singleton - it's just that it's a single instance
> > per thread in that case instead of per program. And you avoid all of the
> > threading-related initia
On 10/12/13 06:33, Jonathan M Davis wrote:
It's still essentially a singleton - it's just that it's a single instance per
thread in that case instead of per program. And you avoid all of the
threading-related initialization issues with singletons if it's thread-local.
Just check whether it's null
Am Mon, 09 Dec 2013 23:15:27 -0800
schrieb Jonathan M Davis :
> On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> > On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> > > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> > >> I just found weird D behavior about inference of array t
On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
wrote:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
>> I just found weird D behavior about inference of array
>> t
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> >> I just found weird D behavior about inference of array types.
> >>
> >> Let's suppose we have these overloaded functions:
> >>
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln("static array")
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> I just found weird D behavior about inference of array types.
>
> Let's suppose we have these overloaded functions:
>
> import std.stdio;
>
> void bar(const(int[3]) arr)
> {
> writeln("static array");
> }
>
> void bar(const(int[]) a
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln("static array");
}
void bar(const(int[]) arr)
{
writeln("array slice");
}
// In main we have something like that:
int
On Tue, Dec 10, 2013 at 6:54 AM, Dfr wrote:
> Hello, here is example code, which doesn't work:
>
> Variant[] vtypes = [ Variant("hello"), Variant("bye") ];
> string[] filetypes = map!(to!string)(vtypes);
>
> Gives me error:
>
> Error: cannot implicitly convert expression (map(vtypes)) of t
Hello, here is example code, which doesn't work:
Variant[] vtypes = [ Variant("hello"), Variant("bye") ];
string[] filetypes = map!(to!string)(vtypes);
Gives me error:
Error: cannot implicitly convert expression (map(vtypes)) of type
MapResult!(to, VariantN!(24u)[]) to string[]
On Monday, December 09, 2013 06:19:19 Joseph Rushton Wakeling wrote:
> On Monday, 9 December 2013 at 00:24:44 UTC, Ali Çehreli wrote:
> > David Simcha presented it as a D-specific pattern and explained
> > how D avoids at least one of the bugs of double-checked locking:
> >
> >
> > http://www.you
On Tuesday, 10 December 2013 at 02:05:12 UTC, Jeremy DeHaan wrote:
On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote:
On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan
wrote:
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote:
*sigh* No dice. And I can't get GtkD t
On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote:
On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote:
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote:
*sigh* No dice. And I can't get GtkD to work either, because
of entry point errors...
I've gotten GtkD
My fault! and the reason is worth understanding in a slightly
wider context.
I'm importing into the new memory management related D source
files a D interface file obtained via htod and some tweaking from
the C header files associated with the C source I am modifying.
And that interface fil
On 09.12.2013 23:03, seany wrote:
yet another array question :
I have defined :
alias string[] surrealNum_segments;
alias string[string] surrealNum_segments_withID;
surrealNum_segments_withID BAR;
Is there a built in function FOO, such that i could also write:
FOO(surrealNum_segments) BAR;
i
yet another array question :
I have defined :
alias string[] surrealNum_segments;
alias string[string] surrealNum_segments_withID;
surrealNum_segments_withID BAR;
Is there a built in function FOO, such that i could also write:
FOO(surrealNum_segments) BAR;
instead of
surrealNum_segments_with
On Monday, 9 December 2013 at 19:53:09 UTC, Adam D. Ruppe wrote:
When you used the class, did you remember to new it?
Unlike C++, "Io io;" in D would be null. You have to create it
with "io = new Io();"
You got me thinking in the right direction, turns out I was
putting in a bad parameter at
When you used the class, did you remember to new it?
Unlike C++, "Io io;" in D would be null. You have to create it
with "io = new Io();"
So, I was doing some coding to my IO.d, and came across the
strangest error, I looked it up and tried some different asserts,
which is why it shows up as something different from "null this"
now, anyway here, I seriously can't figure this out, the code is
here: http://pastebin.com/bGiKMM4Y
co
Wow, i didn't know i could cast out constness from an lvalue.
This is what i needed. I'll try it in my code as soon as i can.
Thanks.
Yep, it compiles and works! By the way, i forgot to call b.foo()
in my example. Thanks for your help guys.
Given the following declarations in C:
typedef int foo_t[3];
void take_foo( foo_t );
How would you handle this in D?
It's obvious to me that the type should be declared the same way, so
that it may be used the same way in D as in C:
alias foo_t = int[3];
Given that on the C side, foo_t[3] p
I'm building a 32-bit windows executable using dmd 2.064.2, dmc
(857 according to the file in its root directory, but when run it
says 8.42n), and implicitly optlink. The executable is the a vm
for an interpreted language.
The source is mainly C that I didn't write, but I successfully
bolte
On Monday, 9 December 2013 at 16:10:34 UTC, qznc wrote:
That is probably not the root of Fras problem, though.
You are right, that was not the root, even if the mistake is
extremely simple: foreach(c, s) is used to seek the string.
I just realized that foreach can mess things up when used on
On Monday, 9 December 2013 at 16:11:39 UTC, Jakob Ovrum wrote:
Upon consulting the specification[1], it looks like it's
officially recommended to use `ref T[n]` for C's `T[n]`, and
`T*` for C's `T[]`, in parameter lists.
[1] http://dlang.org/interfaceToC.html, "Passing D Array
Arguments to C
On Monday, 9 December 2013 at 16:10:34 UTC, qznc wrote:
On Monday, 9 December 2013 at 15:58:53 UTC, qznc wrote:
I also smell a unicode bug, due to the combination of foreach
and length.
Bug reported. :)
https://d.puremagic.com/issues/show_bug.cgi?id=11712
That is probably not the root of Fra
On Monday, 9 December 2013 at 15:58:53 UTC, qznc wrote:
I also smell a unicode bug, due to the combination of foreach
and length.
Bug reported. :)
https://d.puremagic.com/issues/show_bug.cgi?id=11712
That is probably not the root of Fras problem, though.
Apparently the OP intended to set it in foo(). If the data is
actually mutable and there really is no way other than going
against the type system, foo() must be called at least once and
can be implemented like this:
public void foo()
{
abc = [1,2,3,4];
cast(ubyte*)data
On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote:
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote:
*sigh* No dice. And I can't get GtkD to work either, because
of entry point errors...
I've gotten GtkD to work for me, though it has been a while. If
I am able to fi
On Monday, 9 December 2013 at 16:11:39 UTC, Jakob Ovrum wrote:
On Monday, 9 December 2013 at 15:46:40 UTC, Mike Parker wrote:
Given that on the C side, foo_t[3] parameters will degrade to
pointers, it's just as obvious to me to declare the function
on the D side like so:
extern( C ) void take
On Monday, 9 December 2013 at 15:46:40 UTC, Mike Parker wrote:
Given that on the C side, foo_t[3] parameters will degrade to
pointers, it's just as obvious to me to declare the function on
the D side like so:
extern( C ) void take_foo( foo_t* );
That means that one need pass foo.ptr when call
Mike Parker:
I was expecting the length field to get in the way, but it
didn't seem to.
If you pass a fixed-sized array by ref it only passes the
pointer. The length is not passed, it's a compile-time known
value.
My question is, can I rely on this? Is there a guarantee that a
ref stati
On Monday, 9 December 2013 at 14:44:23 UTC, Fra wrote:
various (UTF) symbols seems to be ignored by inPattern, see
http://dpaste.dzfl.pl/e8ff9002 for a quick example (munch()
uses inPattern() internally)
Is it me doing something in an improper way, or is the
documentation lacking more specifi
various (UTF) symbols seems to be ignored by inPattern, see
http://dpaste.dzfl.pl/e8ff9002 for a quick example (munch() uses
inPattern() internally)
Is it me doing something in an improper way, or is the
documentation lacking more specific limitation of the function?
All I can read is "In the
On Monday, 9 December 2013 at 09:32:26 UTC, Dfr wrote:
What i trying to achieve in my current example is more succinct
code.
A coming from Perl and instead of writing:
if(some_complex_statement.here > 0) {
writefln("x is %s", some_long_expression.here);
}
I got used not to repeat complex s
On 09/12/13 12:43, Abdulhaq wrote:
I was tidying up my emails at work and by coincidence I found the original paper
that I was referring to, it's very pertinent to this discussion and interesting
too,
The pitfalls of verifying floating-point computations
David Monniaux (LIENS, Verimag - Imag)
h
On 07/12/13 11:52, John Colvin wrote:
I'm pretty sure D is free to do this, it goes with the whole
more-precision-is-better-precision philosophy.
I'm not complaining about better precision, I just want my equality comparisons
to be predictable -- arguably a losing cause :-)
I was tidying up my emails at work and by coincidence I found the
original paper that I was referring to, it's very pertinent to
this discussion and interesting too,
The pitfalls of verifying floating-point computations
David Monniaux (LIENS, Verimag - Imag)
http://arxiv.org/abs/cs/0701192
Jay Norwood:
I notice that if Suit and SuitShort have an enum with the same
name, then you still have to fully qualify the enum names when
using the with statement. So, for example, if spd in SuitShort
was renamed spades, the first entry in the array initialization
would have to be {Suit.spa
Sorry, it was misnomer in topic title. But simultaneous
assignment also useful topic to learn.
What i trying to achieve in my current example is more succinct
code.
A coming from Perl and instead of writing:
if(some_complex_statement.here > 0) {
writefln("x is %s", some_long_expression.
To give context, you're talking about a comparison of
(a ^^ 2.0) * 1.0 + 0.0 == a ^^ 2.0
(or, alternatively, the same but using isIdentical).
I'm curious to confirm why placing writefln statements before
the isIdentical check should change its behaviour (I assume
flushing the FPU cach
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote:
*sigh* No dice. And I can't get GtkD to work either, because
of entry point errors...
I've gotten GtkD to work for me, though it has been a while. If I
am able to find some time soon I will see if I can do some kind
of example for
On Monday, 9 December 2013 at 06:43:05 UTC, Joseph Rushton
Wakeling wrote:
On 09/12/13 01:24, Ali Çehreli wrote:
On 12/08/2013 02:40 PM, qznc wrote:
I understand you are talking about the "Singleton" design
pattern.
You might want to look how std.parallelism does it with the
default
global t
On Monday, 9 December 2013 at 07:38:04 UTC, Dfr wrote:
Does D has somtething similar ?
http://code.google.com/p/go-wiki/wiki/SimultaneousAssignment
No, not in general. There are a few special cases, though.
The foreach loop can assign value and index simultaneously.
foreach (int i, char c;
I mean a code fragment like this:
foreach(i; 1..2085)
{
// Bugbug: when we read in the buffer, we can't know anything
about its encoding...
// But REGEX could fail if it contained unknown chars!
Latin1String buf;
string s;
46 matches
Mail list logo
