Conflict between function and template with the same name
I have a question about this example code;
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum
//string
getByName = getByName(name);
}
void main()
{
writeln(getByName!(name));
}
This produces compilation output:
/d967/f983.d(13): Error: forward reference of variable getByName
/d967/f983.d(19): Error: template instance f983.getByName!name
error instantiating
Uncommenting line *//string* changes message to:
Compilation output:
/d976/f558.d(13): Error: recursive evaluation of getByName(name)
/d976/f558.d(19): Error: template instance f558.getByName!name
error instantiating
Is there any reason why function and template conflict. They
using different syntax to *call*. For template we have *!* but
for function we don't have it. So why compiler is not able to see
the difference?
Re: import except one?
A bit late, but you should also be able to do: import scriptlike; alias Config = std.process.Config;
Re: httpS post fail at tango
On Thursday, 26 June 2014 at 17:07:30 UTC, JJDuck wrote: On Thursday, 26 June 2014 at 16:33:57 UTC, JJDuck wrote: I tried to use phobos , but there is no such function exists for posting to https too With Phobos, you can use http://dlang.org/phobos/std_net_curl.html#post. Depending on the SSL certificate (i.e., if it's self-signed), you may need to use the C API to cURL and disable SSL verification (http://dlang.org/phobos/etc_c_curl.html). With curl, if it works for http it works for https, provided no certificate issues are found. Tango isn't really used much anymore and Phobos is the official standard library now (though you can use Tango alongside it), so you'd probably have a hard time finding help for Tango on these forums.
Re: Why is the Win32 boilerplate the way it is?
On 2014-06-29 06:47, Jeremy Sorensen wrote: I found an example of boilerplate code for Win32 programming in D here: http://wiki.dlang.org/D_for_Win32 I have some questions. 1. It appears that the call to myWinMain from WinMain is to ensure that any exception or error is caught. At first glance it looks like this is to ensure that runtime.terminate() gets called, but in fact it doesn't, the catch block doesn't do it and there is no scope(exit). Is this a problem? (And what would happen if you didn't catch the exception?) 2. Why does the boilerplate return 0 on success and failure? (If the return code is irrelevant, why the comment that says failed next to the return code?) 3. I can't imagine a technical reason why the myWinMain signature has to match the WinMain signature. Wouldn't it be better to omit the hPrevInstance since it isn't used? (Or are we preserving backwards compatibility with Win16?). If there is a resource somewhere that explains all this I would happy to consult it but I couldn't find anything. You don't need to use WinMain. You can use a plain D main function and add the -L/SUBSYSTEM:WINDOWS:4.0 link flag to suppress the console. There are API's to get access to the arguments passed to WinMain, if necessary. -- /Jacob Carlborg
Re: Conflict between function and template with the same name
On Sunday, 29 June 2014 at 07:16:10 UTC, Uranuz wrote:
Is there any reason why function and template conflict. They
using different syntax to *call*. For template we have *!* but
for function we don't have it. So why compiler is not able to
see the difference?
I suspect this is by design. The following works, note the dot
before the getByName function call:
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum getByName = .getByName(name);
}
void main()
{
writeln(getByName!(name));
}
Re: Conflict between function and template with the same name
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum getByName = .getByName(name);
}
void main()
{
writeln(getByName!(name));
}
Thanks a lot! Very interesting. Do you see any reasoning why this
happens?
Re: Conflict between function and template with the same name
On Sunday, 29 June 2014 at 08:52:36 UTC, Uranuz wrote:
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum getByName = .getByName(name);
}
void main()
{
writeln(getByName!(name));
}
Thanks a lot! Very interesting. Do you see any reasoning why
this happens?
I think it has to do with variable shadowing. The lookup rules
for enums are the same as for variables. Since the getByName enum
is declared inside the template scope it takes precedence over
the function in the outer scope, even when initializing the enum.
I'm not sure though, hopefully someone a bit more knowledgeable
than me comes along to clarify.
Prepending a dot makes the lookup happen in global scope.
Re: Conflict between function and template with the same name
On 06/29/2014 11:31 AM, Rene Zwanenburg wrote:
On Sunday, 29 June 2014 at 08:52:36 UTC, Uranuz wrote:
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum getByName = .getByName(name);
}
void main()
{
writeln(getByName!(name));
}
Thanks a lot! Very interesting. Do you see any reasoning why this
happens?
I think it has to do with variable shadowing. The lookup rules for enums
are the same as for variables. Since the getByName enum is declared
inside the template scope it takes precedence over the function in the
outer scope, even when initializing the enum.
I'm not sure though, hopefully someone a bit more knowledgeable than me
comes along to clarify.
Prepending a dot makes the lookup happen in global scope.
I think it is either a bug or an unnecessary limitation. The following
compiles:
string s;
void writeln(T...)(T args){ s~=args[0]; writeln(args[1..$]); }
void writeln(){ s~=\n; }
string getByName()(string name){
return smth;
}
void getByName(){
pragma(msg, getByName!foo);
}
template getByName(string name){
enum getByName = getByName!()(name);
}
void main(){
pragma(msg,getByName!(name));
writeln(123,1234);
}
I.e. calling a different overload from a templated function is
supported, instantiating a different overload from a function is
supported, instantiating a different overload from template scope is
supported, but not calling a different overload from template scope.
It's probably left out accidentally.
How to forward format specifiers ?
I am trying to define custom format specifiers (as described here [1])
for the following wrapper struct :
import std.stdio;
import std.format: formattedWrite, FormatSpec;
import std.string: format;
struct wrapper(T) {
private T val;
public this(T newVal) pure { val = newVal; }
public void toString(
scope void delegate(const(char)[]) sink,
FormatSpec!char fmt
) const
{
formattedWrite(sink, /+ Format string +/ , val);
}
}
unittest {
immutable uint base = 16;
auto a = wrapper!uint(base);
assert(format(%x, a) == format(%x, base));
assert(format(%08x, a) == format(%08x, base));
}
More precisely, I want to forward the format specifier fmt received by
wrapper!T.toString to formattedWrite.
Since formattedWrite expects a const(char)[] string as its second
argument, I first naively tried to use :
formattedWrite(sink, to!string(fmt), val);
but to!string(fmt) gives something similar to :
address = 7FFFE91C54C0
width = 0
precision = 2147483646
spec = x
indexStart = 0
indexEnd = 0
flDash = false
flZero = false
flSpace = false
flPlus = false
flHash = false
nested =
trailing =
instead of the original format string, thus causing toString to fail at
runtime.
The documentation for std.format [2] mentions a second prototype (among
four) for toString :
const void toString(
scope void delegate(const(char)[]) sink,
string fmt
);
So I tried to modify wrapper!T.toString as follows :
public void toString(
scope void delegate(const(char)[]) sink,
string fmt
) const
{
formattedWrite(sink, fmt, val);
}
but this one throws exception at runtime :
std.format.FormatException@/usr/include/dlang/dmd/std/format.d(2537):
Expected '%s' format specifier for type 'wrapper!uint'.
I can make it work for simple cases by manually creating the format
string using format() with the FormatSpec attributes, but this approach
is not generic and will fail for complex format strings.
I've certainly missed something, but I can't figure out what is the
right way to do it. What did I do wrong here ?
I remember having seen the void toString(scope void delegate(/*...*/),
/*...*/) const prototypes being deprecated, but I don't know where it
was. Maybe there is a better solution now ?
[1] http://wiki.dlang.org/Defining_custom_print_format_specifiers
[2] http://dlang.org/phobos-prerelease/std_format.html#.formatValue
Re: How to forward format specifiers ?
On 06/29/2014 04:55 AM, Element 126 wrote:
I've certainly missed something
formatValue passes your tests:
import std.stdio;
import std.format: formattedWrite, FormatSpec, formatValue;
import std.string: format;
struct wrapper(T) {
private T val;
public this(T newVal) pure { val = newVal; }
public void toString(
scope void delegate(const(char)[]) sink,
FormatSpec!char fmt
) const
{
formatValue(sink, val, fmt);// -- HERE
}
}
unittest {
immutable uint base = 16;
auto a = wrapper!uint(base);
assert(format(%x, a) == format(%x, base));
assert(format(%08x, a) == format(%08x, base));
}
void main()
{}
Ali
Re: Why is the Win32 boilerplate the way it is?
On Sunday, 29 June 2014 at 07:51:50 UTC, Jacob Carlborg wrote: You don't need to use WinMain. You can use a plain D main function and add the -L/SUBSYSTEM:WINDOWS:4.0 link flag to suppress the console. There are API's to get access to the arguments passed to WinMain, if necessary. OK so I just tried this and found some amazing things. By using main instead of WinMain the std runtime is automatically loaded, and uncaught exceptions are not swallowed up like in WinMain, so you don't need the try-catch anymore! This makes life much better. The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? Will you get an error message or just silent failure?
Re: Why is the Win32 boilerplate the way it is?
The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? WinXP is dead :)
Re: How to forward format specifiers ?
On 06/29/2014 04:22 PM, Ali Çehreli wrote:
On 06/29/2014 04:55 AM, Element 126 wrote:
I've certainly missed something
formatValue passes your tests:
import std.stdio;
import std.format: formattedWrite, FormatSpec, formatValue;
import std.string: format;
struct wrapper(T) {
private T val;
public this(T newVal) pure { val = newVal; }
public void toString(
scope void delegate(const(char)[]) sink,
FormatSpec!char fmt
) const
{
formatValue(sink, val, fmt);// -- HERE
}
}
unittest {
immutable uint base = 16;
auto a = wrapper!uint(base);
assert(format(%x, a) == format(%x, base));
assert(format(%08x, a) == format(%08x, base));
}
void main()
{}
Ali
Thanks a lot ! I just checked if it also worked for structs and classes
and it does the job perfectly.
I have used formattedWrite for months without noticing formatValue, even
though it was on the wiki.
Maybe I should add an example to the documentation of std.format.
formatValue is present but without any example, compared to the
extensive documentation of formattedWrite.
Re: Why is the Win32 boilerplate the way it is?
On 2014-06-29 17:06, Jeremy Sorensen wrote: The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? Will you get an error message or just silent failure? Actually, I don't know. You could try some different value. If you search on Google I'm sure you'll find something. -- /Jacob Carlborg
Bizarre compile error in GtkD
Hello, I have a compile error when trying to use GtkD 2.3.3. When I try to create a FileChooseDialog, I call new FileChooserDialog(Save File, editor.drawingArea.getParent().getParentWindow(), FileChooserAction.SAVE, [OK, Cancel], [GtkResponseType.OK, GtkResponseType.CANCEL]); When I do this, I get the error Error: constructor gtk.FileChooserDialog.FileChooserDialog.this (GtkFileChooserDialog* gtkFileChooserDialog) is not callable using argument types (string, Window, GtkFileChooserAction, string[], GtkResponseType[]) To test why I was getting this error, because there should be another constructor with that signature. After commenting out the one value constructor, I get the error Error: constructor gtk.FileChooserDialog.FileChooserDialog.this (string title, Window parent, GtkFileChooserAction action, string[] buttonsText, GtkResponseType[] responses) is not callable using argument types (string, Window, GtkFileChooserAction, string[], GtkResponseType[]) I have no idea how this error exists. Can anyone help me fix it? -Evan Davis
Re: What is best way to communicate between computer in local network ?
On Friday, 27 June 2014 at 12:51:45 UTC, bioinfornatics wrote: Hi, I have a linux network and i would like to know if they are a D library to communicate between computer efficiently. I do not know if that is better to use websocket and if they exists into dlang: - http://planet.jboss.org/post/rest_vs_websocket_comparison_and_benchmarks Thanks for your help Regards Not efficient in any means, but DHSL allows to create super simple webservers. https://github.com/canidae/DHSL
Re: How to forward format specifiers ?
On Sun, Jun 29, 2014 at 06:08:24PM +0200, Element 126 via Digitalmars-d-learn wrote: [...] I have used formattedWrite for months without noticing formatValue, even though it was on the wiki. Maybe I should add an example to the documentation of std.format. formatValue is present but without any example, compared to the extensive documentation of formattedWrite. Please do! We need all the help we can get to improve Phobos documentation. T -- Real programmers can write assembly code in any language. :-) -- Larry Wall
Redirect to different overloads at compile time?
Suppose I have a C library which implements a function for
several types. C doesn't have overloading, so their names will be
distinct.
extern(C):
double foo_double(double);
float foo_float(float);
Now I want to build a D wrapper, and merge them into a single
function with overloading:
T foo(T)
I could write out the two overloads manually:
double foo(double d) { return foo_double(d); }
float foo(float f) { return foo_float(f); }
but this isn't compile time, it will generate a stub function for
each overload, meaning the wrapper will have performance overhead
unless inlining can be guaranteed somehow.
Is it possible to do something like
alias foo = foo_double;
alias foo = foo_float;
or
template(T) foo {
static if(T is double) {
alias foo = foo_double;
} else {
// etc.
}
}
These doesn't work of course.
I don't fully understand the template syntax yet, but I have a
feeling this is possible with templates. Is it possible to do
what I'm trying to do?
Re: Redirect to different overloads at compile time?
On Sun, 29 Jun 2014 22:24:09 -0400, David Bregman d...@sfu.ca wrote:
Suppose I have a C library which implements a function for several
types. C doesn't have overloading, so their names will be distinct.
extern(C):
double foo_double(double);
float foo_float(float);
Now I want to build a D wrapper, and merge them into a single function
with overloading:
T foo(T)
I could write out the two overloads manually:
double foo(double d) { return foo_double(d); }
float foo(float f) { return foo_float(f); }
but this isn't compile time, it will generate a stub function for each
overload, meaning the wrapper will have performance overhead unless
inlining can be guaranteed somehow.
This is the correct answer. It should be inlined, and inlining should work
as long as -inline is passed to the compiler. I don't think there is
another way.
Is it possible to do something like
alias foo = foo_double;
alias foo = foo_float;
Right, you cannot overload aliases as far as I know. foo either refers to
foo_double, or foo_float. You can't bring in those as overloads under the
name foo.
or
template(T) foo {
static if(T is double) {
alias foo = foo_double;
} else {
// etc.
}
}
These doesn't work of course.
This last one looks like it should work. But IFTI ONLY works if you don't
do what you did :) Basically, IFTI cannot see through static if to
determine how to instantiate. It needs to be a clear single function.
For example, how would IFTI figure it out if you did this?
template(T) foo {
static if(T is double) {
alias foo = foo_float;
} else {
// etc.
}
}
It can't figure out what T is without looking at what the alias would be,
but in order to look at the alias, it needs to decide T!
I don't fully understand the template syntax yet, but I have a feeling
this is possible with templates. Is it possible to do what I'm trying to
do?
It seems like it should be possible, but I think we would need a new type
of implicit determination for templates that was not a function template.
-Steve
Re: import except one?
On Sunday, 29 June 2014 at 07:28:12 UTC, Kapps wrote: A bit late, but you should also be able to do: import scriptlike; alias Config = std.process.Config; Thanks, so an alias or an additional single symbol import will shadow the earlier imported symbol. That's fine for me :-)
Re: Redirect to different overloads at compile time?
On Monday, 30 June 2014 at 02:24:10 UTC, David Bregman wrote:
Suppose I have a C library which implements a function for
several types. C doesn't have overloading, so their names will
be distinct.
extern(C):
double foo_double(double);
float foo_float(float);
Now I want to build a D wrapper, and merge them into a single
function with overloading:
T foo(T)
I could write out the two overloads manually:
double foo(double d) { return foo_double(d); }
float foo(float f) { return foo_float(f); }
but this isn't compile time, it will generate a stub function
for each overload, meaning the wrapper will have performance
overhead unless inlining can be guaranteed somehow.
Is it possible to do something like
alias foo = foo_double;
alias foo = foo_float;
In D, you can merge arbitrary overloads by using alias
declaration.
import std.stdio;
extern(C)
{
double foo_double(double a) { writeln(typeof(a).stringof);
return a; }
float foo_float (float a) { writeln(typeof(a).stringof);
return a; }
}
alias foo = foo_double;
alias foo = foo_float;
void main()
{
double d;
float f;
foo(d); // prints double
foo(f); // prints float
}
Kenji Hara
Re: Redirect to different overloads at compile time?
On Monday, 30 June 2014 at 04:50:05 UTC, Kenji Hara wrote: In D, you can merge arbitrary overloads by using alias declaration. Oh wow, you are right. That's a nice feature! I guess I simplified too much for the sake of making the post, the functions I would actually like to merge are function pointers. I assumed it was the same but I was wrong, sorry. double function(double d) foo_double; float function(float f) foo_float; In this case, trying to use alias to merge them causes an error.
Re: Why is the Win32 boilerplate the way it is?
On Sunday, 29 June 2014 at 18:16:05 UTC, Jacob Carlborg wrote: On 2014-06-29 17:06, Jeremy Sorensen wrote: The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? Will you get an error message or just silent failure? Actually, I don't know. You could try some different value. If you search on Google I'm sure you'll find something. Good suggestion, it took me a bit to figure out how to convince Visual-D to do it, but I got it. I am using windows 8.1, so I had to use an as-yet fictitious number but when I did Windows told me it couldn't run the program, which is just perfect behavior.
Re: Why is the Win32 boilerplate the way it is?
On Sunday, 29 June 2014 at 07:51:50 UTC, Jacob Carlborg wrote: You don't need to use WinMain. You can use a plain D main function and add the -L/SUBSYSTEM:WINDOWS:4.0 link flag to suppress the console. There are API's to get access to the arguments passed to WinMain, if necessary. Thanks for your help on this, I couldn't find a way to get the nCmdShow argument, is it safe to assume SW_SHOWNORMAL for starting a new application? So the situation so far is this: 1. You don't need hPrevInstance 2. You can get hInstance via GetModuleHandle(null) (I think that is the best way) 3. [awesome] use main(string[] args) to get your command line arguments exactly like you are used to (except no program name, I tested this) 4. You don't have to worry about the runtime, it is handled automatically 5. You don't have to catch at the top level and put up a message box, this is also done automatically Assuming the nCmdShow thing isn't a problem I see no reason why the wiki should tell people to use WinMain at all.
