On Wednesday, 30 August 2017 at 22:08:03 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via
Digitalmars-d- learn wrote:
[...]
Templates have no idea what arguments you intend to use with
them. You can pass them any arguments you want, and as long as
they
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
In the new version pending release (scheduled for later this
week), we get a new feature `static foreach` that will let you
loop through the types you want and declare all the functions
that way.
On Wednesday, 30 August 2017 at 22:08:03 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via
Digitalmars-d- learn wrote:
The point you are trying to making, and not doing a great job,
is that the compiler cannot create an unknown set of virtual
functions
On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via Digitalmars-d-
learn wrote:
> The point you are trying to making, and not doing a great job, is
> that the compiler cannot create an unknown set of virtual
> functions from a single templated virtual function. BUT, when you
> realize that
On Wednesday, 30 August 2017 at 21:33:30 UTC, Jonathan M Davis
wrote:
On Wednesday, August 30, 2017 20:47:12 EntangledQuanta via
Digitalmars-d- learn wrote:
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
On Wednesday, 30 August 2017 at 21:13:19 UTC, Kagamin wrote:
It can't work this way. You can try std.variant.
Sure it can! What are you talking about! std.variant has nothing
to do with it! It works if T is hard coded, so it should work
generically. What's the point of templates variables if
On Wednesday, August 30, 2017 20:47:12 EntangledQuanta via Digitalmars-d-
learn wrote:
> This is quite surprising!
>
> public struct S(T)
> {
> T s;
> }
>
>
> interface I
> {
> void Go(T)(S!T s);
>
> static final I New()
> {
> return new C();
> }
> }
>
> abstract class A : I
> {
>
It can't work this way. You can try std.variant.
This is quite surprising!
public struct S(T)
{
T s;
}
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
}
class C : A
{
void Go(T)(S!T s)
{
On 8/28/17 9:34 PM, Johnson Jones wrote:
produces 4 on both x86 and x64. So, I'm not sure how you are getting 8.
Yes, this is exactly why you should use c_long and c_ulong, because just
using int makes it not portable to other systems.
-Steve
On Tuesday, 29 August 2017 at 02:47:34 UTC, Johnson Jones wrote:
[...]
Seems only long and ulong are issues.
With respect to the currently major platforms you can reasonable
expect software to run on, yes.
Just don't try to use D on something with e.g. 32 bit C shorts
unless you bind to it
On Tuesday, 29 August 2017 at 01:56:43 UTC, Moritz Maxeiner wrote:
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
import core.stdc.config;
pragma(msg, c_long.sizeof);
prints 4UL
both on x64 and x86
and and C:
void foo()
{
int dummy;
switch (dummy) {
case sizeof(long) :
case sizeof(long) :
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses LLP64, which uses 32bit longs. Am I correct in
assuming you're on
("%lu\n", sizeof(long)); // also prints 8 on my box
return 0;
}
They should match. If they don't, that's a D bug (in either
core.stdc.config or the compiler, I'm not sure which). If they
do, then one of the other two possibilities is happening, and I
would lean towards the bind
core.stdc.config;
pragma(msg, c_long.sizeof); // prints 8 on my box.
And in c:
#include
int main()
{
printf("%lu\n", sizeof(long)); // also prints 8 on my box
return 0;
}
They should match. If they don't, that's a D bug (in either
core.stdc.config or the compiler, I'm not
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx,
On Monday, 28 August 2017 at 22:41:56 UTC, Moritz Maxeiner wrote:
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven
Schveighoffer wrote:
[...]
and where are these c_ types defined? The reason I replaced
them was precisely
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be correctly defined
for the width, and also it will mangle correctly
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)]
0041eaa9 mov eax, [fs:0x2c]
0041eaaf mov edx,
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)]
0041eaa9 mov eax, [fs:0x2c]
0041eaaf mov edx, [eax+ecx*4]
0041eab2 push dword [edx+0x1c]
lang.org/thread/lkbswgpsgxynhfyzw...@forum.dlang.org
This is either a bug in D, an issue with calling conventions, or
how one passes the data.
The original portaudio open stream function, so you can see that
it simply prints it's arguments:
PaError Pa_OpenStream( Pa
and some doc:
http://dlang.org/spec/function.html#function-inheritance
On Wed, Aug 16, 2017 at 7:45 AM, Daniel Kozak <kozz...@gmail.com> wrote:
> No it is not a bug, there is no s() in B, you can fix this by adding:
>
> alias s = A.s;
>
> to class B
>
> On Wed, Aug 16,
No it is not a bug, there is no s() in B, you can fix this by adding:
alias s = A.s;
to class B
On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> abstract class A
> {
> string _s;
>
> @property:
>
abstract class A
{
string _s;
@property:
final string s()
{
return _s;
}
A s(string x)
{
_s = x;
return this;
}
}
class B : A
{
@property:
final override A s(string
On Fri, Aug 11, 2017 at 11:34:04PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
> > int and I should be able to append an int without having to worry
> > about the value of the int.
>
> Appending an int to a string really ought
On Friday, 11 August 2017 at 23:34:04 UTC, Adam D. Ruppe wrote:
On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
int and I should be able to append an int without having to
worry about the value of the int.
Appending an int to a string really ought to just be a type
mismatch error.
On Friday, 11 August 2017 at 22:43:02 UTC, Mr. Pib wrote:
int and I should be able to append an int without having to
worry about the value of the int.
Appending an int to a string really ought to just be a type
mismatch error.
We might be able to convince the leadership to do that too,
On Friday, 11 August 2017 at 22:50:53 UTC, ketmar wrote:
Mr. Pib wrote:
Wow, that is pretty screwed up! I thought D was against
implicit conversions that might cause problems? I'm passing
an int and I should be able to append an int without having to
worry about the value of the int.
Mr. Pib wrote:
Wow, that is pretty screwed up! I thought D was against implicit
conversions that might cause problems? I'm passing an int and I should
be able to append an int without having to worry about the value of the
int. Instead D chose to do something very strange, awkward, and error
e time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D d)
and one might think it is remnants left over from I cleaned
the project so it shouldn't be happening. Seems like a bug.
(I realized that I'd probably only ever pass compile time
values)
Of course, using D.stri
ring Q(alias T, D)(D d)
and one might think it is remnants left over from I cleaned the project
so it shouldn't be happening. Seems like a bug.
(I realized that I'd probably only ever pass compile time values)
Of course, using D.stringof gives the value.
The problem is the case of D.
T, D)(D d)
and one might think it is remnants left over from I cleaned the
project so it shouldn't be happening. Seems like a bug.
(I realized that I'd probably only ever pass compile time values)
Of course, using D.stringof gives the value.
The problem is the case of D.
On 8/9/17 4:10 PM, Temtaime wrote:
Sorry, messed up numbers
Expected:
3.11
3.11
3.1
3.1
Seems g outputs one digit less
I was bugged by this too.
It's not a bug. For the %f specifier, the number represents the number
of digits *after* the decimal.
For the %g specifier, the number
Sorry, messed up numbers
Expected:
3.11
3.11
3.1
3.1
Seems g outputs one digit less
import std.stdio;
void main()
{
writefln(`%.2g`, 3.11);
writefln(`%.2f`, 3.11);
writefln(`%.1g`, 3.11);
writefln(`%.1f`, 3.11);
}
3.1
3.11
3
3.1
But expected
3.1
3.11
3.1
3.11
On 03-08-17 23:11, Johnson Jones wrote:
On Thursday, 3 August 2017 at 21:00:17 UTC, Mike Wey wrote:
On 03-08-17 22:40, Johnson Jones wrote:
Ok, so, I linked the gtk to the msys gtk that I installed before when
trying to get glade to work and it worked!
seems that msys is much more up to date
On Thursday, 3 August 2017 at 21:00:17 UTC, Mike Wey wrote:
On 03-08-17 22:40, Johnson Jones wrote:
Ok, so, I linked the gtk to the msys gtk that I installed
before when trying to get glade to work and it worked!
seems that msys is much more up to date than anything else as
it just works(I
On 03-08-17 22:40, Johnson Jones wrote:
Ok, so, I linked the gtk to the msys gtk that I installed before when
trying to get glade to work and it worked!
seems that msys is much more up to date than anything else as it just
works(I need to remember than in the future).
The problem I see is
On Thursday, 3 August 2017 at 15:11:46 UTC, Mike Wey wrote:
On 03-08-17 05:00, Johnson Jones wrote:
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe
that will fix everything.
On Thursday, 3 August 2017 at 15:11:46 UTC, Mike Wey wrote:
On 03-08-17 05:00, Johnson Jones wrote:
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe
that will fix everything.
On Thursday, 3 August 2017 at 15:11:46 UTC, Mike Wey wrote:
On 03-08-17 05:00, Johnson Jones wrote:
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe
that will fix everything.
On 03-08-17 05:00, Johnson Jones wrote:
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe that will
fix everything.
Great, unfortunately "Use msys2" seems to be the official way to
On Thursday, 3 August 2017 at 03:00:02 UTC, Johnson Jones wrote:
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe
that will fix everything.
Great, unfortunately "Use msys2" seems to
On Wednesday, 2 August 2017 at 14:51:45 UTC, Mike Wey wrote:
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe
that will fix everything.
Great, unfortunately "Use msys2" seems to be the official way
to install anything GTK related on windows.
on windows.
There seems to be a big bug in gtk or gtkD I have a main window
that I set the center or always center property and when I run it
and try to enlarge the window the window position changes in odd
ways and the title changes. The positions, sizes, etc are not
calculated properly. Possib
On 02-08-17 08:04, Johnson Jones wrote:
Ok, Using msys I was able to get glade 3.20 running. Maybe that will fix
everything.
Great, unfortunately "Use msys2" seems to be the official way to install
anything GTK related on windows.
--
Mike Wey
Ok, Using msys I was able to get glade 3.20 running. Maybe that
will fix everything.
On Tuesday, 1 August 2017 at 20:18:19 UTC, Mike Wey wrote:
On 01-08-17 21:44, Johnson Jones wrote:
On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:
On 01-08-17 05:53, Johnson Jones wrote:
GtkD is currently based on GTK 3 the properties it complains
about were removed in GTK 3.0.
On 01-08-17 21:44, Johnson Jones wrote:
On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:
On 01-08-17 05:53, Johnson Jones wrote:
GtkD is currently based on GTK 3 the properties it complains about
were removed in GTK 3.0.
Which version of glade are you using?
The latest: Glade
On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:
On 01-08-17 05:53, Johnson Jones wrote:
GtkD is currently based on GTK 3 the properties it complains
about were removed in GTK 3.0.
Which version of glade are you using?
The latest: Glade 3.8.5
On 01-08-17 05:53, Johnson Jones wrote:
GtkD is currently based on GTK 3 the properties it complains about were
removed in GTK 3.0.
Which version of glade are you using?
--
Mike Wey
Trying a very simple interface. When I add a notebook I get the
following error
(test.exe:4504): Gtk-[1;31mERROR[0m **: failed to add UI:
C:\Test\Main.Glade:27:43 Invalid property: GtkNotebook.tab_hborder
When removing it from the glade file it then crashes with on the
homogenous
On 07/29/2017 03:54 AM, Cecil Ward wrote:
Is it my bug, or a compiler bug? (name clash at link-time?):
void main()
{
{
immutable static dstring str1 = "a";
}
{
immutable static dstring str1 = "b";
}
}
http
ed out using d.godbolt.org. (Is there any chance of a later
> GDC compiler there?)
>
> Is it my bug, or a compiler bug? (name clash at link-time?):
>
> void main()
> {
> {
> immutable static dstring str1 = "a";
> }
> {
> imm
. (Is there any chance of a later
GDC compiler there?)
Is it my bug, or a compiler bug? (name clash at link-time?):
void main()
{
{
immutable static dstring str1 = "a";
}
{
immutable static dstring
The snippet below failed to compile (I think) in the latest DMD -
but I can't see the error message in the web-based editor at
dlang.org. It certainly failed to compile under GDC 5.2.0 when
tried out using d.godbolt.org. (Is there any chance of a later
GDC compiler there?)
Is it my bug
quot;, 30),
> Tuple!(string, string, int)("Joe", "Carpenter", 30),
> Tuple!(string, string, int)("Fred", "Blacksmith", 40),
> Tuple!(string, string, int)("Fred", "Blacksmith", 40),
> Tuple!(string, string, in
red", "Blacksmith", 40),
Tuple!(string, string, int)("Fred", "Blacksmith", 40),
Tuple!(string, string, int)("Fred", "Blacksmith", 400000)]
It happens because code in
https://github.com/dlang/phobos/blob/master/std/stdio.d#L297
not checks return value after call formattedRead.
Is this a bug? Or I not understand something?
Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
compiles with:
dmd 2.073
fails with:
dmd 2.074
dmd 2.075
Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
Interesting that the same code without immutable works.
Base. However, this is not the case:
main.d(6): Error: class main.Derived cannot implicitly generate
a default ctor when base class main.Base is missing a default
ctor
Is it a bug or it should be like this?
I'd say it's a bug. There was a similar issue at one point where
it wouldn't
main.Derived cannot implicitly generate a
default ctor when base class main.Base is missing a default ctor
Is it a bug or it should be like this?
On Friday, 30 June 2017 at 20:13:37 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2017 at 07:57:22PM +, FoxyBrown via
Digitalmars-d-learn wrote: [...]
[...]
Um... the docs explicit say that dirEntries is lazy, did you
not see that?
[...]
It is possible that dmd has the same problem but I
he
existing slots were already big enough so the problem isn't visible.
OTOH, this still doesn't explain why calling the OS functions directly
fixes the problem. If there is a bug in LDC's version of dirEntries
somewhere, we'd like to know about it so that we can fix it.
T
--
Without outlines, life would be pointless.
se the
os directory listing function manually to extract the data but
this should be investigated as it if it the behavior is what I am
describing, a serious bug exists somewhere. (if someone could
confirm that dirEntries is a lazy range, then it would explain
the problem, but not necessarily why d
On Fri, Jun 30, 2017 at 12:50:24PM +, FoxyBrown via Digitalmars-d-learn
wrote:
> I am using dirEntries to iterate over files to rename them.
>
> I am renaming them in a loop(will change but added code for testing).
>
>
> In DMD the renaming works but in LDC the renaming fails. It fails in
- then it is a serious bug.
Do you use any non-ASCII symbols?
Maybe, the Recompute() function returns a non-unicode string
under LDC?
None of these reasons make sense. They do not take in to account
that simply pre-evaluating dirEntries causes it to work nor the
fact that I said that commenting
On Friday, 30 June 2017 at 12:50:24 UTC, FoxyBrown wrote:
The funny thing is, newName is printed wrong so Recompute is
effected by the rename.
Does LDC use Unicode?
Or, maybe, standard library under LDC does not support Unicode -
then it is a serious bug.
Do you use any non-ASCII symbols
I am using dirEntries to iterate over files to rename them.
I am renaming them in a loop(will change but added code for
testing).
In DMD the renaming works but in LDC the renaming fails. It fails
in a way that I can't quite tell and I cannot debug because
visual D is not working properly
On Thu, 2017-06-22 at 18:38 +, Boris-Barboris via Digitalmars-d-
learn wrote:
> […]
>
> Casts are part of the type system. Yes, D type system allows
> invalid operations. It's not the compiler's fault, it's type
> system's fault.
> […]
Well maybe casts should be allowed as they effectively
On 06/22/2017 08:38 PM, Boris-Barboris wrote:
Casts are part of the type system. Yes, D type system allows invalid
operations. It's not the compiler's fault, it's type system's fault.
unittest
{
immutable int a = 4;
int* b = cast(int*)
*b = 5;
assert(*() == 5);
On Thursday, 22 June 2017 at 19:11:19 UTC, Cym13 wrote:
Here it's the programmer's fault really. You should never use
casts in normal code, cast is the ultimate switch to say "Look,
I know what I'm doing, so disable all safety, don't try to make
sense of it, and let me do my thing. If I'm
On Thursday, 22 June 2017 at 18:38:59 UTC, Boris-Barboris wrote:
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote:
For example, the type system guarantees that immutable data
never changes. But the compiler allows you to cast from
immutable to mutable and change the data. It's an invalid
operation, but the compiler is not expected to catch that for
On 6/21/17 1:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it sees
something that
On 06/22/2017 12:34 PM, Boris-Barboris wrote:
Everything the language allows to compile is allowed by it's type
system, or is a bug in the compiler.
No. D is not supposed to be completely verifiable by the compiler.
For example, the type system guarantees that immutable data never
changes
pe
system, or is a bug in the compiler.
Strong typing means strong typing
Define strong typing then. Pointer is part of the type system,
all casts and operations on it are too. If you pass wrongly-typed
pointer, it won't compile.
Maybe then the fault is having a weak type system, as any
On Wed, 2017-06-21 at 10:23 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
>
> The reason the GC must be conservative is because (1) D is a systems
> programming language, and also because (2) D interfaces directly with
> C.
I think the term "systems programming language" contains no
On Wednesday, 21 June 2017 at 17:11:41 UTC, TheGag96 wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
On 06/21/2017 07:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
Being a systems programming language means you should be able to do
things outside the type system (in @system code, of course, not in @safe
code), including storing pointers as int values. Any C code that your D
program
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
> On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
> > This comes from the fact that D's GC is conservative - if it sees
> > something that *might* be a pointer, it assumes it *is* a pointer
> > and
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
So is the GC then simply made to be "better-safe-than-sorry"
I saw this Tip of the Week a while ago
(http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind
of perplexed at it. It seems like a crazy potential bug... How
exactly is the GC implemented that causes this problem to crop
up? Does the GC just blindly scan memory until it finds
14.06.2017 14:25, ag0aep6g пишет:
It's always a bug when dmd segfaults.
filed https://issues.dlang.org/show_bug.cgi?id=17502
On 06/14/2017 01:06 PM, drug wrote:
https://dpaste.dzfl.pl/b66fffa3bc8d
It's always a bug when dmd segfaults.
https://dpaste.dzfl.pl/b66fffa3bc8d
. This is a feature, not a bug.
It allows overriding of mixin template individual behavior.
see: http://arsdnet.net/this-week-in-d/sep-27.html
To bring in the mixin overloads in addition to your current
ones instead of overriding, use alias:
mixin Foo some_name;
alias foo = some_name.foo
On Wednesday, 17 May 2017 at 13:13:06 UTC, Patric Dexheimer wrote:
Function overloads coming from mixin templates are not being
detected ?
A name being present in the struct means that name is NOT pulled
from the mixin template. This is a feature, not a bug. It allows
overriding of mixin
1)
struct T{
void f1(){writeln("default f1");}
void f1(int x){writeln("overload f1");}
}
//main
T().f1();
T().f1(1);
//compiles and output as expected.
2)
mixin template add_function(){
void f1(){writeln("default f1");}
}
struct T{
mixin add_function;
void f1(int
Aha, https://dlang.org/spec/struct.html#struct-destructor says
that
An identity assignment overload is required for a struct if one
or more of these conditions hold:
* it has a destructor
so this is the above condition coming into play.
The following compiles and runs correctly.
https://forum.dlang.org/post/tzwsohkcqrkqotbwn...@forum.dlang.org
But if I add a destructor to the reference struct template as
follows, it no longer compiles, and the complaints are not about
the destructor.
```
~this()
{
ptr = null;
On Tuesday, 28 March 2017 at 16:30:19 UTC, kinke wrote:
That's a mangling compression scheme (possibly tunable via gcc
options), from
https://github.com/gchatelet/gcc_cpp_mangling_documentation:
To save space a compression scheme is used where symbols that
appears multiple times are then
On Tuesday, 28 March 2017 at 16:30:19 UTC, kinke wrote:
That's a mangling compression scheme (possibly tunable via gcc
options), from
https://github.com/gchatelet/gcc_cpp_mangling_documentation:
To save space a compression scheme is used where symbols that
appears multiple times are then
That's a mangling compression scheme (possibly tunable via gcc
options), from
https://github.com/gchatelet/gcc_cpp_mangling_documentation:
To save space a compression scheme is used where symbols that
appears multiple times are then substituted by an item from the
sequence : S_, S0_, S1_, S2_,
I'm trying to wrap a C++ library and have reduced my problem case
to the code below. I get a linker error due to different name
mangling (this is on Linux):
main.d:(.text._Dmain+0x13): undefined reference to
`_ZN3ns13ns212createStructERN3ns17OptionsE'
The C++ object file has instead a
On Thu, Mar 23, 2017 at 05:11:49PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 23 March 2017 at 00:39:56 UTC, H. S. Teoh wrote:
> > I'm still working on that. :-)
>
> Hey, can you at least put scare quotes around "static foreach" each
> time it is used? There's no such
On Thursday, 23 March 2017 at 00:39:56 UTC, H. S. Teoh wrote:
I'm still working on that. :-)
Hey, can you at least put scare quotes around "static foreach"
each time it is used? There's no such thing as static foreach and
while we might call foreach over a typetuple "static", it isn't a
501 - 600 of 1912 matches
Mail list logo
