On Tuesday, 29 December 2015 at 18:41:41 UTC, Adam D. Ruppe wrote:
On Tuesday, 29 December 2015 at 18:32:23 UTC, Atila Neves wrote:
The problem here is that I don't know what the workaround is.
The one I used (well, last time I tried this) was to just put a
dummy function in the D interface
cpp.cpp:
class Oops {
public:
virtual ~Oops() {}
virtual int number() const { return 42; }
};
Oops* newOops() {
return new Oops;
}
d.d:
import std.stdio;
extern(C++) {
interface Oops {
int number() const;
}
Oops newOops();
}
void main() {
auto oops =
On Tuesday, 29 December 2015 at 18:32:23 UTC, Atila Neves wrote:
The problem here is that I don't know what the workaround is.
The one I used (well, last time I tried this) was to just put a
dummy function in the D interface that is a placeholder for it.
interface C++Class {
// at the
On 26.12.2015 02:04, Bubbasaur wrote:
On Friday, 25 December 2015 at 23:45:42 UTC, anonymous wrote:
It's almost like the example in the URL you showed:
dmd test.d -LC:/gtkd/src/build/GtkD.lib
Note that in the docs I linked it's `dmd hello.d -L+gtkd.lib` with a
plus sign. I'm not sure if it's
On Saturday, 26 December 2015 at 11:19:27 UTC, anonymous wrote:
...
Note that in the docs I linked it's `dmd hello.d -L+gtkd.lib`
with a plus sign. I'm not sure if it's significant, but it's a
difference.
There are two ways in the doc you linked:
dmd hello.d -L+gtkd.lib
or
dmd hello.d
On Saturday, 26 December 2015 at 11:53:55 UTC, Ivan Kazmenko
wrote:
Note that -L passes flags (options) but not necessarily
arguments or paths. For example, I use "dmd
-L/STACK:268435456" by default along with other options to
increase the default stack size to 256Mb.
Your comment is
On Saturday, 26 December 2015 at 01:04:57 UTC, Bubbasaur wrote:
It's almost like the example in the URL you showed:
dmd test.d -LC:/gtkd/src/build/GtkD.lib
Note that -L passes flags (options) but not necessarily arguments
or paths. For example, I use "dmd -L/STACK:268435456" by default
ot;-I" flag you don't need
any space.
It took me 30 minutes until I find why my program wasn't
compiling. (I found the tip on a forum elsewhere).
Is this a bug or a mistake?
Bubba.
On Friday, 25 December 2015 at 15:06:27 UTC, anonymous wrote:
...
You can try removing the "-L" entirely. If it still works...
In fact it works without the "-L". Which makes me wonder if I was
using it wrongly?
What exactly are trying to pass to the linker?
A lib: GtkD.
Can you give a
On 25.12.2015 15:40, Bubbasaur wrote:
But at least on Windows, you need to put a space between -L and the
PATH. Which It's weird, since with "-I" flag you don't need any space.
I don't think that's right. Unless something awful is going in Windows
dmd, that should be processed as two separate
On 25.12.2015 19:32, Bubbasaur wrote:
On Friday, 25 December 2015 at 15:06:27 UTC, anonymous wrote:
In fact it works without the "-L". Which makes me wonder if I was using
it wrongly?
I'm convinced that putting a space between "-L" and its argument is
nonsense. The "-L" part just means "pass
On Friday, 25 December 2015 at 23:45:42 UTC, anonymous wrote:
...
That means a .lib file, right?
Yes.
The GtkD docs say to use -L though [2], so I suppose that
should work too.
Maybe show your exact complete command line, if you want to
find out why it doesn't work for you.
It's almost
heh. it crashed due to "in" presence. if you'll remove "in", it
will work.
On Tuesday, 8 December 2015 at 11:45:25 UTC, Random D user wrote:
Ok. This is minimal app that crashes for me. If someone could
try this:
At the very least, there is no crash when changing `struct Foo`
to `static struct Foo`, so it is perhaps related to `Foo` being
an inner struct with a
On Tuesday, 8 December 2015 at 11:45:25 UTC, Random D user wrote:
Ok. This is minimal app that crashes for me. If someone could
try this:
OK, this at least reproducibly crashes here, too (-m32 and -m64
on Windows, tried dmd 2.069.0 and 2.067.1).
{
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
}
}
int main( char[][] args )
{
App a = new App;
a.crash( 1
On Tuesday, 8 December 2015 at 11:45:25 UTC, Random D user wrote:
Ok. This is minimal app that crashes for me. If someone could
try this:
Interesting.
With dmd 2.064.2, your example compiles and runs fine.
With dmd 2.065.0, it does not compile, complaining that there is
no opCmp for `Foo`s.
it might be my bug or that the
runtime somehow corrupts it's state. Scary.
So I have an App class that gets created in main.
Basically
App = new App
App.start();
If I put that code as the first thing in the constructor
everything works.
If I put that code as the first thing in the first method
on Windows. Works for
me, too.
I tried this again. And it seems it might be my bug or that the
runtime somehow corrupts it's state. Scary.
So I have an App class that gets created in main.
Basically
App = new App
App.start();
If I put that code as the first thing in the constructor
On Tuesday, 8 December 2015 at 00:40:29 UTC, tsbockman wrote:
Someone still needs to review the PR, though.
Thanks! Looks like it's been merged already.
It was a double problem... I failed to read the bit about
advancing the ref and then the old big @@@BUG@@@ comment in the
unit test made
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( ); // Crash!
win64 & dmd 2.69.2
So whilst attempt to convert from a hex string (without the 0x)
to int I bumped into the @@@BUG@@@ the size of China
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270
Is there a bugzilla issue number tracking this?
Searching for conv and parse in the issue
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user wrote:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto
On 07.12.2015 21:56, John Carter wrote:
So whilst attempt to convert from a hex string (without the 0x) to int I
bumped into the @@@BUG@@@ the size of China
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270
Is there a bugzilla issue number tracking
On 12/7/15 5:32 PM, anonymous wrote:
On 07.12.2015 21:56, John Carter wrote:
So whilst attempt to convert from a hex string (without the 0x) to int I
bumped into the @@@BUG@@@ the size of China
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270
worksforme. git HEAD, GNU/Linux, x86.
On Monday, 7 December 2015 at 20:56:24 UTC, John Carter wrote:
So whilst attempt to convert from a hex string (without the 0x)
to int I bumped into the @@@BUG@@@ the size of China
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270
Is there a bugzilla issue
On Monday, 7 December 2015 at 22:38:03 UTC, Steven Schveighoffer
wrote:
It's an old bug, if it still exists. But in any case, the
description is terrible. A real bug report should be filed.
-Steve
Filed (https://issues.dlang.org/show_bug.cgi?id=15419) and fixed
(https://github.com/D
On Monday, 7 December 2015 at 22:03:42 UTC, Alex Parrill wrote:
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user wrote:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe
On Wednesday, 25 November 2015 at 09:31:15 UTC, John Colvin wrote:
import std.range;
import std.algorithm;
import std.utf;
void main() {
char[64] arr;
copy(chain("test1", "test2").byCodeUnit,
arr[0..10].byCodeUnit);
}
I'll use byCodeUnit. Thanks.
On Wednesday, 25 November 2015 at 08:10:03 UTC, Jack Applegame
wrote:
This doesn't compile:
import std.range;
import std.algorithm;
void main() {
char[64] arr;
copy(chain("test1", "test2"), arr[0..10]);
}
http://dpaste.dzfl.pl/24230ac02e6e
Essentially this comes down to the
This doesn't compile:
import std.range;
import std.algorithm;
void main() {
char[64] arr;
copy(chain("test1", "test2"), arr[0..10]);
}
http://dpaste.dzfl.pl/24230ac02e6e
On Saturday, 14 November 2015 at 05:44:44 UTC, Anonymous wrote:
I was playing with some code someone posted on the forum that
involved opDispatch and compile time parameters. I pasted it in
a file named templOpDispatch.d, ran it, and got an error. Then
I noticed if I renamed the file it
On Saturday, 14 November 2015 at 05:44:44 UTC, Anonymous wrote:
Then running 'rdmd templOpDispatch.d' produces:
std.process.ProcessException@std\process.d(568): Failed to
spawn new process (The requested operation requires elevation.)
This is a Windows quirk. When they introduced UAC in
I was playing with some code someone posted on the forum that
involved opDispatch and compile time parameters. I pasted it in a
file named templOpDispatch.d, ran it, and got an error. Then I
noticed if I renamed the file it worked.
The source didn't matter; same thing happens with an empty
On Friday, 6 November 2015 at 20:00:43 UTC, BBaz wrote:
Sorry, the forum as stripped my answer. Here is the full
version:
...
Thank you very much for taking the time to explain it!
Template parameter deduction in partially specialized template
fails:
---
enum Bar{b,a,r}
void foo(Bar bar, T)(T t){}
alias foob(T) = foo!(Bar.b, T);
void main()
{
foo!(Bar.b)(8);
foob(8); // autsch
}
---
It looks like a bug, doesn't it ?
like a bug, doesn't it ?
I believe this is https://issues.dlang.org/show_bug.cgi?id=1807
Consider this:
[code]
import std.stdio, std.utf, std.exception;
void do_decode(string txt)
{
try
{
size_t idx;
writeln("decode ", txt);
for (size_t i = 0; i < txt.length; i++)
{
dchar dc = std.utf.decode(txt[i..i+1], idx);
On Friday, 6 November 2015 at 19:26:50 UTC, HeiHon wrote:
Am I using std.utf.decode wrongly or is it buggy?
It's obviously used wrongly, try this instead:
import std.utf, std.stdio;
---
dstring do_decode(string txt)
{
dstring result;
try
{
size_t idx;
Sorry, I mixed up the line numbers from dmd 2.068.2 and dmd
2.069.0.
The correct line numbers for dmd 2.069.0 are:
Attempted to decode past the end of a string (at index 1)
file=D:\dmd2\windows\bin\..\..\src\phobos\std\utf.d line=1281
and
core.exception.RangeError@std\utf.d(1278): Range
On Friday, 6 November 2015 at 19:26:50 UTC, HeiHon wrote:
Consider this:
[code]
import std.stdio, std.utf, std.exception;
void do_decode(string txt)
{
try
{
size_t idx;
writeln("decode ", txt);
for (size_t i = 0; i < txt.length; i++)
{
dchar
Sorry, the forum as stripped my answer. Here is the full version:
On Friday, 6 November 2015 at 19:26:50 UTC, HeiHon wrote:
Am I using std.utf.decode wrongly or is it buggy?
It's obviously used wrongly, try this instead:
import std.utf, std.stdio;
---
dstring do_decode(string txt)
{
On Thursday, 8 October 2015 at 09:01:32 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 7 October 2015 at 16:25:02 UTC, Marc Schütz wrote:
Lionello Lunesu posted a PR that should fix this:
https://github.com/D-Programming-Language/dmd/pull/1913
See also the discussion in the linked bug
On Wednesday, 7 October 2015 at 16:25:02 UTC, Marc Schütz wrote:
Lionello Lunesu posted a PR that should fix this:
https://github.com/D-Programming-Language/dmd/pull/1913
See also the discussion in the linked bug report.
Unfortunately it seems it's been forgotten since then...
Meanwhile I
On 10/7/15 1:27 AM, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
On Thursday, 8 October 2015 at 13:32:17 UTC, Steven Schveighoffer
wrote:
On 10/7/15 1:27 AM, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your
code
On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your
code ends up
being portable ;) (It's trivial to do,
On Wednesday, 7 October 2015 at 07:38:44 UTC, Andrea Fontana
wrote:
On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc
wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos
>= 10)) );
}
[/code]
[output]
0 true false true
[/output]
How is it generating "true" for (dec <= -10) ? Is there a
special casting or something?
DMD 2.068.2, Ubuntu 64-bit
Lionello Lunesu posted a PR that should fix this:
https://github.com/D-Programming-Language/dmd/pul
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code
ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
-Steve
It seems unnatural to use such a
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec <=
-10) || (dec >= 10)) );
}
[/code]
[output]
0 true false true
[/output]
How is it generating "true" for (dec
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec
<= -10) || (dec >= 10)) );
}
[/code]
[output]
0 true
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
void main(){
size_t dec = 0;
How is it generating "true" for (dec <= -10) ? Is there a
special casting or something?
size_t is unsigned, so the -10 is cast to unsigned too for the
comparison which yields some huge number.
due to the bug there) when
I tried to print out the passed value and ended up with the
segfault. So I guess it doesn't bite devs often as it is mostly
used as you wrote.
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
-Steve
On Tuesday, 6 October 2015 at 14:55:23 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
void main(){
size_t dec = 0;
How is it generating "true" for (dec <= -10) ? Is there a
special casting or something?
size_t is unsigned, so the -10 is cast to
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec
<= -10) || (dec >= 10)) );
}
[/code]
[output]
0 true
This code:
import std.stdio;
import std.datetime;
void main()
{
SysTime t = SysTime.init;
writeln(t);
}
results in segfault with dmd-2.068.2
Is it ok?
Backtrace:
#0 0x004733f3 in std.datetime.SysTime.adjTime() const ()
#1 0x004730b9 in
On Monday, October 05, 2015 18:12:06 tchaloupka via Digitalmars-d-learn wrote:
> This code:
>
> import std.stdio;
> import std.datetime;
>
> void main()
> {
> SysTime t = SysTime.init;
> writeln(t);
> }
>
> results in segfault with dmd-2.068.2
>
> Is it ok?
It is by design, albeit
This compiles with enabled warnings:
---
int f()
{
while(true){}
assert(false);
}
---
thank you :) works now
http://pastebin.com/fknwgjtz
i tried to call fibers in a loop forever, to multiplex some
networking client worker fibers and a listener fiber
it seems to work correctly with for(int i=0;i<1;)
with while(true) i get:
C:\dev\server_client>dub
Building server_client ~master configuration
using DMD32 D Compiler v2.068.0 on windows x64
On Thursday, 17 September 2015 at 19:43:02 UTC, H. S. Teoh wrote:
On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via
Digitalmars-d-learn wrote:
http://pastebin.com/fknwgjtz
i tried to call fibers in a loop forever, to multiplex some
networking
client worker fibers and a listener fiber
it
On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via Digitalmars-d-learn wrote:
> http://pastebin.com/fknwgjtz
>
> i tried to call fibers in a loop forever, to multiplex some networking
> client worker fibers and a listener fiber
> it seems to work correctly with for(int i=0;i<1;)
>
> with
On Thursday, 17 September 2015 at 19:32:16 UTC, ddos wrote:
source\app.d(72): Warning: statement is not reachable
What's there? Anything after an endless loop is potentially
unreachable and dub treats warnings as errors.
With the for loop, the compiler can't be as sure that it is
endless
On Thursday, 17 September 2015 at 19:35:05 UTC, Adam D. Ruppe
wrote:
What's there? Anything after an endless loop is potentially
unreachable and dub treats warnings as errors.
i see, thx
On 09/17/2015 09:47 PM, ddos wrote:
yeah i tried for(;;) and it generates the same warning :)
sure, here is the full example, it's not too long anyways
( the example doesn't make much sense tho because socket.accept is
blocking :P )
http://pastebin.com/9K0wRRD6
ps: pastebin needs D support :-D
On Thursday, 17 September 2015 at 19:47:15 UTC, ddos wrote:
yeah i tried for(;;) and it generates the same warning :)
sure, here is the full example, it's not too long anyways
( the example doesn't make much sense tho because socket.accept
is blocking :P )
http://pastebin.com/9K0wRRD6
Yeah,
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
wrote:
Yeah... I guess I was expecting it to overload across class
boundaries. I mean there's already a member eat in base class
and sub class can't override that since it's got different
parameters, and it's a function (can't be
On Wednesday, 16 September 2015 at 13:18:51 UTC, Meta wrote:
It's the exact same as in Java, and probably C# as well. I
don't know if there's any OOP language that overloads methods
between the base and super class.
https://ideone.com/En5JEc
https://ideone.com/aIIrKM No, there's nothing
On Wednesday, 16 September 2015 at 14:08:11 UTC, Kagamin wrote:
On Wednesday, 16 September 2015 at 13:18:51 UTC, Meta wrote:
It's the exact same as in Java, and probably C# as well. I
don't know if there's any OOP language that overloads methods
between the base and super class.
eat does not override any
function, did you mean to override 'main.Father.eat'?
}
Daughter d = new Daughter();
// BUG? I expected this to work. It seems that compiler doesn't
even look into parent class to see if there's a matching function.
//int num = d.eat();// Error: funct
apples ) {} // Workaround D,
fails -> Error: function main.Daughter.eat does not override
any function, did you mean to override 'main.Father.eat'?
}
Daughter d = new Daughter();
// BUG? I expected this to work. It seems that compiler doesn't
even look into parent class to see if ther
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
Given that, normally properties are just overloaded methods in
D, it's pretty sad classes break this behavior/convention.
The D behavior for overloading is different in general:
http://dlang.org/hijack.html
It basically never
On Wednesday, 16 September 2015 at 03:17:05 UTC, Meta wrote:
Considering Father defines the function `int eat()` and
Daughter defines the completely different function `int
eat(int)`, it doesn't surprise me. You're not using virtual
dispatch when you do `return super.eat` or `d.Father.eat()`,
On Wednesday, 16 September 2015 at 03:54:34 UTC, Adam D. Ruppe
wrote:
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
Given that, normally properties are just overloaded methods in
D, it's pretty sad classes break this behavior/convention.
The D behavior for overloading is
On Saturday 12 September 2015 20:28, Random D user wrote:
> prints (with option B):
> bar: 0.00, 0.00 // BUG??
> baz: 1.00, 2.00
Looks like a bug to me. Please file an issue at https://issues.dlang.org/
On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user
wrote:
or is it some obscure feature conflict?
[...]
Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior
was present earlier than that...
(with option B):
bar: 0.000000, 0.00 // BUG??
baz: 1.00, 2.00
prints (with option A):
bar: 1.00, 2.00
baz: 1.00, 2.00
-
Luckily the option A works as I expected and is good enough for
me...
The following fails to compile with an 'cannot deduce function
from argument types' error. When using an array of something
other than TypeInfo_Class everything works as expected.
void main()
{
import std.algorithm.mutation : remove;
TypeInfo_Class[] arr;
; {
> import std.algorithm.mutation : remove;
>
> TypeInfo_Class[] arr;
> TypeInfo_Class c;
> arr = arr.remove!(a => a is c);
> }
Yes, it's a bug. It should work.
The problem is that TypeInfo_Class has a method called "init" which shadows
the built
as expected.
void main()
{
import std.algorithm.mutation : remove;
TypeInfo_Class[] arr;
TypeInfo_Class c;
arr = arr.remove!(a => a is c);
}
Yes, it's a bug. It should work.
The problem is that TypeInfo_Class has a method called "init"
which shad
On Wednesday, 26 August 2015 at 17:30:29 UTC, Alex Parrill wrote:
it shouldn't segfault though.
The segfault is because of:
https://issues.dlang.org/show_bug.cgi?id=14993
It "should've" been an InvalidMemoryOperationError, which in turn
was caused by:
, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Note that mmap-ing a zero-length range is invalid on Linux. Dunno
about OSX; it shouldn't segfault though.
,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN?
Note that mmap-ing a zero-length range is invalid on Linux
std.mmFile;
int main() {
auto x = new MmFile(testdic,MmFile.Mode.readWrite,0,null);
return 0;
}
---
OSX 10.10.3 ,
DMD64 D Compiler v2.069-devel-d0327d9
After testdic file (size=0) was made, Segmentation Fault: 11 .
I don't know whether this code is typical use.
Is this Phobos BUG? or BY DESIGN
): Error: no property 'len2' for type 'Vector!float',
did you mean 'len'?
In dmd 2.067 is normaly.
is it Bug or enhancements?
On 08/06/2015 11:26 PM, VlasovRoman wrote:
I have some code:
Filed:
https://issues.dlang.org/show_bug.cgi?id=14883
Ali
On 08/06/2015 11:26 PM, VlasovRoman wrote:
I have some code:
Reduced:
import std.stdio;
auto foo(T)(T)
{
return 42;
}
struct Vector(T)
{
pragma(msg, is(typeof(foo(Vector.init;// prints true
static if(is(typeof(foo(Vector.init {
static assert(false);
);
}
I get error by compiler when i build this:
main.d(30): Error: no property 'len2' for type 'Vector!float',
did you mean 'len'?
In dmd 2.067 is normaly.
is it Bug or enhancements?
Does not work in 2.067 for me.
Btw. you do not need to do this:
alias selftype = Vector!T;
You can just use
fix - https://github.com/D-Programming-Language/phobos/pull/3524
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static
Typo:
*scenario
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
My project has just stopped for this reason, I
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
large static array could allow indexing it through a null pointer
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote:
Sorry, I can't see _the_ point in that.
Yeah, especially since you can jsut break up the array and get
the same effect anyway...
so like if you don't want to dynamically allocate the memory, you
could also try:
byte[1024*1024*8]
901 - 1000 of 1912 matches
Mail list logo
