On Wednesday, 10 August 2016 at 15:20:37 UTC, Arafel wrote:
I'm not sure if the following is even expected to work, since
I'm not sure how the vtable for the interface would look like
(well, that would be applicable to any overriden templated
method, though):
---
public interface I {
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta
wrote:
On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
Would it even make sense to "force" (deprecation warning) a
"final" keyword in any implicitly-final function (I wasn't
even aware of those, I have to admit)? It
On 8/10/16 12:41 PM, Arafel wrote:
I have to say that the fact that this compiles at all seems like a bug
to me according to [1], even more so that the method in A is called:
That is definitely a bug. D ignores many misplaced attributes, but not
override.
-Steve
On Wednesday, 10 August 2016 at 15:25:40 UTC, Lodovico Giaretta
wrote:
Because templated functions cannot be virtual, it follows that
I.func is final. Having no body, the compiler thinks that its
body will be found by the linker in another object file, but
this does not happen, so the linker
On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
On Wednesday, 10 August 2016 at 15:25:40 UTC, Lodovico Giaretta
wrote:
Because templated functions cannot be virtual, it follows that
I.func is final. Having no body, the compiler thinks that its
body will be found by the linker in
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta
wrote:
I read the spec again, and found out that it says interfaces
cannot contain templated functions... So either my
interpretation is the intended one and the spec is outdated, or
the spec is right and the compiler is bugged.
On Wednesday, 10 August 2016 at 17:04:20 UTC, Jacob Carlborg
wrote:
Thanks, I didn't know that. It's not ideal, it adds some other
tags that I would like to avoid, i.e. "Page generated by Ddoc",
but it works.
those are in the macro definition file, you can make your own and
simplify/improve.
On Wednesday, 10 August 2016 at 15:54:42 UTC, Adam D. Ruppe wrote:
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta
wrote:
I read the spec again, and found out that it says interfaces
cannot contain templated functions... So either my
interpretation is the intended one and the
On Wednesday, 10 August 2016 at 15:07:52 UTC, Ali Çehreli wrote:
On 08/10/2016 02:05 AM, ciechowoj wrote:
Better with some mixin magic:
mixin template CArray(string symbol, T) {
pragma(mangle, symbol) extern extern(C) __gshared
mixin ("T[0] _c" ~ symbol ~ ";");
@property
mixin
On Wednesday, 10 August 2016 at 15:52:29 UTC, Lodovico Giaretta
wrote:
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta
wrote:
On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
Would it even make sense to "force" (deprecation warning) a
"final" keyword in any
On 10/08/16 16:48, Kagamin wrote:
dmd generates html from dd files; example:
https://github.com/dlang/dlang.org/blob/master/download.dd
Thanks, I didn't know that. It's not ideal, it adds some other tags that
I would like to avoid, i.e. "Page generated by Ddoc", but it works.
--
/Jacob
On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ =
S.init.opBinary!"+"(int.init));
Made a typo, this should be:
static assert(__traits(compiles, { auto _ =
S.init.opBinary!"+"(int.init); }));
On Wednesday, 10 August 2016 at 12:36:14 UTC, Arafel wrote:
Hi,
I'm trying to check at compilation time if a given type
implements some operator (let's assume it's '+' in this case),
without caring about the type of the parameters it accepts.
Since operator overloading is expressed in D
On Wednesday, 10 August 2016 at 12:36:14 UTC, Arafel wrote:
Hi,
I'm trying to check at compilation time if a given type
implements some operator (let's assume it's '+' in this case),
without caring about the type of the parameters it accepts.
Since operator overloading is expressed in D
On Wednesday, 10 August 2016 at 13:57:54 UTC, Arafel wrote:
On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:
On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ =
S.init.opBinary!"+"(int.init));
Made a typo, this should be:
static
dmd generates html from dd files; example:
https://github.com/dlang/dlang.org/blob/master/download.dd
Hi,
I'm trying to check at compilation time if a given type
implements some operator (let's assume it's '+' in this case),
without caring about the type of the parameters it accepts. Since
operator overloading is expressed in D through templated
functions, what is the preferred way of
I'm not sure if the following is even expected to work, since I'm
not sure how the vtable for the interface would look like (well,
that would be applicable to any overriden templated method,
though):
---
public interface I {
void func(T)(T t);
}
public class C : I {
void
On Wednesday, August 10, 2016 13:57:54 Arafel via Digitalmars-d-learn wrote:
> On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:
> > On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
> >> static assert(__traits(compiles, auto _ =
> >> S.init.opBinary!"+"(int.init));
> >
> > Made a
On 08/10/2016 02:05 AM, ciechowoj wrote:
On Tuesday, 9 August 2016 at 19:16:42 UTC, Steven Schveighoffer wrote:
D has an answer:
pragma(mangle, "tab")
extern extern(C) int[1] _ctab;
@property int* tab() { return _ctab.ptr; }
I still don't recommend doing this, for previously stated reasons.
On Wednesday, August 10, 2016 12:36:14 Arafel via Digitalmars-d-learn wrote:
> Hi,
>
> I'm trying to check at compilation time if a given type
> implements some operator (let's assume it's '+' in this case),
> without caring about the type of the parameters it accepts. Since
> operator overloading
On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:
On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ =
S.init.opBinary!"+"(int.init));
Made a typo, this should be:
static assert(__traits(compiles, { auto _ =
What's the best way to generate HTML from a snippet of Ddoc? I've
extracted the Ddoc from a symbol using DCD and would like to display it
in a text editor. Ideally it should be a command line tool.
--
/Jacob Carlborg
On Wednesday, 10 August 2016 at 18:08:02 UTC, Lodovico Giaretta
wrote:
I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of
front...
On Wednesday, 10 August 2016 at 18:38:00 UTC, Ali Çehreli wrote:
RangeWrapper does not provide the InputRange interface, so the
compiler uses 'alias this' and iterates directly on the member
range.
I tried making RangeWrapper an InputRange but failed. It still
uses 'range'.
// Still fails
I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of
front...
=
import std.stdio, std.container.array;
struct
On 08/10/2016 11:08 AM, Lodovico Giaretta wrote:
> I'm probably missing something stupid but...
> Why on earth do the two loops in main print a different result?
> It looks like the foreach lowering is ignoring my definition of front...
>
> =
>
On 08/10/2016 11:47 AM, Lodovico Giaretta wrote:
On Wednesday, 10 August 2016 at 18:38:00 UTC, Ali Çehreli wrote:
RangeWrapper does not provide the InputRange interface, so the
compiler uses 'alias this' and iterates directly on the member range.
I tried making RangeWrapper an InputRange but
On 10/08/16 19:10, Adam D. Ruppe wrote:
those are in the macro definition file, you can make your own and
simplify/improve.
I replaced the DDOC macro with my own version, that worked fine. Thanks.
--
/Jacob Carlborg
On Wednesday, 10 August 2016 at 19:37:39 UTC, Ali Çehreli wrote:
A quick read reveals popFront() is implemented only for bool
Arrays. That explains the issue.
I don't know whether it's an oversight.
Ali
First of all, thank you for spending your time on this issue. I
really appreciate that.
On Wednesday, 10 August 2016 at 21:00:01 UTC, Lodovico Giaretta
wrote:
On Wednesday, 10 August 2016 at 20:54:15 UTC, Steven
Schveighoffer wrote:
[...]
Wow. Thanks. I didn't know the compiler would try opSlice. I
will file it.
Filed on bugzilla:
On 10/08/16 16:48, Kagamin wrote:
dmd generates html from dd files; example:
https://github.com/dlang/dlang.org/blob/master/download.dd
Unfortunately it looks like Standard Sections [1] are not handled in the
same way as when generating documentation from D source files. They're
handled just
On Wednesday, August 10, 2016 21:00:01 Lodovico Giaretta via Digitalmars-d-
learn wrote:
> Wow. Thanks. I didn't know the compiler would try opSlice. I will
> file it.
It does that so that you can use foreach with containers without having to
call something on the container. The idea is that the
void foo(@nogc void delegate())
doesn't work.
But declaring an alias does, but too verbose. Surely we should be
able to add the attribute directly?
On 08/10/2016 04:32 PM, WhatMeWorry wrote:
string pwdxCommand = escapeShellCommand("pwdx", to!string(pid));
writeln("pwdxCommand = ", pwdxCommand);
Output:
Current process ID: 7962
pwdxCommand = 'pwdx' '7962'
I'm confused as to why the writeln statement didn't output "pwdx 7962"?
On 08/11/2016 06:15 AM, Engine Machine wrote:
void foo(@nogc void delegate())
doesn't work.
Put it after the parameter list, like so:
void foo(void delegate() @nogc)
On 8/10/16 2:08 PM, Lodovico Giaretta wrote:
I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of front...
=
import
On Wednesday, 10 August 2016 at 20:54:15 UTC, Steven
Schveighoffer wrote:
On 8/10/16 2:08 PM, Lodovico Giaretta wrote:
[...]
The issue is that it tries using [] on the item to see if it
defines a range-like thing. Since you don't define opSlice(),
it automatically goes to the subrange.
On 08/10/2016 10:54 PM, Steven Schveighoffer wrote:
The issue is that it tries using [] on the item to see if it defines a
range-like thing. Since you don't define opSlice(), it automatically
goes to the subrange.
This breaks for int[] as well as Array.
If I add opSlice to your code (and
On Monday, 8 August 2016 at 12:29:51 UTC, Seb wrote:
You should always carefully read the description and Notes ;-)
Note:
Each front will not persist after popFront is called, so the
caller must copy its contents (e.g. by calling to!string) when
retention is needed. If the caller needs to
On Tuesday, 9 August 2016 at 19:16:42 UTC, Steven Schveighoffer
wrote:
D has an answer:
pragma(mangle, "tab")
extern extern(C) int[1] _ctab;
@property int* tab() { return _ctab.ptr; }
I still don't recommend doing this, for previously stated
reasons.
This is really interesting :).
On Tuesday, 9 August 2016 at 19:16:46 UTC, Ali Çehreli wrote:
Well, C's array symbol is used as a pointer to the first
element and D allows array indexing for pointers as well.
Here is the C code:
// c.c
#include "stdio.h"
int tab[64];
int *get() {
return tab;// or [0]
}
void
On Monday, 8 August 2016 at 16:30:39 UTC, Meta wrote:
Alternatively you can use std.stdio.byLineCopy and don't need
to add the `to!string`. If you are calling to!string on ever
line there will probably be no performance difference, but if
you are not, such as only calling to!string on every
string pwdxCommand = escapeShellCommand("pwdx", to!string(pid));
writeln("pwdxCommand = ", pwdxCommand);
Output:
Current process ID: 7962
pwdxCommand = 'pwdx' '7962'
I'm confused as to why the writeln statement didn't output "pwdx
7962"?
Afterall, isn't that the definition of a
44 matches
Mail list logo
