Re: How can I express the type of a function in D?
On Wednesday, 30 January 2019 at 06:02:02 UTC, FrankLike wrote:
On Wednesday, 30 January 2019 at 05:40:50 UTC, FrankLike wrote:
On Wednesday, 30 January 2019 at 05:14:20 UTC, Sobaya wrote:
[...]
import std.stdio;
import std.process:executeShell;
import core.demangle;
void main()
{
assert(mangle!(int function(int))("a.b") == "_D1a1bPFiZi");
executeShell("pause");
}
CODE END//
Yes,"_D1a1bPFiZi",which includes "P".
I want a mangled function name without "P", not one with "P".
Re: How can I express the type of a function in D?
On Wednesday, 30 January 2019 at 05:40:50 UTC, FrankLike wrote:
On Wednesday, 30 January 2019 at 05:14:20 UTC, Sobaya wrote:
I want to get a mangled name of a D function by
`core.demangle.mangle`, but I'm in trouble because there are
no ways to express a type of a function, which is used for a
template argument of `mangle`.
For example, it is wrong to use the type `int
function(int,int)` to express the type of `int add(int,int)`.
Because it expresses the type of a function POINTER, not just
a function.
The fuction name in a binary compiled this function is
"_D3addFiiZi", but `mangle!(int function(int,int))("add")`
returns "_D3addPFiiZi", which includes "P" meaning POINTER.
How can I get the former one?
Thanks.
import std.stdio;
import std.process:executeShell;
import core.demangle;
void main()
{
assert(mangle!(int function(int))("a.b") == "_D1a1bPFiZi");
executeShell("pause");
}
CODE END//
Yes,"_D1a1bPFiZi",which includes "P".
Re: How can I express the type of a function in D?
On Wednesday, 30 January 2019 at 05:14:20 UTC, Sobaya wrote:
I want to get a mangled name of a D function by
`core.demangle.mangle`, but I'm in trouble because there are no
ways to express a type of a function, which is used for a
template argument of `mangle`.
For example, it is wrong to use the type `int
function(int,int)` to express the type of `int add(int,int)`.
Because it expresses the type of a function POINTER, not just a
function.
The fuction name in a binary compiled this function is
"_D3addFiiZi", but `mangle!(int function(int,int))("add")`
returns "_D3addPFiiZi", which includes "P" meaning POINTER.
How can I get the former one?
Thanks.
import std.stdio;
alias int* PINT;
void main()
{
auto x= Add(1,2);
writeln(x);
writeln(&x);
executeShell("pause");
}
private PINT Add(int a,int b)
{
return cast(PINT)(a+b);
}
CODE END//
It works ok.
How can I express the type of a function in D?
I want to get a mangled name of a D function by
`core.demangle.mangle`, but I'm in trouble because there are no
ways to express a type of a function, which is used for a
template argument of `mangle`.
For example, it is wrong to use the type `int function(int,int)`
to express the type of `int add(int,int)`.
Because it expresses the type of a function POINTER, not just a
function.
The fuction name in a binary compiled this function is
"_D3addFiiZi", but `mangle!(int function(int,int))("add")`
returns "_D3addPFiiZi", which includes "P" meaning POINTER.
How can I get the former one?
Thanks.
Re: Implement Interface Using Super
On Wednesday, 30 January 2019 at 01:02:37 UTC, Jonathan M Davis
wrote:
Yeah. It would be like trying to do something like
alias x = this.x;
As it stands, I believe that super is always either used as a
function call to the constructor or to mean the this pointer
for the base class. I don't think that it ever means the type
of the base class - just like this never means the type of the
current class or struct. And their usage is pretty much
identical. They're both either used for calling a constructor
or for accessing the pointer/reference of the object. It's just
that one of them is for the current class or struct, whereas
the other is for a base class of the current class. The only
difference in syntax that I can think of between them at the
moment is that this is also used to name constructors when
they're declared, whereas super is not used in that sort of way
(since any constructor that would be referenced by super would
be declared with this, not super).
- Jonathan M Davis
Current, you *can* use `super` to mean the type of the base
class, but it's been deprecated in a recent release (IIRC):
class Super
{
}
class Sub
{
super test()
{
return new Super();
}
}
void main()
{
(new Sub()).test();
}
From DPaste:
Up to 2.080.1: Success and no output
Since 2.081.2: Success with output: onlineapp.d(7):
Deprecation: Using `super` as a type is deprecated. Use
`typeof(super)` instead
Re: Implement Interface Using Super
On Monday, January 28, 2019 10:41:55 PM MST Meta via Digitalmars-d-learn wrote: > On Monday, 28 January 2019 at 22:17:56 UTC, Steven Schveighoffer > > wrote: > > On 1/28/19 3:28 PM, Jonathan Levi wrote: > >> On Sunday, 27 January 2019 at 09:31:46 UTC, bauss wrote: > >>> On Sunday, 27 January 2019 at 05:37:57 UTC, Jonathan Levi > >>> > >>> wrote: > This works in LDC *but not* DMD? > . . . > Is this a bug in DMD *or* in LDC? > >>> > >>> There is no bug here. > >> > >> So... LDC is the one that is bugged? > > > > Yeah, that's odd. It should be the same result, as they both > > have the same semantics for the front end. > > > > I'll defer to an LDC developer to answer that, but in truth, it > > really should be the way LDC implements it, even if that's not > > how the language spec is. > > > >> I think it would have been nice to have a way of explicitly > >> use the super method to implement an interface without having > >> to rewrite the whole signature. I thought I remember seeing a > >> way once, but I must have been dreaming. > > > > I agree. > > > > BTW, the typeof(super) requirement is super-annoying. alias x = > > super.x; is clear, I don't see why we need to specify > > typeof(super) in this context at least. > > > > -Steev > > It's because aliases do not support context pointers, I'm pretty > sure. Yeah. It would be like trying to do something like alias x = this.x; As it stands, I believe that super is always either used as a function call to the constructor or to mean the this pointer for the base class. I don't think that it ever means the type of the base class - just like this never means the type of the current class or struct. And their usage is pretty much identical. They're both either used for calling a constructor or for accessing the pointer/reference of the object. It's just that one of them is for the current class or struct, whereas the other is for a base class of the current class. The only difference in syntax that I can think of between them at the moment is that this is also used to name constructors when they're declared, whereas super is not used in that sort of way (since any constructor that would be referenced by super would be declared with this, not super). - Jonathan M Davis
Re: Should I prefix package names with the name of my program?
Am 28.01.19 um 18:29 schrieb H. S. Teoh: > On Mon, Jan 28, 2019 at 04:59:22PM +, Victor Porton via > Digitalmars-d-learn wrote: >> Should I prefix all module names with `xmlboiler.` (where XML Boiler >> is the name of my program). These packages are expected to be used >> internally by my program, not as an exported API (however there are >> some little chances that in the future I will make a public API) > > I won't pretend to speak for anyone else, but personally, I don't even > bother with packages until my code has grown past a certain size. It's > just useless cruft and needless complexity for small to medium sized > projects. It's only when you're planning to export a public API, or when > your code has grown past a certain size, that it becomes useful to > segregate the code into different packages. > > So IMO you don't need to bother. You can always refactor the code later > to have a package name when you make a public API. > > > T > This is basically the same thing I do: Start with toplevel modules and reorder them into packages once things get more complicated. Mostly I only include a top level package named like my project when writing a project which might be used by other projects (i.e. library code). So far this has worked very well for me. If you expect name clashes with other modules you import, prefixing your own modules with a top level package is a valid solution.
Re: Vibed + OpenSSL on Windows 10?
On Tuesday, 29 January 2019 at 10:12:30 UTC, Suliman wrote: On Tuesday, 29 January 2019 at 10:06:43 UTC, Suliman wrote: On Tuesday, 29 January 2019 at 10:01:04 UTC, Suliman wrote: Always compile vibe.d with mscoff Could you show command to compile with mscoff? I am not sure that all works fine, but at last I do not have linking error. I have add to dub.sdl ext string: "dflags-windows-x86": ["-m32mscoff"] Sorry, it was my mistake. I complied another project. Nothing do not working correct string is: dflags-windows-x86 "-m32mscoff" But I got again linking problem. Another way is just doing: dub -a=x86_mscoff But uhmm not sure about the linking error. I will try locally later and see if I can reproduce it.
Re: Vibed + OpenSSL on Windows 10?
On Tuesday, 29 January 2019 at 10:06:43 UTC, Suliman wrote: On Tuesday, 29 January 2019 at 10:01:04 UTC, Suliman wrote: Always compile vibe.d with mscoff Could you show command to compile with mscoff? I am not sure that all works fine, but at last I do not have linking error. I have add to dub.sdl ext string: "dflags-windows-x86": ["-m32mscoff"] Sorry, it was my mistake. I complied another project. Nothing do not working correct string is: dflags-windows-x86 "-m32mscoff" But I got again linking problem.
Re: Vibed + OpenSSL on Windows 10?
On Tuesday, 29 January 2019 at 10:06:43 UTC, Suliman wrote: On Tuesday, 29 January 2019 at 10:01:04 UTC, Suliman wrote: Always compile vibe.d with mscoff Could you show command to compile with mscoff? I am not sure that all works fine, but at last I do not have linking error. I have add to dub.sdl ext string: "dflags-windows-x86": ["-m32mscoff"] Also you set the default architecture for dub as described here: https://dub.pm/settings.html Kind regards Andre
Re: Vibed + OpenSSL on Windows 10?
On Tuesday, 29 January 2019 at 10:01:04 UTC, Suliman wrote: Always compile vibe.d with mscoff Could you show command to compile with mscoff? I am not sure that all works fine, but at last I do not have linking error. I have add to dub.sdl ext string: "dflags-windows-x86": ["-m32mscoff"]
Re: Vibed + OpenSSL on Windows 10?
Always compile vibe.d with mscoff Could you show command to compile with mscoff?
Re: Vibed + OpenSSL on Windows 10?
On Tuesday, 29 January 2019 at 06:48:38 UTC, Suliman wrote: Does anybody have success with using vibed 0.8.4 with OpenSSL 1.0/1.1 on Windows? I tried all possible solutions without any result. I am getting linking error: Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _TLS_server_method C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _TLS_client_method C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _BN_get_rfc3526_prime_2048 C:\Users\bubnenkov\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\tls\.dub\build\openssl-release-windows-x86-dmd_2084-F1EDC8E792A20905C7802AF7FD58830B\vibe-d_tls.lib(openssl) Error 42: Symbol Undefined _OPENSSL_init_ssl Error: linker exited with status 4 Always compile vibe.d with mscoff Not sure if that has anything to do with this linking error though. I use vibe.d exclusively on Windows though and have had no problems.
Re: Ordered set container?
On Monday, 28 January 2019 at 17:18:52 UTC, Victor Porton wrote: I want "ordered set" container (like list or vector but with the warranty of no duplicate elements). The above answers are ordered, but if you want a type that's a simple sorted array, there's none at the standard library besides SortedRange, which you can't add to. (Mostly for a good reason, because adding elements to such an array after the initial sorting would be very slow). https://github.com/nordlow/justd/blob/master/stdx/container/sorted.d contains an implementation of such an array, but one cannot currently use it legally, because it is not licensed. I don't know if the author did that intentionally (Nordlöw, are you around?)
