On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
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 Monday, 4 September 2017 at 03:08:50 UTC, EntangledQuanta
wrote:
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 Septembe
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC,
EntangledQuanta wrote:
[...]
The contexts
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
[...]
The contexts being independent of each other doesn't change
that we would still
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC,
EntangledQuanta wrote:
On Friday, 1 Sept
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being ab
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic
functions in C#. Unfortunately C# d
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so
many other issues where Generics jus
On Saturday, 2 September 2017 at 16:20:10 UTC, Jesse Phillips
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
Regardless of the implementation, the idea that we should
throw the baby out with the bathwater is simply wrong. At
least there are a few who get that. By l
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
Regardless of the implementation, the idea that we should throw
the baby out with the bathwater is simply wrong. At least there
are a few who get that. By looking in to it in a serious manner
an event better solution might be
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
I've love being able to inherit and override generic functions in
C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
compiler to generate a virtual function for every instantiated T,
a
This happens when building, not running. This might be a Visual D
issue as when I use dmd from the command line, it works fine ;/
On Friday, 1 September 2017 at 19:25:53 UTC, Adam D Ruppe wrote:
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means
you didn't new the class...
No, that is the code!
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means you
didn't new the class...
On Friday, 1 September 2017 at 15:24:39 UTC, Adam D. Ruppe wrote:
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list
of types
}
c
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list of
types
}
class Ass : Foo {
static foreach(T; I!(int, float))
On Thursday, 31 August 2017 at 15:48:12 UTC, EntangledQuanta
wrote:
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all mea
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all means, genius!
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
On 08/30/2017 05:49 PM, EntangledQuanta wrote:
> The compiler can and should do this!
Yes, the compiler can do it for each compilation but there is also the
feature called /separate compilation/ that D supports. With separate
compilation, there would potentially be multiple different and
inco
On Wednesday, 30 August 2017 at 22:52:41 UTC, Adam D. Ruppe wrote:
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 t
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 from
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 i
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 v
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 LLP64,
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) :
bre
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 Windows
On Tuesday, 29 August 2017 at 00:42:45 UTC, Steven Schveighoffer
wrote:
On 8/28/17 7:47 PM, Johnson Jones wrote:
[...]
Then I think possibly the port audio bindings are not correct.
It's also possible that long is not 64-bit even on the platform
you are using. Finally, it's also possible tha
On 8/28/17 7:47 PM, 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:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041e
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, [typeid(PaStreamParameters)+
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 becaus
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 corre
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 fo
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, [eax
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]
004
0x
You can find the full code at
https://forum.dlang.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 i
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 to
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, sinc
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. Instead
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
On Friday, 11 August 2017 at 04:17:32 UTC, ketmar wrote:
Mr. Pib wrote:
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowerca
Mr. Pib wrote:
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile time,
x
100
x = d;
there is no lowercase d. I did initially define Q as
string Q(alias T, D)(D
string Q(alias T, alias D)()
{
pragma(msg, T);
pragma(msg, D);
enum x = T~" = "~D~";";
pragma(msg, x);
}
mixin(Q!(`x`, 100)());
outputs, at compile 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
56 matches
Mail list logo
