On Thursday, 10 January 2013 at 00:21:48 UTC, Charles Hixson
wrote:
Would the following code:
for (int i = 1; i < di.count; i++)
{ assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
be optimized away if compiled under -release?
If you write it as:
//
version(assert)
{
for (i
On Thursday, 10 January 2013 at 03:29:21 UTC, Peter Summerland
wrote:
I don't think Jonathan was (merely) dismissing readable
terseness and saving typing. IMO he had more pertinent reasons
why
foreach(i; 0 .. 5)
{}
is very nice, *as is*.
The only thing I'd want to be able to do is:
//
On Thursday, 10 January 2013 at 02:04:57 UTC, ixid wrote:
Regardless of this particular suggestion's value, I think
you're wrong to dismiss readable terseness and saving typing as
mattering, it's one of D's advantages over C++ that it makes a
lot of things far easier to do and understand beca
di is a struct containing *NO* functions. count, however, is a
@property, it just returns a counter variable, but that's not a local
property.
I *LIKE* the
version(assert)
{
...
}
choice. I'd been thinking about debug. I didn't know that version (or
possibly assert) could be used that way.
On 01/09/2013 04:14 PM, Charles Hixson wrote:
Would the following code:
for (int i = 1; i < di.count; i++)
{ assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
be optimized away if compiled under -release?
It looks like you can use std.algorithm.isSorted instead:
http://dlang.org/p
Le 10/01/2013 10:23, monarch_dodra a écrit :
On Thursday, 10 January 2013 at 03:29:21 UTC, Peter Summerland wrote:
The only thing I'd want to be able to do is:
//
foreach ( ; 0 .. 5)
{
writeln("hello");
}
//
If I don't need a named variable, why force me to define a symbol?
http://
Hi, im no expert in this, but my workflow used to be the
following:
Windows (vc) lib conversion to a dmd linkable one:
1. def file generation, from windows lib: coffimplib.exe -e
ecl.lib
2. edit def file for the missing symbols, for ex: _SDL_Init =
SDL_Init ==> _SDL_Init@4 = SDL_Init
3. update
10-Jan-2013 01:47, Era Scarecrow пишет:
On Wednesday, 9 January 2013 at 21:16:37 UTC, Era Scarecrow wrote:
Hmm as I'm thinking about it more, a mixin for BitString may be better..
Overall direction is good (I mean separation of ranges/containers). I'll
post more comments once I think it th
On 01/10/2013 08:41 AM, Ali Çehreli wrote:
On 01/09/2013 04:14 PM, Charles Hixson wrote:
Would the following code:
for (int i = 1; i < di.count; i++)
{ assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
be optimized away if compiled under -release?
It looks like you can use std.algor
On Thursday, 10 January 2013 at 20:24:02 UTC, Charles Hixson
wrote:
On 01/10/2013 08:41 AM, Ali Çehreli wrote:
On 01/09/2013 04:14 PM, Charles Hixson wrote:
Would the following code:
for (int i = 1; i < di.count; i++)
{ assert (node.di.entry[i - 1].key < node.di.entry[i].key); }
be optimized a
On Thursday, 10 January 2013 at 20:11:38 UTC, Dmitry Olshansky
wrote:
You want to mixin a definition of a inner struct BitString into
each bit array?
That was the idea, yes.
Or include all of functions of BitString to be mixed into
BitArray?
If the latter then:
Well it seems like it sho
11-Jan-2013 00:33, Era Scarecrow пишет:
On Thursday, 10 January 2013 at 20:11:38 UTC, Dmitry Olshansky wrote:
You want to mixin a definition of a inner struct BitString into each
bit array?
That was the idea, yes.
Or include all of functions of BitString to be mixed into BitArray?
If the
On Thursday, 10 January 2013 at 21:37:22 UTC, Dmitry Olshansky
wrote:
It's only for classes AFAIK. Inner structs of structs (LOL)
don't have it.
Why not? I don't see a reason why not personally. Umm maybe I
do... the outer struct becomes referenced to S2, so...
struct S {
int x;
stru
dnLftLnk is an array.
(It's still a confusing error message. I assume that "[7LU]" indicates
that it's an array, but if so, I don't know where it's documented.)
On 01/09/2013 06:36 PM, Charles Hixson wrote:
$ dmd -unittest bptree.d
Error: cannot implicitly convert expression (this.dnLftL
On Thursday, 10 January 2013 at 21:53:27 UTC, Charles Hixson
wrote:
(It's still a confusing error message. I assume that "[7LU]"
indicates that it's an array, but if so, I don't know where
it's documented.)
It's an array. Fixed arrays have a numeric value inside the
brackets, the LU is beca
Is it expected behaviour that this code compiles and prints:
this(this)
this(this)
?
[code]
import std.stdio;
static if (!is(typeof(writeln)))
alias writefln writeln;
struct vec2f {
public:
float x, y;
this(this) {
writeln("this(this)");
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
And what should I use, this(this) or opAssign? I thougth that
it is unimportant,
but that changed my mind: http://dpaste.dzfl.pl/36ce3688
The default generated opAssign will postblit the other struct
over itself, then destroy it's
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
Is it expected behaviour that this code compiles and prints:
I think it is. Postblit 'this(this)' occurs while initializing a
variable from one, rather than copying. Which you also can
compare against move symantics.
Correct m
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
And what should I use, this(this) or opAssign? I thougth that
it is unimportant,
but that changed my mind: http://dpaste.dzfl.pl/36ce3688
BTW, answered to the best of my abilities, taking into account
your link expired, so I don't
On Thursday, 10 January 2013 at 23:30:35 UTC, monarch_dodra wrote:
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
And what should I use, this(this) or opAssign? I thougth that
it is unimportant,
but that changed my mind: http://dpaste.dzfl.pl/36ce3688
BTW, answered to the best
Without a declared opAssign, this
S s3;
s3 = s1;
also calls the postblit. That is strange.
On Thursday, 10 January 2013 at 23:37:14 UTC, Namespace wrote:
Without a declared opAssign, this
S s3;
s3 = s1;
also calls the postblit. That is strange.
If there is no user declared opAssign, then opAssign is
implemented in terms of postblit. It's designed that way.
This is kind of li
On Thursday, 10 January 2013 at 23:37:14 UTC, Namespace wrote:
Without a declared opAssign, this
S s3;
s3 = s1;
also calls the postblit. That is strange.
Think of it like this: Blit means bit-by-bit copy, so a postblit
is a function that is invoked on the result of every bit-by-bit
copy
On Friday, 11 January 2013 at 00:02:48 UTC, monarch_dodra wrote:
On Thursday, 10 January 2013 at 23:35:19 UTC, Namespace wrote:
On Thursday, 10 January 2013 at 23:30:35 UTC, monarch_dodra
wrote:
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
And what should I use, this(this) or
On Thursday, 10 January 2013 at 23:35:19 UTC, Namespace wrote:
On Thursday, 10 January 2013 at 23:30:35 UTC, monarch_dodra
wrote:
On Thursday, 10 January 2013 at 23:03:30 UTC, Namespace wrote:
And what should I use, this(this) or opAssign? I thougth that
it is unimportant,
but that changed my
On 01/10/2013 02:15 PM, Era Scarecrow wrote:
On Thursday, 10 January 2013 at 21:53:27 UTC, Charles Hixson wrote:
(It's still a confusing error message. I assume that "[7LU]" indicates
that it's an array, but if so, I don't know where it's documented.)
It's an array. Fixed arrays have a numeric
On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
It's conform to the spec
http://dlang.org/function.html
Last line of the 'nested functions' subsection:
"Nested functions cannot be overloaded."
Nested functions cannot be overloaded.
Note that this is a case of the spec being adapted to the
im
Should these variants serve as identifiers?
auto x²; //fails to compile: char 0x00b2 not allowed in
identifier, unsupported char 0xb2 (why? is it not a digit?)
Same for ⅀, ∫ and etc.
Official documentations says:
«
D source text can be in one of the following formats:
ASCII
UTF-8
UTF-16BE
UTF
On Friday, 11 January 2013 at 02:09:33 UTC, Andrey wrote:
Should these variants serve as identifiers?
auto x²; //fails to compile: char 0x00b2 not allowed in
identifier, unsupported char 0xb2 (why? is it not a digit?)
Same for ⅀, ∫ and etc.
Official documentations says:
«
D source text can b
On Fri, Jan 11, 2013 at 03:09:29AM +0100, Andrey wrote:
> Should these variants serve as identifiers?
>
> auto x²; //fails to compile: char 0x00b2 not allowed in identifier,
> unsupported char 0xb2 (why? is it not a digit?)
Weird, identifiers like "Цвет" and "張" and even "ℝ" all work fine, but
"⅀
On Friday, 11 January 2013 at 01:49:03 UTC, Timon Gehr wrote:
On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
"Nested functions cannot be overloaded."
Note that this is a case of the spec being adapted to the
implementation. It has been added after I complained about the
DMD behaviour.
So
On 1/10/2013 5:49 PM, Timon Gehr wrote:
> On 01/08/2013 10:12 PM, Philippe Sigaud wrote:
>> It's conform to the spec
>>
>> http://dlang.org/function.html
>>
>> Last line of the 'nested functions' subsection:
>>
>> "Nested functions cannot be overloaded."
>> Nested functions cannot be overloaded.
>
save module as utf8(or any other enconding from list above)
file, from your error description it is ascii
I'm pretty sure I'm saving it in unicode. I can use all unicode
chars easily in string literals ("x²") and output them to
console. But using them in identifiers leads to compiler error.
33 matches
Mail list logo
