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;
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
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
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
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
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,
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
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
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 :-)
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)
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
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
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
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
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];
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
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
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
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.
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
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]
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.
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
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();
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
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
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;
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
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
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
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:
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[]
And
On Tue, Dec 10, 2013 at 6:54 AM, Dfr defle...@yandex.ru 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
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 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[]) arr)
{
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 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:
import
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
Am Mon, 09 Dec 2013 23:15:27 -0800
schrieb Jonathan M Davis jmdavisp...@gmx.com:
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
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
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
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 FreeSlave wrote:
Am Tue, 10 Dec 2013 08:29:02 +0100
schrieb Kenji Hara k.hara...@gmail.com:
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'; //
45 matches
Mail list logo
