Re: Compiling a template
On Friday, 7 December 2018 at 01:21:42 UTC, Ali Çehreli wrote:
There is no trace of the template in the library or the object
file. You can investigate the compiled symbols with e.g. the
'nm' tool on Linux systems:
// deneme.d:
void foo(T)(T t) {
import std.stdio;
writeln(t);
}
void main() {
// foo(42);
}
$ dmd deneme.d -lib
$ nm deneme.a | grep foo
No trace of foo... Now uncomment the line in main and repeat:
$ dmd deneme.d -lib
$ nm deneme.a | grep foo
U _D6deneme__T3fooTiZQhFNfiZv
W _D6deneme__T3fooTiZQhFNfiZv
"W" indicates a definition.
I see, what confused me was that if I put main() in a different
file and
$ dmd main.d deneme.a
the program compiled properly. Now I realize that in this case
deneme.a file was ignored and the source file was used instead. I
expected an error. Thank you for your answers.
Re: Compiling a template
On Thu, 06 Dec 2018 22:50:49 +, albertas-jn wrote: > If templates are a compile-time feature and instances of templates are > generated by compiler at compile time, why is it possible to compile a > template definition with dmd -lib or -c? You compile files, not individual declarations like a template. If you have a source file containing a hundred templates and nothing else, and you compile it, you'll get the same output as if you had an empty source file, byte for byte.
Re: Trying to get current function name results in compiler error with __traits
On Fri, 07 Dec 2018 02:37:34 +, Arun Chandrasekaran wrote:
> I'm trying to get the current function name and apparently the commented
> line errors out.
>
> What am I doing wrong?
Referring to nested functions is weird.
Dotted identifiers let you traverse aggregates. Modules, C++ namespaces
(ugh), enums, structs, identifiers, unions, that sort of thing. They
*don't* let you traverse functions to refer to symbols defined inside
those functions.
*Separately*, nested functions have names that look like dotted
identifiers. But you can't use that to refer to them, because that would
make it *very* awkward to do symbol lookup.
For example:
struct Foo { int bar; }
Foo test()
{
void bar() { }
writeln();
return Foo();
}
Should the `writeln` line invoke the `test` function, get the `bar` field
from its result, and take its address? Or should it take the address of
the nested function `bar`?
Trying to get current function name results in compiler error with __traits
I'm trying to get the current function name and apparently the
commented line errors out.
What am I doing wrong?
https://run.dlang.io/is/EGsRU2
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
void foo() {
// __traits(identifier, mixin(__FUNCTION__)).writeln; //
compilation error
__FUNCTION__.split('.')[$-1].writeln;
}
__traits(identifier, mixin(__FUNCTION__)).writeln;
__FUNCTION__.split('.')[$-1].writeln;
foo();
}
```
Re: Compiling a template
On 12/06/2018 02:50 PM, albertas-jn wrote:
If templates are a compile-time feature and instances of templates are
generated by compiler at compile time, why is it possible to compile a
template definition with dmd -lib or -c?
There is no trace of the template in the library or the object file. You
can investigate the compiled symbols with e.g. the 'nm' tool on Linux
systems:
// deneme.d:
void foo(T)(T t) {
import std.stdio;
writeln(t);
}
void main() {
// foo(42);
}
$ dmd deneme.d -lib
$ nm deneme.a | grep foo
No trace of foo... Now uncomment the line in main and repeat:
$ dmd deneme.d -lib
$ nm deneme.a | grep foo
U _D6deneme__T3fooTiZQhFNfiZv
W _D6deneme__T3fooTiZQhFNfiZv
"W" indicates a definition.
Ali
Compiling a template
If templates are a compile-time feature and instances of templates are generated by compiler at compile time, why is it possible to compile a template definition with dmd -lib or -c?
Re: Compiling a template
On Thursday, 6 December 2018 at 22:50:49 UTC, albertas-jn wrote: If templates are a compile-time feature and instances of templates are generated by compiler at compile time, why is it possible to compile a template definition with dmd -lib or -c? Because to instantiate the source code is still used (-I). Just the D interface is even not enough.
Re: struct static initializer method apply to UDA
On Thursday, 6 December 2018 at 12:50:34 UTC, Radu wrote: On Thursday, 6 December 2018 at 11:09:47 UTC, Basile B. wrote: Which would be a real nice feature to have. this is what I need, I guess I has to wait.
Re: dub is building docs of dependencies
On Thursday, 6 December 2018 at 14:09:34 UTC, Jedzia wrote: On Wednesday, 5 December 2018 at 12:00:45 UTC, Andre Pany wrote: [...] Thank you Andre, but that refers to ddox which is badly applicable under windows, thanks to the "Unexpected OPTLINK Termination at EIP=." problem. A solution to this is building ddox from the repository with `dub build --arch=x86_64`. With ´dub build --arch=x86_64 -b ddox´ in the minimal app above and your filter added(and without), the ddox build fails with the above error. For reasons I don't know it seems that ddox is build as 32bit app and OPTILINK fails. The solution for this is to point dub to my successful built 64bit ddox ... which I don't know how to do. If someone can clarify this? Thanks. [...] With next version of dub, also ddox respects the architecture. https://github.com/dlang/dub/pull/1588 Yes, we should adapt the documentation and add a dub docs command. Kind regards Andre
Re: dub is building docs of dependencies
Okay, what i am trying to achieve is simply not there. BuildOption._docs is a enum, that is passed recursively to the dependencies and switches doc building on and object building off for the different generators (I missed to say that i am using dmd -> "-o-", "-Dddocs"). What i was looking for is a dub command-target like "build", "run", "test". Oh "add docs command" -> https://github.com/dlang/dub/issues/501 Not a solution, but a warm feeling of knowledge:)
Re: Ambiguous virtual function
On Thursday, 6 December 2018 at 07:37:12 UTC, John Chapman wrote:
Is the compiler giving the non-mixed-in function special
treatment?
Yes, this is by design:
https://dlang.org/spec/template-mixin.html#mixin_scope
It allows you to have multiple functions in a mixin and override
them selectively by repeating the name after the mixin.
mixin template Base() {
void foo() {}
void bar() {}
}
class Class {
mixin Base; // I like the bar from there, but want a custom
foo
void foo() {} // so I write this and it just works!
}
If it turns out you do want some of the stuff from the mixin
after all, you simply give it a name and reference it:
class Class {
mixin Base base;
void foo() {
base.foo();
}
}
There, I "overrode" foo from the mixin, and also called the
version from the mixin, analogous to the regular "super.foo" from
plain inheritance.
Note that you can still call "obj.bar();" with the renaming - the
"mixin Base base" and "mixin Base" are indistinguishable from
each other as far as users of your class are concerned.
You can also handle overloads this way:
class Class {
mixin Base base;
void foo(int) {}
}
Here, I want to offer an overload. Normally, this would override
ALL "foo" stuff from Base because it works on the basis of the
name alone. But you can merge the overload sets with alias:
class Class {
mixin Base base;
void foo(int) {}
alias foo = base.foo;
}
and now they are combined again! Thus foo() and foo(int) are both
present in Class.
With specialized templates, it doesn't quite work that way, you
will get another compile error (they aren't technically function
overloads, so it isn't a bug per se, the compiler is following
the spec, but I think it might be considered one anyway because
you'd kinda expect it to work the same way)...
This is what Dennis saw in his bug report. I commented there too,
but here's the answer:
struct S {
mixin Operators ops;
int opBinary(string op: "*")(S rhs) {return 2;}
int opBinary(string op)(S rhs) {
// forward all others to the mixin
return ops.opBinary!op(rhs);
}
}
You write an unspecialized version in the top-level thing that
calls into the mixin one. It will then do the specialization from
there, with the compiler picking the right one from top level if
available, or calling the generic fallback to try the next level
if possible, or still throwing an error if the operator is indeed
not implemented.
Re: dub is building docs of dependencies
On Wednesday, 5 December 2018 at 12:00:45 UTC, Andre Pany wrote:
On Wednesday, 5 December 2018 at 02:08:13 UTC, Jedzia wrote:
dmd2-2.083.0, win
minimal dub init
with dub.json:
{
"description": "A minimal D application.",
"dependencies": {
"iz": "~>0.6.23"
},
"authors": [
"Jedzia"
],
"copyright": "Copyright © 2018, Jedzia",
"license": "MIT",
"name": "testdoc"
}
and `dub build -b docs`
Is it normal that dub builds the docs of dependencies (iz
library in that case).
And if, how to build only the docs of my own project?
To your dub.json you can add following line to exclude e.g.
arsd.cgi:
"-ddoxFilterArgs": ["--ex", "arsd.cgi", "--min-protection",
"Public"],
Kind regards
André
Thank you Andre, but that refers to ddox which is badly
applicable under windows, thanks to the "Unexpected OPTLINK
Termination at EIP=." problem.
A solution to this is building ddox from the repository with `dub
build --arch=x86_64`.
With ´dub build --arch=x86_64 -b ddox´ in the minimal app above
and your filter added(and without), the ddox build fails with the
above error. For reasons I don't know it seems that ddox is build
as 32bit app and OPTILINK fails.
The solution for this is to point dub to my successful built
64bit ddox ... which I don't know how to do. If someone can
clarify this? Thanks.
But all of that has nothing to do with the simple and essential
task of building documentation for your project. Not for the
dependencies, not for something else. Your project.
Don't get me wrong. I am not pissed, only lost as newbie. The
solution or at least a hint to this problem should be stated in
the documentation right under
http://code.dlang.org/docs/commandline#build and should not turn
into a research project:)
So lets dig into
https://github.com/dlang/dub/blob/master/source/dub/commandline.d
GeneratorSettings.m_buildType == "docs"
Re: struct static initializer method apply to UDA
On Thursday, 6 December 2018 at 11:09:47 UTC, Basile B. wrote:
On Thursday, 6 December 2018 at 11:04:23 UTC, learnfirst1 wrote:
my question is how to easy use struct static initializer
method with UDA.
Fake code:
struct DbColumn {
string name;
boolunique ;
boolsigned ;
boolnullable ;
}
struct Order {
uint id;
@DbColumn({ .nullable= true}) // not working
string order_id;
@DbColumn({ :nullable= true}) // not working
string order_time;
@DbColumn(nullable= true) // not working
string order_time;
}
Looks like what you want is named parameters.
Actually he's looking for in-place struct initialization
https://github.com/dlang/DIPs/blob/b1283b455b635d7dcbc2c871d2aa47cc67190059/DIPs/DIP1xxx-sw.md
Which would be a real nice feature to have.
Re: struct static initializer method apply to UDA
On Thursday, 6 December 2018 at 11:04:23 UTC, learnfirst1 wrote:
my question is how to easy use struct static initializer
method with UDA.
Fake code:
struct DbColumn {
string name;
boolunique ;
boolsigned ;
boolnullable ;
}
struct Order {
uint id;
@DbColumn({ .nullable= true}) // not working
string order_id;
@DbColumn({ :nullable= true}) // not working
string order_time;
@DbColumn(nullable= true) // not working
string order_time;
}
Looks like what you want is named parameters.
struct static initializer method apply to UDA
my question is how to easy use struct static initializer
method with UDA.
Fake code:
struct DbColumn {
string name;
boolunique ;
boolsigned ;
boolnullable ;
}
struct Order {
uint id;
@DbColumn({ .nullable= true}) // not working
string order_id;
@DbColumn({ :nullable= true}) // not working
string order_time;
@DbColumn(nullable= true) // not working
string order_time;
}
Re: Ambiguous virtual function
On Thursday, 6 December 2018 at 07:37:12 UTC, John Chapman wrote:
Is the compiler giving the non-mixed-in function special
treatment?
I think you're running into this bug:
https://issues.dlang.org/show_bug.cgi?id=19365
I see that it is not limited to operator overloading, in general
the overload set directly put into a struct/class completely
overrides the overload set from mixin templates. mixin strings
seem to work fine, so you can use those as temporary workaround.
Example:
```
mixin template F() {
int fun(int i) {return i;}
}
struct S {
mixin F; // (1)
mixin(`int fun(int i) {return i;}`); // (2)
string fun(string s) {return s;} // (3)
}
void main() {
import std.stdio;
S().fun(1).writeln();
}
```
With only the mixin template (1) it works, adding an overload (3)
breaks it, though adding the string mixin (2) fixes it even
though it should be ambiguous with (1).
