Re: Runtime heterogeneous collections?
On Thursday, January 17, 2019 1:21:41 AM MST Dukc via Digitalmars-d-learn wrote: > On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh > > wrote: > > 1. Make a wrapper class. Now you can store Object[], or you can > > make a > > base class or base interface and use that. > > 2. Use Variant, which can wrap anything, or the related > > Algebraic, which > > can wrap a fixed collection of types. > > 3. Use an union. However, only do this if you always know from > outside what type of data is stored in each node. If you need to > memoize the type of data for each node, better resort to 1. or 2. Variant types are really just user-friendly wrappers around unions. So, pedantically, using a variant type such as Variant or Albegbraic and using a union are fundamentally the same thing, though obviously, the actual usage in terms of the code that you write is not the same, since if you use a union directly, you have to deal with the union directly (including figuring out how to know which type the union currently holds), whereas with a Variant, you're using its API rather than dealing with the union directly. In general, it's probably better to use Variant rather than union simply because Variant deals with the type safety for you. - Jonathan M Davis
Re: Alternative to Interfaces
On Friday, 18 January 2019 at 01:00:33 UTC, H. S. Teoh wrote: Maybe you could help us answer your question better by explaining a bit more what you're trying to achieve. Generally, if you want to use an interface, that usually means you want (1) runtime polymorphism, i.e., the ability to swap one concrete implementation for another at runtime, and (2) pass around possibly different concrete objects to code that expects objects of a single type (the interface type). I do apologize for my vagueness. In hindsight, it was quite a poor way to request for help. Anyway, for my current use case, the latter's functionality is what I am attempting to replicate. If the reason you're using structs is just to avoid the GC, then you should look up emplace() in the docs. It *is* possible to use classes without using the GC. Just in case you didn't know. Thank you for informing me of this. I didn't know. So from a cursory glance it would seem that I would, omitting details, make a wrapper function that combines an allocator (e.g. malloc) and emplace. (Though you should also keep in mind the possible drawbacks of template bloat -- which may cause more instruction cache misses by making your code larger than it could have been.) Yes, this is something I worried about too. My personal tendency is to start with structs and compile-time introspection as an initial stab, but depending on what might be needed, I may use some classes / interfaces. The two can be combined to some extent -- e.g., a template function can take both structs with compile-time introspection and also classes that allow runtime polymorphism. A template function instantiated with a class type will be able to accept different concrete objects at runtime (as long as they are subclasses of that type). However, it will only be able to "see" the static info of the class it was instantiated with, not any additional features of derived classes that it may receive at runtime, since there will be no runtime introspection. Initially, I was going to use Classes when I needed to use Interfaces and use Structs for everything else, but I decided against that because I was worried it would make the program's structure "inconsistent," for the lack of a better word, and again the GC. Though AFAIK, delegates probably still need heap allocation and depend on the GC, esp. if you have closures over local variables. There may be some cases where the compiler will elide this, e.g., if you have a function literal passed via an alias that does not escape the caller's scope. OTOH, you might be able to get around needing the GC if you put your delegates in an emplace()'d class as methods, and take their address (which produces a delegate). Just make sure your class doesn't go out of scope while the resulting delegates are still around. Keep in mind that in this case, you will not be able to have closure over local variables (delegates can only have 1 context pointer, and in this case it's already used up by the `this` reference) and will have to store any such contextual information inside the class itself. With regards to the emplaced class, this is interesting. My main use for the delegate was in achieving one of the effects of interfaces for Structs, so I don't think I'll be using them as much. I'll have to pay close attention to the profiler in any case. With the information you gave me, I think I'll try Class & emplace as I really don't want to attempt replicate existing functionality--especially so considering my experience level. With thanks, 1001Days
Re: Alternative to Interfaces
On Fri, Jan 18, 2019 at 12:08:00AM +, 1001Days via Digitalmars-d-learn wrote: > Hello, > > Preface: I do apologize if this is too simplistic of a matter, and if > I need to RTFM. I'm quite slow. > > I want to use Structs instead of Classes, but I don't want to lose the > abilities of Interfaces. So instead I used a combination of templates, > constraints, the hasMember trait, and delegates to achieve a simple > alternative. Maybe you could help us answer your question better by explaining a bit more what you're trying to achieve. Generally, if you want to use an interface, that usually means you want (1) runtime polymorphism, i.e., the ability to swap one concrete implementation for another at runtime, and (2) pass around possibly different concrete objects to code that expects objects of a single type (the interface type). So the first question is, do you need runtime polymorphism? Do you need to pass objects of different types to functions that only take a single type? Do you need the ability to change *at runtime* the type of object passed to a function? If so, you probably should stick with interfaces and classes. While it *is* possible to achieve equivalent functionality with structs and templates, you'll basically end up reinventing classes, possibly poorly, and spending coding / debugging time doing so when you could have just used the built-in construct. If the reason you're using structs is just to avoid the GC, then you should look up emplace() in the docs. It *is* possible to use classes without using the GC. Just in case you didn't know. OTOH, if you don't need runtime polymorphism, then using classes and templates would be the "more idiomatic" way to do it. (Though you should also keep in mind the possible drawbacks of template bloat -- which may cause more instruction cache misses by making your code larger than it could have been.) > It works, but I have two questions regarding its efficacy: is it > viable in the long run, and is it now possible to use delegates > without the GC? The latter is of particular importance as I'm using > Structs for compatibility. [...] Whether or not it's viable really depends on whether you need runtime polymorphism, and what you're trying to accomplish. My personal tendency is to start with structs and compile-time introspection as an initial stab, but depending on what might be needed, I may use some classes / interfaces. The two can be combined to some extent -- e.g., a template function can take both structs with compile-time introspection and also classes that allow runtime polymorphism. A template function instantiated with a class type will be able to accept different concrete objects at runtime (as long as they are subclasses of that type). However, it will only be able to "see" the static info of the class it was instantiated with, not any additional features of derived classes that it may receive at runtime, since there will be no runtime introspection. Though AFAIK, delegates probably still need heap allocation and depend on the GC, esp. if you have closures over local variables. There may be some cases where the compiler will elide this, e.g., if you have a function literal passed via an alias that does not escape the caller's scope. OTOH, you might be able to get around needing the GC if you put your delegates in an emplace()'d class as methods, and take their address (which produces a delegate). Just make sure your class doesn't go out of scope while the resulting delegates are still around. Keep in mind that in this case, you will not be able to have closure over local variables (delegates can only have 1 context pointer, and in this case it's already used up by the `this` reference) and will have to store any such contextual information inside the class itself. T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Alternative to Interfaces
Hello, Preface: I do apologize if this is too simplistic of a matter, and if I need to RTFM. I'm quite slow. I want to use Structs instead of Classes, but I don't want to lose the abilities of Interfaces. So instead I used a combination of templates, constraints, the hasMember trait, and delegates to achieve a simple alternative. It works, but I have two questions regarding its efficacy: is it viable in the long run, and is it now possible to use delegates without the GC? The latter is of particular importance as I'm using Structs for compatibility. With thanks, 1001Days
Re: problem extracting data from GtkSourceView using Gtkd
I think I finally figured it out. I think the GTKapplication shutdown signal is called after the window has been destroyed. If I attach a handler to the window's destroy signal, then I am able to get the data from the sourceView.
Re: problem extracting data from GtkSourceView using Gtkd
On 17-01-2019 00:31, Chris Bare wrote: Are the widgets destroyed before onShutdown? The onShutdown callback is run after the GTK main loop terminates, so most objects would be finalized. -- Mike Wey
Re: beginner's linking error
On Thursday, 17 January 2019 at 12:38:55 UTC, Adam D. Ruppe wrote: You need to pass all the modules you use to the compiler, or compile each one at a time and pass the resultant .o files to the linker together. Marvellous, thanks! (Okay, it was a naive beginner's question. But I can't help thinking that there's a bit of a hole in the documentation shaped around this.)
Re: How to include curl.lib?
On Thursday, 17 January 2019 at 20:05:27 UTC, Head Scratcher wrote: On Monday, 14 January 2019 at 18:45:27 UTC, Head Scratcher wrote: The following text is in the source code for curl.d: Windows x86 note: A DMD compatible libcurl static library can be downloaded from the dlang.org $(LINK2 http://downloads.dlang.org/other/index.html, download archive page). I downloaded that static library. How do I link it into my D project? Is it something I can put into dub.json? It would be nice to compile my app into one EXE file including std.curl and curl.lib. Does nobody know how to do this? You do not need to specify curl.lib but you have to bundle your executable with curl.dll. Recent Windows 10 versions might even come with curl.dll but I am not 100% sure. Kind regards Andre
Re: How to include curl.lib?
On Monday, 14 January 2019 at 18:45:27 UTC, Head Scratcher wrote: The following text is in the source code for curl.d: Windows x86 note: A DMD compatible libcurl static library can be downloaded from the dlang.org $(LINK2 http://downloads.dlang.org/other/index.html, download archive page). I downloaded that static library. How do I link it into my D project? Is it something I can put into dub.json? It would be nice to compile my app into one EXE file including std.curl and curl.lib. Does nobody know how to do this?
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 16:55:33 UTC, SrMordred wrote:
Yes, but there is a mistake there:
alias is part of the template:
foo(alias x)(){} //note extra parens
than u call like an template:
foo!"a"; //equivalent = foo!("a")();
foo!1;
I see now and thanks.
Matheus.
Re: What is the Utility of Parent Class Method Hiding in Inheritance?
On 1/16/19 12:25 PM, Neia Neutuladh wrote: On Wed, 16 Jan 2019 12:01:06 -0500, Steven Schveighoffer wrote: It was 2.068 that removed the HiddenFuncError, and made this a compile error instead. If your compiler is that or newer, definitely file a bug report. Oh god, that must have been awful. I'm glad we're no longer in those benighted times. I will never forget those times! This subject was actually my first reason for posting to the forums :) https://forum.dlang.org/post/f8qrgg$12q8$1...@digitalmars.com Good times... -Steve
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
[...]
auto window = Window();
window.title = "My Window";
window.width = 1000;
window.create();
[...]
Is there a better way that's not ugly?
[...]
//usage:
auto a = NewWindow!q{ title : "MainTitle" };
auto b = NewWindow!q{ title : "MainTitle", width : 800 };
auto c = NewWindow!q{ width : 1000 };
auto d = NewWindow!q{};
:)
Put a semicolon instead of the comma in the line "auto b ..." and
compile.
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 12:11:02 UTC, Matheus wrote:
foo(alias x){}
foo("a");
foo(1);
'x' will be string one time and integer another? Or there is
something that I'm missing.
Matheus.
Yes, but there is a mistake there:
alias is part of the template:
foo(alias x)(){} //note extra parens
than u call like an template:
foo!"a"; //equivalent = foo!("a")();
foo!1;
Re: beginner's linking error
On Thursday, 17 January 2019 at 10:38:50 UTC, James Cranch wrote: An attempt to compile it looks as follows: | $ gdc executable.d -o executable You need to pass all the modules you use to the compiler, or compile each one at a time and pass the resultant .o files to the linker together. | /tmp/cc4RjTlb.o:(.data.rel+0x10): undefined reference to `_D7library12__ModuleInfoZ' This just means the library module was missing from the final link. (if you remove the other call from it, it made the library do nothing and thus the compiler didn't even actually emit the call to it). But try just gdc executable.d -o executable library.d so both .d files are on the list. That's the easiest and fastest way to make ti work.
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
Let me throw this idea here:
...
I usually do this too, I like to use struct and then in another
language I use reflection do optimize binding.
Anyway I understood all your code, except for this "alias code"
auto NewWindow( alias code )()
{
mixin("Config config = {"~code~"};");
return Window(config);
}
Looking on specs: https://dlang.org/spec/declaration.html#alias
"AliasDeclarations create a symbol that is an alias for another
type, and can be used anywhere that other type may appear."
So with your example imagine this:
foo(alias x){}
foo("a");
foo(1);
'x' will be string one time and integer another? Or there is
something that I'm missing.
Matheus.
Re: Is there a nice syntax to achieve optional named parameters?
On Thu, Jan 17, 2019 at 10:29:13AM +, John Burton via Digitalmars-d-learn wrote: [...] > Well window was just an example really, my real use case is a similar > object that needs a lot of configuration where mostly the default > works but you might want to override, and the config is needed to > create the object in the first place. [...] When I encounter similar situations in my code, my go-to solution is to use a struct with default field values as a configuration object that you pass to the ctor. You can either pass .init to the ctor to get default behavior, or declare an instance of the struct and customize as you see fit before handing it to the ctor. --T
beginner's linking error
Hi all,
I've just installed gdc from Debian Stable (gdc (Debian
6.3.0-18+deb9u1) 6.3.0 20170516), and have been having linker
errors when using writeln.
A minimal nonworking example is as follows: I have a file
library.d which contains the following:
| module library;
|
| import std.stdio;
|
| class Greeter(string s) {
|
| this() { }
|
| void say_hello() {
| writeln("Hello ", s, "!");
| }
| }
I also have a file executable.d which contains the following:
| module executable;
| import library;
|
| int main() {
|
| alias G = Greeter!("James");
| G a = new G();
| a.say_hello();
| return 0;
| }
An attempt to compile it looks as follows:
| $ gdc executable.d -o executable
| /tmp/cc4RjTlb.o:(.data.rel+0x10): undefined reference to
`_D7library12__ModuleInfoZ'
| collect2: error: ld returned 1 exit status
If I remove the import std.stdio and the writeln command from
library.d, then it all works, so I'm clearly not linking
libraries right, but it's not clear to me what to do.
Re: Is there a nice syntax to achieve optional named parameters?
On Wednesday, 16 January 2019 at 14:59:01 UTC, Kagamin wrote:> On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote: auto window = Window(title = "My Window", width = 1000, fullscreen = true); In this particular case I would make the constructor take 3 parameters - title, width and height. Full screen is a rare functionality and shouldn't clutter the constructor, can it be set after the window is created? Well window was just an example really, my real use case is a similar object that needs a lot of configuration where mostly the default works but you might want to override, and the config is needed to create the object in the first place. For this example you are right though, and it may be that I'm overthinking the whole thing.
Re: Is there a nice syntax to achieve optional named parameters?
On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
[...]
Let me throw this idea here:
struct Config
{
string title;
int width;
}
struct Window
{
this(Config config)
{
//use static foreach magic to set everything :P
}
}
auto NewWindow( alias code )()
{
mixin("Config config = {"~code~"};");
return Window(config);
}
//usage:
auto a = NewWindow!q{ title : "MainTitle" };
auto b = NewWindow!q{ title : "MainTitle", width : 800 };
auto c = NewWindow!q{ width : 1000 };
auto d = NewWindow!q{};
:)
Oh that's interesting!
Re: Runtime heterogeneous collections?
On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: On Thu, 17 Jan 2019 02:21:21 +, Steven O wrote: I want to create a heterogeneous collection of red-black trees, and I can't seem to figure out if it's possible. RedBlackTree!int and RedBlackTree!string are entirely different types (they just happen to be generated from the same template). There are two reasonable ways of doing things: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface and use that. 2. Use Variant, which can wrap anything, or the related Algebraic, which can wrap a fixed collection of types. You can use this technique either with the collection types themselves or with the value types. As the OP is most likely looking for Variant, let me link to it: https://dlang.org/phobos/std_variant.html#Variant
Re: Runtime heterogeneous collections?
On Thursday, 17 January 2019 at 02:27:20 UTC, Neia Neutuladh wrote: 1. Make a wrapper class. Now you can store Object[], or you can make a base class or base interface and use that. 2. Use Variant, which can wrap anything, or the related Algebraic, which can wrap a fixed collection of types. 3. Use an union. However, only do this if you always know from outside what type of data is stored in each node. If you need to memoize the type of data for each node, better resort to 1. or 2.
