On 8/16/18 4:45 PM, Aaron D. Trout wrote:
On Thursday, 16 August 2018 at 18:56:45 UTC, Steven Schveighoffer wrote:
On 8/16/18 2:32 PM, Aaron D. Trout wrote:
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer wrote:
Yes, this is the effect I would expect.
D has traditiona
Thanks again for the quick reply! I have a pretty firm grasp on
what a slice is (array + offset).
Argh! Of course my brain would fail in that sentence! :-) I meant
(pointer + offest).
-Aaron
On Thursday, 16 August 2018 at 18:56:45 UTC, Steven Schveighoffer
wrote:
On 8/16/18 2:32 PM, Aaron D. Trout wrote:
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven
Schveighoffer wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data with
On 8/16/18 2:32 PM, Aaron D. Trout wrote:
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data without question
(even in @safe code), but that will change when dip1000 is fu
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer
wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data without
question (even in @safe code), but that will change when
dip1000 is fully realized. It will be allowed, but onl
On 8/16/18 12:51 PM, Aaron D. Trout wrote:
Hello all! I'm a mathematician at Chatham University in Pittsburgh, PA
(USA). I use D for research, and I'm a frequent lurker on the forums. I
think I found a bug, but I want to make sure I'm not just doing
something silly. (I'm happy to file a bugzill
Hello all! I'm a mathematician at Chatham University in
Pittsburgh, PA (USA). I use D for research, and I'm a frequent
lurker on the forums. I think I found a bug, but I want to make
sure I'm not just doing something silly. (I'm happy to file a
bugzilla issue if it turns out to be a legitimate
Hello,
I am currently trying to improve the TOML library of:
https://github.com/iccodegr/toml.d
I get a really weird error:
Error: function main.TOMLValue.opAssign is not callable because
it is annotated with @disable
I have tested this with dmd 2.071.1 and 2.068.0.
Here is the code to re
On Tuesday, 5 July 2016 at 13:48:50 UTC, ag0aep6g wrote:
Something is also going wrong in dmd. There should be a
deprecation message.
Exactly.
On 07/05/2016 12:47 PM, Jack Applegame wrote:
ttt.d
import std.string;
void main() {
lastIndexOf("aa","bb");
}
rdmd ttt.d
compiles successfully without any errors or warnings
rdmd -dw ttt.d
compiles successfully without any errors or warnings
rdmd -de ttt.d
/usr/include/dmd/phobos/std
ttt.d
import std.string;
void main() {
lastIndexOf("aa","bb");
}
rdmd ttt.d
compiles successfully without any errors or warnings
rdmd -dw ttt.d
compiles successfully without any errors or warnings
rdmd -de ttt.d
/usr/include/dmd/phobos/std/string.d(1239): Error: template
std.algorithm.
On Tuesday, 17 May 2016 at 18:59:31 UTC, Rishub Nagpal wrote:
https://dlang.org/phobos/std_experimental_logger_filelogger.html
import std.experimental.logger;
void main()
{
auto l1 = new FileLogger("logFile", "loggerName");
}
throws an error:
Error: none of the overloads of '__ctor' a
https://dlang.org/phobos/std_experimental_logger_filelogger.html
import std.experimental.logger;
void main()
{
auto l1 = new FileLogger("logFile", "loggerName");
}
throws an error:
Error: none of the overloads of '__ctor' are callable using
argument types (string, string), candidates
On Monday, 4 April 2016 at 21:31:08 UTC, Ali Çehreli wrote:
On 04/04/2016 09:36 AM, Anonymouse wrote:
On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:
[...]
assert(x.aa.length > 0); // <-- boom
[...]
No idea myself but that's where it seems to go wrong.
Looks like
On 04/04/2016 09:36 AM, Anonymouse wrote:
On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:
On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
auto clobber(ref Set x, ref Set o) {
Set ret;
ret.aa = x.aa;
assert(x.aa.length > 0); // <-- boom
return ret;
}
On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:
On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
auto clobber(ref Set x, ref Set o) {
Set ret;
ret.aa = x.aa;
assert(x.aa.length > 0); // <-- boom
return ret;
}
No idea myself but that's
On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
I have encountered a weird bug.
I defined a Set class, which has a opBinary!"-". And somehow
this:
auto tmp = set_a-set_b;
produces different results as this:
set_a = set_a-set_b;
the latter will produce an empty set.
I tried to
On Monday, 4 April 2016 at 03:55:26 UTC, Yuxuan Shui wrote:
On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
I have encountered a weird bug.
I defined a Set class, which has a opBinary!"-". And somehow
this:
auto tmp = set_a-set_b;
produces different results as this:
set_a = set
On Monday, 4 April 2016 at 03:28:01 UTC, Yuxuan Shui wrote:
I have encountered a weird bug.
I defined a Set class, which has a opBinary!"-". And somehow
this:
auto tmp = set_a-set_b;
produces different results as this:
set_a = set_a-set_b;
the latter will produce an empty set.
I tried to
I have encountered a weird bug.
I defined a Set class, which has a opBinary!"-". And somehow this:
auto tmp = set_a-set_b;
produces different results as this:
set_a = set_a-set_b;
the latter will produce an empty set.
I tried to reduce the source code to get a test case. But this
problem ju
On Friday, 26 December 2014 at 07:46:03 UTC, Jack wrote:
On Friday, 26 December 2014 at 07:23:34 UTC, Rikki Cattermole
wrote:
On 26/12/2014 6:58 p.m., Jack wrote:
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a
On Friday, 26 December 2014 at 07:23:34 UTC, Rikki Cattermole
wrote:
On 26/12/2014 6:58 p.m., Jack wrote:
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json,
and I
haven't really used th
On 26/12/2014 6:58 p.m., Jack wrote:
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json, and I
haven't really used the library as of the time of its building.
So, is this a bug?
Short ans
Complete error code here: http://codepad.org/KcW7jhXl
Apparently, there exists an incompatibility.
Take note, I just listed tkd as a dependency on my dub.json, and
I haven't really used the library as of the time of its building.
So, is this a bug?
On 12/30/2013 04:55 PM, Afshin wrote:
Thanks Ali.
I uninstalled 2.63.x.
Installed the 2.64.2.
I compiled and ran the test, and surely enough there were no problems.
However, when I build using Visual D environment, the problem persists.
Microsoft Visual Studio 2010 Ultimate.
Visual D plugin.
Thanks Ali.
I uninstalled 2.63.x.
Installed the 2.64.2.
I compiled and ran the test, and surely enough there were no
problems.
However, when I build using Visual D environment, the problem
persists.
Microsoft Visual Studio 2010 Ultimate.
Visual D plugin.
Thankfully, there is a simple work
On 12/29/2013 10:38 PM, Afshin wrote:
module test;
class Foo {
public static ulong next = 0;
public static ulong getNext() {
return next++;
}
}
void main() {
Foo.getNext();
}
/*
The next++ is the culprit.
Using a ++next does not throw an exception.
*/
Must have
module test;
class Foo {
public static ulong next = 0;
public static ulong getNext() {
return next++;
}
}
void main() {
Foo.getNext();
}
/*
The next++ is the culprit.
Using a ++next does not throw an exception.
*/
On Sunday, 15 December 2013 at 00:21:37 UTC, Ali Çehreli wrote:
On 12/14/2013 10:48 AM, Gary Willoughby wrote:
> On Friday, 13 December 2013 at 17:35:27 UTC, John Colvin
wrote:
>>> public void opAssign(uint value)
>>> {
>>> this._octets = value.nativeToBigEndian();
>>> a
On 12/14/2013 10:48 AM, Gary Willoughby wrote:
> On Friday, 13 December 2013 at 17:35:27 UTC, John Colvin wrote:
>>> public void opAssign(uint value)
>>> {
>>> this._octets = value.nativeToBigEndian();
>>> assert(this._octets == [1, 2, 3, 4]);
>>> }
>>> }
>> opAssign
On Friday, 13 December 2013 at 17:35:27 UTC, John Colvin wrote:
On Friday, 13 December 2013 at 16:37:51 UTC, Gary Willoughby
wrote:
I have the following code which is massively simplified from a
larger type. The problem occurs between assigning the value to
the type and retrieving it.
The val
On Friday, 13 December 2013 at 18:01:53 UTC, Rémy Mouëza wrote:
It works fine when using dup to the value returned by
nativeToBigEndian:
public void opAssign(uint value)
{
this._octets = value.nativeToBigEndian().dup;
assert(this._octets == cast (ubyte[]) [1, 2, 3, 4]);
It works fine when using dup to the value returned by nativeToBigEndian:
public void opAssign(uint value)
{
this._octets = value.nativeToBigEndian().dup;
assert(this._octets == cast (ubyte[]) [1, 2, 3, 4]);
}
On 12/13/2013 06:35 PM, John Colvin wrote:
On Friday, 13
On Friday, 13 December 2013 at 16:37:51 UTC, Gary Willoughby
wrote:
I have the following code which is massively simplified from a
larger type. The problem occurs between assigning the value to
the type and retrieving it.
The value is assigned through opAssign and the assert passes.
When usin
I have the following code which is massively simplified from a
larger type. The problem occurs between assigning the value to
the type and retrieving it.
The value is assigned through opAssign and the assert passes.
When using a property to retrieve the same data the assert fails!
import std
On Tuesday, 26 March 2013 at 05:40:00 UTC, Steven Schveighoffer
wrote:
What you have to do is instantiate the template, then call the
constructor:
S!(int, 4).S!(byte, 5)(3)
Note that the way templates work in D, a templated struct is
really a shortcut for:
template S(T)
{
struct S { ...
On Tue, 26 Mar 2013 01:28:03 -0400, Sergei Nosov
wrote:
Thank you, guys!
You made the matters clear to me!
It would be an interesting enhancement over C++.
Although, Steven, I didn't quite understand what you're suggesting to
use in case of "templated-struct-templated-constructor"
Expl
Thank you, guys!
You made the matters clear to me!
It would be an interesting enhancement over C++.
Although, Steven, I didn't quite understand what you're
suggesting to use in case of
"templated-struct-templated-constructor"
Explicitly specifying struct parameters is ok. Deducing
construc
On Mon, 25 Mar 2013 17:13:58 -0400, Ali Çehreli wrote:
On 03/25/2013 12:40 PM, Steven Schveighoffer wrote:
> On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli
wrote:
>
>> This design allows templated constructors:
>>
>> struct S // <-- not a template
>> {
>> this(T)(T t) // <-- templat
On 03/25/2013 12:40 PM, Steven Schveighoffer wrote:
> On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli
wrote:
>
>> This design allows templated constructors:
>>
>> struct S // <-- not a template
>> {
>> this(T)(T t) // <-- template
>> {
>> // ...
>> }
>>
>> // ...
>> }
>>
>> The same in C++...
>
On Mon, 25 Mar 2013 11:31:17 -0400, Ali Çehreli wrote:
This design allows templated constructors:
struct S // <-- not a template
{
this(T)(T t) // <-- template
{
// ...
}
// ...
}
The same in C++...
Templated constructors would not be disallowed if you
On Mon, 25 Mar 2013 11:11:40 -0400, Sergei Nosov
wrote:
On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is working as
c
On 03/25/2013 08:11 AM, Sergei Nosov wrote:
> On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
>> Sergei Nosov:
>>
>>> Everything's fine if I specify parameters explicitly:
>>>
>>> test!int hello = test!int(cptr);
>>>
>>
>> Some persons have proposed alternative designs, but D is work
On Monday, 25 March 2013 at 14:12:17 UTC, bearophile wrote:
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is
working as currently designed here... Unlike template
functions, templa
Sergei Nosov:
Everything's fine if I specify parameters explicitly:
test!int hello = test!int(cptr);
Some persons have proposed alternative designs, but D is working
as currently designed here... Unlike template functions,
templated structs don't infer the type.
Bye,
bearophile
Hi!
This code doesn't compile with dmd v2.062 on Linux_x86_64
struct test(T)
{
T *data_;
this(T *data) {
data_ = data;
}
}
void main()
{
int *cptr = null;
test!int hello = test(cptr);
}
Error:
dmd test.d
test.d(12): Error: struct test.test does not match any funct
46 matches
Mail list logo
