Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote: I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead? Note: I don't have a problem with giving away my code. I just want to know if it can be done. Or maybe later build a plugin system where the creator of the plugin does not need the source of the entire application. And in turn the app does not need to be recompiled in order to use the plugin. DLLs also have nothing to do with compilation. That's a runtime thing. D is not like Java, where everything you need is bundled in an archive and can be used at both compile time and runtime. It's more like C and C++, where there are very distinct formats in use and compile time and runtime. The compiler needs to know which symbols are available for you to use in your module. It can only get them from the source for the modules you import, not from any static libraries or DLLs. D does support interface files (called 'D Interface' files, with a .di extension). These are stripped down versions of your source code that can be shipped with your binary. Instead of having full function implementations, you have the declarations only. This means that none of those functions can be inlined. And you still need the full implementation of any templates in the library, otherwise the templates can't be instantiated. .di files are more like C and C++ header files. You can generate them from any D source file by passing -H on the command line during compilation. The primary benefit of .di files is to hide the source. Since you say you don't care about that, you probably shouldn't worry about them. Really, if you are using DUB to manage your projects and don't care about hiding the source, then there's nothing to worry about. You can put your libraries on github or BitBucket, register them with the DUB registry at code.dlang.org, and then everyone who uses them as dependencies will have everything they need automatically. You could also bundle them up in zip files and distribute them that way. People can run dub to compile the libraries and then configure their project locally to find what they need. It isn't a problem at all.
Re: Using .lib and .dll in D applications
On 2016-06-20 06:33, moe wrote: I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead? for this purpose there are .di interface files that can be generated automatically: https://dlang.org/dmd-windows.html#interface-files
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:
On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
Unfortunatelly I still don't get it. I would like to have an
independant project "dbar". The created lib is then used in
another project "dfoo". Assuming that "dfoo" has no access to
"dbar" other than the .lib file.
You can't do it with only the lib file. You *need* the source
file too for the import statement. As I explained, the lib
file is used by the linker, not the compiler. The compiler
needs the source file.
My folder structure is like this:
-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.
-dtest
--dfoo
lib\dbar.d // copied from the dbar project
source\app.d
dub.json
You don't need to copy dbar to the lib directory in this case.
This project would use the dbar.lib but should otherwise not
have access to the dbar project. Basically simulating, that
someone else made a dbar project to which I would not have
access other than using the dbar.lib. How do I have to
configure the dub.json file for this to work?
One of two things would happen:
1) They would register the project with he dub registry, then
you add a dependency to a specific version the library. Dub
would then download the necessary files for you and ensure
that everything you need is passed to the compiler when
building your project.
2) They would provide some other means for you to get the
source and the library. Then you would need to manually
configure your dub.json to pass the import path to the
compiler and link with the library.
I have tried a variety of configurations for the dub.json. At
this point it feels like a bad guessing game. That is no way
to deveop anything. I need to figure out how to properly
setup the dub.json but I don't seam to find the answer
online. "http://code.dlang.org/package-format?lang=json;
isn't very helpful.
All the information you need is there on that page.
I have meanwhile adjusted my dtest/dfoo/dub.json to this:
"dependencies": {
"dbar": "~master"
}
This gives me the error: "Root package dfoo references
unknown package dear"
As I explained above, you need a path attribute for the
dependency in this case since it is on your local file system
and not in the registry. The documentation link I gave you
explains how to to this. Try this:
"dependencies": {
"dbar": {"path": "../dbar"}
}
I see where I went wrong. I thought that it's possible to only
use the .lib file without the source code of dbar. Having
access to the source makes what I am trying somewhat pointless.
Is it otherwise possible to provide some functionality without
having to give away your source? I would like to put together a
library that I can reuse, without having to rely on the source
each time. Maybe a dll instead?
Note: I don't have a problem with giving away my code. I just
want to know if it can be done. Or maybe later build a plugin
system where the creator of the plugin does not need the source
of the entire application. And in turn the app does not need to
be recompiled in order to use the plugin.
Thanks for your help!
Sure, you can just have a file with "extern" functions that tells
the compiler that the source for those functions isn't available
at compile time, but that later on when you link the library, the
linker will find those function definitions in the .lib file (I'm
not a Windows expert, but from my understanding .DLLs are a
different ball game, and have to be loaded and called with
special functions in your app.)
In your example, in your "dfoo.d", you can declare the functions
from the dbar.lib inside as "extern myfunction();" and the
compiler will say, "OK, myfunction() isn't defined here, so we'll
let the linker sort it out." If you try and compile without
telling it about dbar.lib, you'll get errors like "undefined
reference to myfunction()...".
When you see that somebody wrote a "binding" in D for a library
like OpenGL, etc., this is what they are providing, a .d file
filled with "extern" definitions and maybe some glue code to
convert D types into C types if the .lib file is a C library.
APIs generally work the same way. Library writers will provide a
.h header file that doesn't expose any of their closed source,
but gives users of the library the definitions of the functions
they need to use it's functions.
I hope this helps!
-Jon
Re: What exactly does the compiler switch -betterC do?
On Sunday, 19 June 2016 at 19:53:46 UTC, Gary Willoughby wrote: When compiling, what exactly does the -betterC flag do? The command help says "omit generating some runtime information and helper functions" but what does this really mean? Is there any specifics somewhere? My understanding was that -betterC was not fully implemented yet, due mostly to tight compiler integration with the runtime. (old info?) I'm not super smart on the DMD source, but it looks like betterC prevents genhelpers() and genModuleInfo() from being called, with "helpers" appearing to be array checking, asserts and unit tests. A comparison of object files compiled with and without the flags shows just a small reduction in the size of the code, but grepping for bounds checking, unit tests and ModuleInfo in the -betterC generated object file shows they are missing. Hope this helps, -Jon
Re: D casting broke?
On Sunday, 19 June 2016 at 23:00:03 UTC, ag0aep6g wrote:
On 06/19/2016 11:19 PM, Joerg Joergonson wrote:
On Sunday, 19 June 2016 at 20:21:35 UTC, ag0aep6g wrote:
[...]
No. B!b is derived from A!b, not from A!a. `b` being derived
from `a`
does not make A!b derived from A!a.
why not? This doesn't seem logical!
Template parameters simply don't work like that. A template can
result in completely unrelated types based on template
parameters.
For example:
template C(T)
{
static if (is(T == A)) class C {}
else static if(is(T == B)) alias C = int;
else struct C {int x;}
}
As you see there can't be any inheritance relation between the
different instantiations of the C template here. Having such a
relation for different instantiation that result in classes
would be a weird special case.
There's probably a really simple and obvious reason why that
special would be a bad idea in itself, but I'm not able to
point it out. Maybe make a thread in the General group. I think
the language people tend to focus their attention there.
Criticism and improvement proposals are also better directed to
the General group.
Here is the full inheritance tree:
X
├─x
│ └─a
│ └─b
├─A!a
└─A!b
└─B!b
But b is derived from a.
Yeah, that's right there in the middle.
Your tree completely ignores under A.
Clearly, there's B!b under A!b. That's it. Nothing exists below
B!b. B!a doesn't exist either. A!a is on a different branch. I
don't think I've missed anything.
[...]
Just because D doesn't understand this logical consistency
between
inheritance doesn't mean D is right. (Hence, why D's type
system is broke)
In fact, the tree should look like this:
X
├─x
│ └─a
│ └─b
└─A!x
│ \
└─A!a
│ \
└─A!b
│ \
└─B!b
I'm having trouble reading this. A!x isn't valid, as the
constraint on A says `T : a`, but x doesn't satisfy that.
no, my point was that a is derived from x, b from a, hence we
have a derivation change x -> a -> b. So, similarly A!x -> A!a ->
A!b
I also don't understand what the backslashes mean. They just
repeat the other lines, don't they? Or do they connect x, a,
and b? That's already expressed in the upper section.
Yes, they connect them. Yes, exactly, But this time they connect
in terms of A. The compiler doesn't seem to use the fact that x
-> a -> -> b to infer anything about A!x -> A!a -> A!b, and it
should.
As for A!b being below A!a, I can only repeat that this
inheritance is not implied. You would have to spell it out
explicitly for the compiler to pick it up.
Maybe so. But that is kinda my point.
Basically you are treating A!a and A!b as if a and be have no
relationship. BUT THEY DO!
Well, to the compiler they don't.
Yes, exactly.
basically I am doing a cast(A!a)this because all I care about is
this in terms of A!a. If it's a B!b or B!a or A!b is immaterial
to me since casting to A!a gets me what I need. (It's no
different than if I was doing simpler inheritance) D doesn't
understand this and there is no simple fix that anyone has
presented.
The casting is the only problem and there is no reason it should
fail because the object I am casting on can be cast to it's base
class.
If we assume that I'm wrong or D can't do this because of a bug
or shortsightedness... the issue remains on how to make it work.
public class Button(T : ButtonItem) : Widget { ... }
public class ButtonItem : Item
{
void Do() { auto parent = (cast(Button!ButtonItem)this.Parent); }
...
}
All this works great! As long as Do is not being called from a
derived class
public class Slider(T : SliderItem) : Button!T { }
public class SliderItem : ButtonItem { }
The last two classes are truly empty. Now, when I use a Slider
object, things go to shit because the cast is invalid.
this.Parent is of type Slider!SliderItem.
SliderItem only sets the array type. So in Slider, I end up with
a SliderItem[] type then in ButtonItem's Do(which gets called
since SliderItem doesn't override), it tries to cast that down to
a ButtonItem. It should work. There is no reason it shouldn't
logically. There is no up casting.
If I duplicate Do() and put it in SliderItem and change the cast
to use Slider/SliderItem, it works. The cast is the only problem.
Not the objects themselves.
If this wasn't a parameterized class, everything would work. If I
made Slider use ButtonItems everything would work. It's only
because I derived a new type SldierItem from ButtonItem that
breaks and only at the cast.
I'm almost 100% sure this should work and haven't seen anyone
actually show why this would not work(the examples given are
simply wrong and are not understanding the problem... or there is
more going than anyone has said).
Again, do we not expect derived types to be able to be down cast?
Just because they are parameterized on other types doesn't change
this fact? It just makes it more
Re: Can anybody install DDT on Eclipse Neon or Mars?
On Saturday, 18 June 2016 at 16:46:26 UTC, Mark wrote: I've spent may hours trying to do this in OSX. Everything goes fine from the marketplace window...until I restart Eclipse and find no files have been added? Any words of consolation or advice will be greatly appreciated. Desperately, Mark I have only played around with DDT, and it's been a long time, so I can't offer help. I do not know how many of the developers will see your message here. They have their own user group http://groups.google.com/group/ddt-ide and there is a separate IDE forum http://forum.dlang.org/group/ide where you may have better luck.
Re: Can anybody install DDT on Eclipse Neon or Mars?
On Saturday, 18 June 2016 at 16:46:26 UTC, Mark wrote: I've spent may hours trying to do this in OSX. Everything goes fine from the marketplace window...until I restart Eclipse and find no files have been added? Any words of consolation or advice will be greatly appreciated. I have Eclipse Version: Mars.2 Release (4.5.2) Build id: 20160218-0600 with DDT installed, don't remember any problems, but this is under Ubuntu 14.04. As I remember I didn't use Marketplace window, but follow instructions here: https://github.com/DDT-IDE/DDT/blob/latest/documentation/Installation.md#installation
Re: D casting broke?
On 06/19/2016 11:19 PM, Joerg Joergonson wrote:
On Sunday, 19 June 2016 at 20:21:35 UTC, ag0aep6g wrote:
[...]
No. B!b is derived from A!b, not from A!a. `b` being derived from `a`
does not make A!b derived from A!a.
why not? This doesn't seem logical!
Template parameters simply don't work like that. A template can result
in completely unrelated types based on template parameters.
For example:
template C(T)
{
static if (is(T == A)) class C {}
else static if(is(T == B)) alias C = int;
else struct C {int x;}
}
As you see there can't be any inheritance relation between the different
instantiations of the C template here. Having such a relation for
different instantiation that result in classes would be a weird special
case.
There's probably a really simple and obvious reason why that special
would be a bad idea in itself, but I'm not able to point it out. Maybe
make a thread in the General group. I think the language people tend to
focus their attention there.
Criticism and improvement proposals are also better directed to the
General group.
Here is the full inheritance tree:
X
├─x
│ └─a
│ └─b
├─A!a
└─A!b
└─B!b
But b is derived from a.
Yeah, that's right there in the middle.
Your tree completely ignores under A.
Clearly, there's B!b under A!b. That's it. Nothing exists below B!b. B!a
doesn't exist either. A!a is on a different branch. I don't think I've
missed anything.
[...]
Just because D doesn't understand this logical consistency between
inheritance doesn't mean D is right. (Hence, why D's type system is broke)
In fact, the tree should look like this:
X
├─x
│ └─a
│ └─b
└─A!x
│ \
└─A!a
│ \
└─A!b
│ \
└─B!b
I'm having trouble reading this. A!x isn't valid, as the constraint on A
says `T : a`, but x doesn't satisfy that.
I also don't understand what the backslashes mean. They just repeat the
other lines, don't they? Or do they connect x, a, and b? That's already
expressed in the upper section.
As for A!b being below A!a, I can only repeat that this inheritance is
not implied. You would have to spell it out explicitly for the compiler
to pick it up.
Basically you are treating A!a and A!b as if a and be have no
relationship. BUT THEY DO!
Well, to the compiler they don't.
If you don't take that into account then your
wrong.
Simply stating how D behaves is not proof of why it is right or wrong.
For discussions about how D should behave, please post to General. Here
in the Learn group I (and I think we) tend to focus on how D works or is
meant to work. The way you think it should behave here is not how it's
meant to work by the designers and implementors.
[...]
import std.stdio;
class a { }
class b : a { }
class A(T : a)
{
T x;
}
void main(string[] argv)
{
auto _A = new A!a();
auto _C = new A!b();
auto p = cast(A!a)_C;
}
p is null. My example with B is irrelevant. The issue is with the
parameter.
As you can see, D thinks that A!b and A!a are completely unrelated... as
do you and arsd.
Do you seriously think this is the case? That
class b : a { }
and
class b { }
effectively mean the same with regards to A?
Yes. A!a is a class like this: `class A!a {a x;}`. A!b is this: `class
A!b {b x;}`. The generated classes have members that have an inheritance
relationship, but that doesn't imply an inheritance relationship between
A!a and A!b.
The whole problem comes about at this line:
auto p = cast(A!a)_C;
We are trying to cast `T x` in C, which is effectively `b x` to `a x`.
No. You try to cast from one class type to another, that's different
from casting the members.
You can have two classes with exactly the same members, yet they're not
(directly) castable to each other when there's no inheritance relation:
class A {int x;}
class B {int x;}
void main()
{
assert((cast(B) new A) is null); /* holds */
assert((cast(A) new B) is null); /* holds */
}
Maybe this is the crux? I'd expect you to be of the opinion that those
casts should work.
Of course, you can force an unsafe conversion by casting to void* first:
cast(B) cast(void*) new A
A reinterpret-style cast would also work:
A a = new A;
B b = * cast(B*)
I suppose a simple cast doesn't do that because it's deemed more useful
to get null when the inheritance doesn't work out, even when the member
layout would work out. This way `cast` can be used for downcasts in a
safe manner.
Because, when there is no inheritance relation, that means there is no
guarantee that a class can be used in place of another one, even when
the fields are compatible. Consider A and B having methods with the same
name that do completely unrelated things. Converting accidentally from
one to the other would be bad.
const and mutable opApply's
Hello
struct WTable
{
...
private enum opApply_body = q{
if( smt )
{
foreach( f; 0 .. size-1 )
foreach( t; f+1 .. size )
if( auto r = dlg(f,t,data[getIndex(f,t)]) )
return r;
}
else
{
foreach( f; 0 .. size )
foreach( t; 0 .. size )
{
if( f == t ) continue;
if( auto r = dlg(f,t,data[getIndex(f,t)]) )
return r;
}
}
return 0;
};
int opApply( int delegate(size_t,size_t,T val) dlg ) const {
mixin( opApply_body ); }
int opApply( int delegate(size_t,size_t,ref T val) dlg ) {
mixin( opApply_body ); }
}
How I can rewrite this code without mixin's and with one (maybe
inout) opApply?
Re: D casting broke?
On Sunday, 19 June 2016 at 21:06:43 UTC, Joerg Joergonson wrote: A!b is derived from A!a if b is derived from a, is it not? If not, then I am wrong, if so then D casting has a bug. You are wrong. The array example given by Adam is actually a neat illustration of precisely your question if you just think of `T[]` as `Slice!T`. In other words, `Slice!b` cannot be derived from `Slice!a` automatically, since then you could use the `Slice!a` interface to push `a` instances into your `Slice!b`. If that's a bit too far of a mental leap to make, you can certainly find a more thorough illustration of the concepts at play here by looking up covariance vs. contravariance in containers/generics online. — David
Re: D casting broke?
On Sunday, 19 June 2016 at 20:21:35 UTC, ag0aep6g wrote:
On 06/19/2016 09:59 PM, Joerg Joergonson wrote:
This should be completely valid since B!T' obviously derives
from A!T
directly
ok
and we see that T' derives from b which derives from a
directly.
ok
So B!b is an entirely derived from A!a
No. B!b is derived from A!b, not from A!a. `b` being derived
from `a` does not make A!b derived from A!a.
why not? This doesn't seem logical!
Here is the full inheritance tree:
X
├─x
│ └─a
│ └─b
├─A!a
└─A!b
└─B!b
But b is derived from a. Your tree completely ignores under A.
X
├─x
│ └─a
│ └─b
├─A!a
| \
└─A!b
└─B!b
Just because D doesn't understand this logical consistency
between inheritance doesn't mean D is right. (Hence, why D's type
system is broke)
In fact, the tree should look like this:
X
├─x
│ └─a
│ └─b
└─A!x
│ \
└─A!a
│ \
└─A!b
│ \
└─B!b
Basically you are treating A!a and A!b as if a and be have no
relationship. BUT THEY DO! If you don't take that into account
then your wrong.
Simply stating how D behaves is not proof of why it is right or
wrong.
This is very easy to see, check my other post using a Widget
Example and you will see that it is a logical extension.
D doesn't check parameter inheritance relationships properly. A!b
is a derivation of A!a.
import std.stdio;
class a { }
class b : a { }
class A(T : a)
{
T x;
}
void main(string[] argv)
{
auto _A = new A!a();
auto _C = new A!b();
auto p = cast(A!a)_C;
}
p is null. My example with B is irrelevant. The issue is with the
parameter.
As you can see, D thinks that A!b and A!a are completely
unrelated... as do you and arsd.
Do you seriously think this is the case? That
class b : a { }
and
class b { }
effectively mean the same with regards to A?
The whole problem comes about at this line:
auto p = cast(A!a)_C;
We are trying to cast `T x` in C, which is effectively `b x` to
`a x`.
Is that not possible to do? We do it all the time, right?
That is my point. D doesn't see that it can do this but it can,
if not, prove me wrong.
Re: D casting broke?
On Sunday, 19 June 2016 at 20:18:14 UTC, Adam D. Ruppe wrote:
On Sunday, 19 June 2016 at 19:59:28 UTC, Joerg Joergonson wrote:
This should be completely valid since B!T' obviously derives
from A!T directly and we see that T' derives from b which
derives from a directly. So B!b is an entirely derived from
A!a and hence the cast should be successful
I don't see how you think that. Here's the parent chain:
B!b -> A!b -> X -> x -> Object
There's no A!a in there, the cast is failing correctly.
Just because `b` is a child of `a` doesn't mean that `A!b` is
the same as `A!a`. Consider an array:
MyClass[] arr;
arr ~= new MyClass(); // ok cool
Object[] obj_arr = arr; // won't work! because...
obj_arr[0] = new RandomClass(); // this would compile...
// but obj_arr and arr reference the same data, so now:
arr[0] is typed MyClass... but is actually RandomClass! It'd
crash horribly.
Array is just one example of where converting A!b to A!a is
problematic. The same principle can apply anywhere, so it won't
implicitly cast them.
I'm not saying they are the same! They don't have to be the same.
That is the whole point of inheritance and casting. A!b is
derived from A!a if b is derived from a, is it not? If not, then
I am wrong, if so then D casting has a bug.
The obviously question: Is there a simple way around this?
What are you actually trying to do?
Do you really want to know? It's very simple and logical and
might blow your mind and show you it's more complex than the
example you have
I have a widget class
class Widget { Widget Parent; }
I have a button item class
class ButtonItem : Widget;
I have a button class
class Button : Widget { ButtonItem[] items; }
Make sense so far? Very logical and all that?
NOW, suppose I want to create a derived type from button? Say, a
slider that effectively is a button that can move around:
class Slider : Button { }
So far so good, right?
WRONG! Slider shouldn't contain button items but slider items!
How to get around this?
class SliderItem : ButtonItem; (since sliders are buttons slider
items should be button items, right?)
So, to make this work we have to parameterize Button.
class Button(T : ButtonItem) : Widget { T[] items; }
So far so good!
and
class SliderItem : ButtonItem;
Very logical, Spock would be proud!
Now
class Slider(T : SliderItem) : Button!T;
Very logical still, right? Because T is of type SliderItem which
is of type ButtonItem and therefor Button!SliderItem is of type
Button!ButtonItem.
Everything works, right? Of course, I have a working example!
Slider!T is a type of Button!T, Slider!SliderItem is a type of
Button!ButtonItem. Surely items in Button can hold SliderItems?
(since they are derived from ButtonItems and ButtonItems work)
Ok, everything works!
Now what?
Well, In ButtonItem, I have to get the parent items to do some
work. i.e.,
Work(Parent.items);
But this can't work because Parent is a Widget, so we must cast
to a Button.
Work((cast(Button)Parent).items);
But this doesn't work because Button is parameterized. so
Work((cast(Button!T)Parent).items);
But this doesn't work because there is no T in ButtonItem, which
is were we are at, so lets cast to a ButtonItem.
Work((cast(Button!ButtonItem)Parent).items);
This works!! At least as long as we are in ButtonItems!
When our parent is a Slider then the cast fails and everything
goes to shit.
I have to duplicate the code AND only change the cast to
cast(Slider!SliderItem)Parent and then everything works.
But, you might think that Slider!SliderItem is somehow not
derived from Button!ButtonItem but it is, it was created to be
that way by god himself.
Widget -> Button -> Slider
| |
-> ButtonItem -> SliderItem
First, for one, everything is an Widget, lets get that clear.
Second, Slider!SliderItem is just a wrapper to Button!ButtonItem.
This allows us to add additional slider based code to a button to
make it act like a slider(which is more than a button, but still
a button).
This is just a 2D case of the 1D inheritance Slider is a Button.
Just because we add a parameterization to it DOESN'T NECESSARILY
change that. If the parameter also has an inheritance
relationship then we have a fully valid inheritance relationship.
e.g., Slider!Pocahontas has only a partial inheritance to
Button!ButtonItem because Pocahontas is not in any way derived
from ButtonItem. But if Pocahontas is fully derived from
ButtonItem then the partial inheritance is full inheritance.
Do you understand that?
Else, if you were correct, something like Slider!Widget and
Button!Widget would never be relatable. Yet it's obvious that it
is trivially relatable because Widget = Widget. In my case the
only difference is SliderItem derives from ButtonItem.
We can always cast to a super class. ALWAYS! Slider!SliderItem is
a super class of Button!ButtonItem.
In fact, if we had some way to
Re: D casting broke?
On 06/19/2016 09:59 PM, Joerg Joergonson wrote: This should be completely valid since B!T' obviously derives from A!T directly ok and we see that T' derives from b which derives from a directly. ok So B!b is an entirely derived from A!a No. B!b is derived from A!b, not from A!a. `b` being derived from `a` does not make A!b derived from A!a. Here is the full inheritance tree: X ├─x │ └─a │ └─b ├─A!a └─A!b └─B!b
Re: D casting broke?
On Sunday, 19 June 2016 at 19:59:28 UTC, Joerg Joergonson wrote: This should be completely valid since B!T' obviously derives from A!T directly and we see that T' derives from b which derives from a directly. So B!b is an entirely derived from A!a and hence the cast should be successful I don't see how you think that. Here's the parent chain: B!b -> A!b -> X -> x -> Object There's no A!a in there, the cast is failing correctly. Just because `b` is a child of `a` doesn't mean that `A!b` is the same as `A!a`. Consider an array: MyClass[] arr; arr ~= new MyClass(); // ok cool Object[] obj_arr = arr; // won't work! because... obj_arr[0] = new RandomClass(); // this would compile... // but obj_arr and arr reference the same data, so now: arr[0] is typed MyClass... but is actually RandomClass! It'd crash horribly. Array is just one example of where converting A!b to A!a is problematic. The same principle can apply anywhere, so it won't implicitly cast them. The obviously question: Is there a simple way around this? What are you actually trying to do?
D casting broke?
import std.stdio;
class X { X Parent; }
class x : X { }
class a : x
{
void Do()
{
auto p = cast(A!a)(this.Parent); // works as long as we
are in A
assert(p !is null);
}
}
class A(T : a) : X
{
X Parent = new X();
T _y = new T();
}
class b : a { }
class B(T : b) : A!T { }
void main(string[] argv)
{
auto _A = new A!a();
auto _B = new B!b();
_A.Parent = _A;
_A._y.Parent = _A;
_B.Parent = _B;// works if _A, since _B is of type _A it
should still work
_B._y.Parent = _B; // ...
_A._y.Do();
_B._y.Do();
}
This should be completely valid since B!T' obviously derives from
A!T directly and we see that T' derives from b which derives from
a directly. So B!b is an entirely derived from A!a and hence the
cast should be successful
So, my code crashes because when I do the cast in the base class
A!T, and it is used in the derived class(which the cast should be
valid), a null pointer is created which is used in the base
class. (Basically, B!T doesn't have to have any code in it, just
create the object, the code in A!T then will crash if such a cast
exists)
The obviously question: Is there a simple way around this? I'd
ask, how long to fix but that might take months/years. I can
override in b and duplicate code but why? That makes life more
difficult than having things work as they should(having to
maintain twice is much code is not a solution).
What exactly does the compiler switch -betterC do?
When compiling, what exactly does the -betterC flag do? The command help says "omit generating some runtime information and helper functions" but what does this really mean? Is there any specifics somewhere?
Re: Unmanaged drop in replacemet for [] and length -= 1
On Sunday, June 19, 2016 15:59:41 Joerg Joergonson via Digitalmars-d-learn wrote: > If foreach removes all/any of the elements of a container then > something is broke. That's exactly what happens with a basic input range, and if it doesn't happen with a forward range, it's just because copying that range implicitly saves it, which doesn't work in generic code, because it's not the case with all forward ranges. popFront consumes an element from a range, and foreach is popping every element in the range. The same goes for any algorithm which iterates over a range. So, naturally, any container that is treated as a range is going to have its elements removed as it's iterated over. You're certainly free to treat a container as a range if that's what you want to do, but it shows a fundamental misunderstanding of what a range is supposed to be and do, and there are plenty of algorithms that will behave very badly for you if you do that. - Jonathan M Davis
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
Unfortunatelly I still don't get it. I would like to have an
independant project "dbar". The created lib is then used in
another project "dfoo". Assuming that "dfoo" has no access to
"dbar" other than the .lib file.
You can't do it with only the lib file. You *need* the source
file too for the import statement. As I explained, the lib file
is used by the linker, not the compiler. The compiler needs the
source file.
My folder structure is like this:
-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.
-dtest
--dfoo
lib\dbar.d // copied from the dbar project
source\app.d
dub.json
You don't need to copy dbar to the lib directory in this case.
This project would use the dbar.lib but should otherwise not
have access to the dbar project. Basically simulating, that
someone else made a dbar project to which I would not have
access other than using the dbar.lib. How do I have to
configure the dub.json file for this to work?
One of two things would happen:
1) They would register the project with he dub registry, then
you add a dependency to a specific version the library. Dub
would then download the necessary files for you and ensure that
everything you need is passed to the compiler when building
your project.
2) They would provide some other means for you to get the
source and the library. Then you would need to manually
configure your dub.json to pass the import path to the compiler
and link with the library.
I have tried a variety of configurations for the dub.json. At
this point it feels like a bad guessing game. That is no way
to deveop anything. I need to figure out how to properly setup
the dub.json but I don't seam to find the answer online.
"http://code.dlang.org/package-format?lang=json; isn't very
helpful.
All the information you need is there on that page.
I have meanwhile adjusted my dtest/dfoo/dub.json to this:
"dependencies": {
"dbar": "~master"
}
This gives me the error: "Root package dfoo references unknown
package dear"
As I explained above, you need a path attribute for the
dependency in this case since it is on your local file system
and not in the registry. The documentation link I gave you
explains how to to this. Try this:
"dependencies": {
"dbar": {"path": "../dbar"}
}
I see where I went wrong. I thought that it's possible to only
use the .lib file without the source code of dbar. Having access
to the source makes what I am trying somewhat pointless. Is it
otherwise possible to provide some functionality without having
to give away your source? I would like to put together a library
that I can reuse, without having to rely on the source each time.
Maybe a dll instead?
Note: I don't have a problem with giving away my code. I just
want to know if it can be done. Or maybe later build a plugin
system where the creator of the plugin does not need the source
of the entire application. And in turn the app does not need to
be recompiled in order to use the plugin.
Thanks for your help!
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
Unfortunatelly I still don't get it. I would like to have an
independant project "dbar". The created lib is then used in
another project "dfoo". Assuming that "dfoo" has no access to
"dbar" other than the .lib file.
You can't do it with only the lib file. You *need* the source
file too for the import statement. As I explained, the lib file
is used by the linker, not the compiler. The compiler needs the
source file.
My folder structure is like this:
-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.
-dtest
--dfoo
lib\dbar.d // copied from the dbar project
source\app.d
dub.json
You don't need to copy dbar to the lib directory in this case.
This project would use the dbar.lib but should otherwise not
have access to the dbar project. Basically simulating, that
someone else made a dbar project to which I would not have
access other than using the dbar.lib. How do I have to
configure the dub.json file for this to work?
One of two things would happen:
1) They would register the project with he dub registry, then you
add a dependency to a specific version the library. Dub would
then download the necessary files for you and ensure that
everything you need is passed to the compiler when building your
project.
2) They would provide some other means for you to get the source
and the library. Then you would need to manually configure your
dub.json to pass the import path to the compiler and link with
the library.
I have tried a variety of configurations for the dub.json. At
this point it feels like a bad guessing game. That is no way to
deveop anything. I need to figure out how to properly setup the
dub.json but I don't seam to find the answer online.
"http://code.dlang.org/package-format?lang=json; isn't very
helpful.
All the information you need is there on that page.
I have meanwhile adjusted my dtest/dfoo/dub.json to this:
"dependencies": {
"dbar": "~master"
}
This gives me the error: "Root package dfoo references unknown
package dear"
As I explained above, you need a path attribute for the
dependency in this case since it is on your local file system and
not in the registry. The documentation link I gave you explains
how to to this. Try this:
"dependencies": {
"dbar": {"path": "../dbar"}
}
Re: ARSD PNG memory usage
Also, for some reason one image has a weird horizontal line at the bottom of the image that is not part of the original. This is as if the height was 1 pixel to much and it's reading "junk". I have basically a few duplicate images that were generated from the same base image. None of the others have this problem. If I reduce the image dimensions it doesn't have this problem. My guess is that there is probably a bug with a > vs >= or something. When the image dimensions are "just right" an extra line is added that may be non-zero. The image dimensions are 124x123. This is all speculation but it seems like it is a png.d or opengltexture issue. I cannot see this added line in any image editor I've tried(PS, ifranview) and changing the dimensions of the image fix it. Since it's a hard one to debug without test case I will work on it... Hoping you have some possible points of attack though.
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote: On Sunday, 19 June 2016 at 16:31:40 UTC, Mike Parker wrote: [...] Thanks for the reply. Unfortunatelly I still don't get it. I would like to have an independant project "dbar". The created lib is then used in another project "dfoo". Assuming that "dfoo" has no access to "dbar" other than the .lib file. [...] Darn, I can't seam to edit the post. The line: "lib\dbar.d // copied from the dbar project" should of course read: lib\dbar.lib // copied from the dbar project I am copying the lib file. Not the .d file.
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 16:31:40 UTC, Mike Parker wrote:
On Sunday, 19 June 2016 at 15:35:04 UTC, moe wrote:
I am new to d and doing some small test apps at the moment to
learn d. Currently I must be missing something basic here. I
have installed dub as a project manager and I am trying to use
a .lib file in an app. However, I can not use a module from
the .lib file. I get the following error:
"module barlib is in file 'barlib.d' which cannot be read"
This is a compile time error, not a link time error. Imports
modules and linking to libraries are two different things.
the dub.json for the app
{
"name": "dfoo",
"authors": ["moe"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "executable",
"configurations": [
{
"name": "debug",
"targetPath": "bin/debug",
"buildOptions": ["debugMode", "debugInfo"]
},
{
"name": "release",
"targetPath": "bin/release",
"buildOptions": ["releaseMode", "optimize", "inline"]
}
]
}
Nowhere have you set up barlib as a dependency for your app, so
DUB has no idea it's supposed to tell dmd that you need to link
to the library or where to find the modules. So the easy thing
to do is to add a dependency directive. Since your library
isn't registered with the dub registry, you'll need to provide
a path to the barlib dub project rather than a release tag for
the library.
Assuming a directory tree like so:
-projects
--barlib
---dub.json
--dfoo
---dub.json
Then the path for dfoo's depencency is ../barlib. With a
dub.sdl file, it would look like this:
dependency "barlib" path="../barlib"
You can find the equivalent JSON syntax somewhere at [1]. With
this, dub will manage your import path and library dependency
for you.
I can successfully build the barlib.lib file but I can not use
it in the app. I thought that it should be possible to simply
import the module from the lib-file, but the app cannot find
the module. I would like to be able to build .lib and .dll
files and use them in other applications. Can someone tell me
what I am missing?
Compiling and linking are two distinct steps. The compiler
passes any libraries you give it to the linker, but it does not
do anything with them itself during the compile step. At that
stage, it's only concerned with source modules. So you need to
tell it: where to find the source modules (on the command
line), which ones to import (with the import statement). It
also needs to know which libraries to pass to the linker and
where they can be found.
Give the directory tree above, when compiling dfoo manually,
you might do this on Windows:
cd dfoo
dmd -I../barlib/source source/app.d ../barlib/bin/barlib.lib
On other systems:
dmd -I../barlib/source -L-L../barlib/bin -L-lbarlib source/app.d
The -I switch tells the compiler where it can find the modules
you need to import. DRuntime and Phobos are configured in DMD's
config files, so you don't need to every specify those. On the
windows command line, you can pass the full path to the library
directly and the compiler will do the right thing. This is
easier than dealing with the different syntax the two supported
Windows linkers use for command line switches. On Posix
systems, it's better to use the -L switch, which tell the
compiler the immediately following command should be passed to
the system linker. Ex:
-L-L/some/path -> passes -L/some/path to the linker, which is
the switch telling it where to look for libraries.
-L-lFoo (-L-l -- the second letter is a lowercase 'L') ->
passes -lname to the linker, telling it which library to link
with.
Given this, the linker will look for /some/path/libFoo.so or
/some/path/libFoo.a, in addition to searching the normal search
paths.
As you can see, it's easier to properly configure your dub.json
dependecies so that DUB can handle all of this for you.
[1] http://code.dlang.org/package-format?lang=json
Thanks for the reply.
Unfortunatelly I still don't get it. I would like to have an
independant project "dbar". The created lib is then used in
another project "dfoo". Assuming that "dfoo" has no access to
"dbar" other than the .lib file.
My folder structure is like this:
-dtest
--dbar
source\barlib.d
dub.json
This project creates a dbar.lib file which seams to work.
-dtest
--dfoo
lib\dbar.d // copied from the dbar project
source\app.d
dub.json
This project would use the dbar.lib but should otherwise not have
access to the dbar project. Basically simulating, that someone
else made a dbar project to which I would not have access other
than using the dbar.lib. How do I have to configure the dub.json
file
Re: Using .lib and .dll in D applications
On Sunday, 19 June 2016 at 15:35:04 UTC, moe wrote:
I am new to d and doing some small test apps at the moment to
learn d. Currently I must be missing something basic here. I
have installed dub as a project manager and I am trying to use
a .lib file in an app. However, I can not use a module from the
.lib file. I get the following error:
"module barlib is in file 'barlib.d' which cannot be read"
This is a compile time error, not a link time error. Imports
modules and linking to libraries are two different things.
the dub.json for the app
{
"name": "dfoo",
"authors": ["moe"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "executable",
"configurations": [
{
"name": "debug",
"targetPath": "bin/debug",
"buildOptions": ["debugMode", "debugInfo"]
},
{
"name": "release",
"targetPath": "bin/release",
"buildOptions": ["releaseMode", "optimize", "inline"]
}
]
}
Nowhere have you set up barlib as a dependency for your app, so
DUB has no idea it's supposed to tell dmd that you need to link
to the library or where to find the modules. So the easy thing to
do is to add a dependency directive. Since your library isn't
registered with the dub registry, you'll need to provide a path
to the barlib dub project rather than a release tag for the
library.
Assuming a directory tree like so:
-projects
--barlib
---dub.json
--dfoo
---dub.json
Then the path for dfoo's depencency is ../barlib. With a dub.sdl
file, it would look like this:
dependency "barlib" path="../barlib"
You can find the equivalent JSON syntax somewhere at [1]. With
this, dub will manage your import path and library dependency for
you.
I can successfully build the barlib.lib file but I can not use
it in the app. I thought that it should be possible to simply
import the module from the lib-file, but the app cannot find
the module. I would like to be able to build .lib and .dll
files and use them in other applications. Can someone tell me
what I am missing?
Compiling and linking are two distinct steps. The compiler passes
any libraries you give it to the linker, but it does not do
anything with them itself during the compile step. At that stage,
it's only concerned with source modules. So you need to tell it:
where to find the source modules (on the command line), which
ones to import (with the import statement). It also needs to know
which libraries to pass to the linker and where they can be found.
Give the directory tree above, when compiling dfoo manually, you
might do this on Windows:
cd dfoo
dmd -I../barlib/source source/app.d ../barlib/bin/barlib.lib
On other systems:
dmd -I../barlib/source -L-L../barlib/bin -L-lbarlib source/app.d
The -I switch tells the compiler where it can find the modules
you need to import. DRuntime and Phobos are configured in DMD's
config files, so you don't need to every specify those. On the
windows command line, you can pass the full path to the library
directly and the compiler will do the right thing. This is easier
than dealing with the different syntax the two supported Windows
linkers use for command line switches. On Posix systems, it's
better to use the -L switch, which tell the compiler the
immediately following command should be passed to the system
linker. Ex:
-L-L/some/path -> passes -L/some/path to the linker, which is the
switch telling it where to look for libraries.
-L-lFoo (-L-l -- the second letter is a lowercase 'L') -> passes
-lname to the linker, telling it which library to link with.
Given this, the linker will look for /some/path/libFoo.so or
/some/path/libFoo.a, in addition to searching the normal search
paths.
As you can see, it's easier to properly configure your dub.json
dependecies so that DUB can handle all of this for you.
[1] http://code.dlang.org/package-format?lang=json
Re: ARSD PNG memory usage
On Saturday, 18 June 2016 at 02:17:01 UTC, Adam D. Ruppe wrote:
I have an auto generator for pngs and 99% of the time it works,
but every once in a while I get an error when loading the png's.
Usually re-running the generator "fixes the problem" so it might
be on my end. Regardless of where the problem stems, it would be
nice to have more info why instead of a range violation.
previousLine is null in the break.
All the png's generated are loadable by external app like
ifranview, so they are not completely corrupt but possibly could
have some thing that is screwing png.d up.
The code where the error happens is:
case 3:
auto arr = data.dup;
foreach(i; 0 .. arr.length) {
auto prev = i < bpp ? 0 : arr[i - bpp];
arr[i] += cast(ubyte)
/*std.math.floor*/( cast(int) (prev +
previousLine[i]) / 2);
}
Range violation at png.d(1815)
Any ideas?
Re: Unmanaged drop in replacemet for [] and length -= 1
On Sunday, 19 June 2016 at 10:10:54 UTC, Jonathan M Davis wrote: On Saturday, June 18, 2016 21:55:31 Joerg Joergonson via Digitalmars-d-learn wrote: I wanted to switch to std.container.Array but it doesn't seem to mimic [] for some odd ball reason. D's dynamic arrays are really quite weird in that they're sort of containers and sort of not. So, pretty much nothing is ever going to act quite like a dynamic array. But when dynamic arrays are used as ranges, their semantics definitely are not that of containers. Having a container which is treated as a range is just begging for trouble, and I would strongly advise against attempting it. When it comes to containers, ranges are intended to be a view into a container, just like an iterator is intended to be a pointer into a container. Neither ranges are iterators are intended to _be_ containers. Treating a container as a range is going to get you weird behavior like foreach removing every element from the container. - Jonathan M Davis Thanks for your 2c... but I think I can handle it. I'm a big boy and I wear big boy pants and I'm not afraid of a few little scrapes. If foreach removes all/any of the elements of a container then something is broke.
Using .lib and .dll in D applications
Hello,
I am new to d and doing some small test apps at the moment to
learn d. Currently I must be missing something basic here. I have
installed dub as a project manager and I am trying to use a .lib
file in an app. However, I can not use a module from the .lib
file. I get the following error:
"module barlib is in file 'barlib.d' which cannot be read"
here is what I currently have:
the file to build the library
-
module barlib;
import std.stdio;
class BarLib
{
this(){}
void Talk(string msg)
{
writeln("BL: %s", msg);
}
}
the dub.json to build the lib
-
{
"name": "dbar",
"authors": ["moe"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "staticLibrary",
"configurations": [
{
"name": "debug",
"targetPath": "bin/debug",
"buildOptions": ["debugMode", "debugInfo"]
},
{
"name": "release",
"targetPath": "bin/release",
"buildOptions": ["releaseMode", "optimize", "inline"]
}
]
}
the file for the app
import barlib;
import std.stdio;
void main()
{
auto b = new BarLib();
b.Talk("Hello from barlib");
}
the dub.json for the app
{
"name": "dfoo",
"authors": ["moe"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "executable",
"configurations": [
{
"name": "debug",
"targetPath": "bin/debug",
"buildOptions": ["debugMode", "debugInfo"]
},
{
"name": "release",
"targetPath": "bin/release",
"buildOptions": ["releaseMode", "optimize", "inline"]
}
]
}
I can successfully build the barlib.lib file but I can not use it
in the app. I thought that it should be possible to simply import
the module from the lib-file, but the app cannot find the module.
I would like to be able to build .lib and .dll files and use them
in other applications. Can someone tell me what I am missing?
Re: Templated class defaults and inheritence
On Saturday, 18 June 2016 at 17:48:47 UTC, Joerg Joergonson wrote:
class foo(T) if (is(T : subfoo)) X;
FYI this can also be done in the template parameter list:
class foo(T : subfoo){}
Re: Why do I get this error when casting to an immutable or shared byRef return type?
On 06/19/2016 12:45 PM, Gary Willoughby wrote:
On Sunday, 19 June 2016 at 10:35:59 UTC, Gary Willoughby wrote:
...
A more correct example:
import core.stdc.stdlib;
import std.traits;
ref T foo(T)()
{
alias Type = Unqual!(T);
Type* foo = cast(Type*) malloc(Type.sizeof * 8);
return *foo;
}
void main(string[] args)
{
// Works!
auto bar = foo!(int)();
// Works!
auto bar = foo!(const(int))();
// Error: cast(immutable(int))*foo is not an lvalue
auto bar = foo!(immutable(int))();
// Error: cast(shared(int))*foo is not an lvalue
auto bar = foo!(shared(int))();
}
At the core, int* doesn't implicitly convert to immutable(int)*.
Equally, a mutable int doesn't implicitly convert to an immutable one
with the same address. That conversion makes a copy, so the result is an
rvalue and you can't take it's address.
A mutable int does implicitly convert to a const one with the same
address, because const is fine with the value changing through the
mutable view. immutable would not be fine with that, so it's rejected.
Same with shared, of course.
Re: Why do I get this error when casting to an immutable or shared byRef return type?
On Sunday, 19 June 2016 at 10:45:25 UTC, Gary Willoughby wrote: On Sunday, 19 June 2016 at 10:35:59 UTC, Gary Willoughby wrote: ... A more correct example: In the second example, the problem is this: alias Type = Unqual!(T); You are declaring the function to return T, which in your example is either int, const(int), immutable(int), or shared(int), but are returning a plain int in every case. This is fine for const(int), since non-const can implicitly convert to const. That is not the case for immutable(int) or shared(int). If you take out the alias to Unqual!T and replace both remaining instances of Type with T, then it works.
Re: Why do I get this error when casting to an immutable or shared byRef return type?
On Sunday, 19 June 2016 at 10:35:59 UTC, Gary Willoughby wrote:
...
A more correct example:
import core.stdc.stdlib;
import std.traits;
ref T foo(T)()
{
alias Type = Unqual!(T);
Type* foo = cast(Type*) malloc(Type.sizeof * 8);
return *foo;
}
void main(string[] args)
{
// Works!
auto bar = foo!(int)();
// Works!
auto bar = foo!(const(int))();
// Error: cast(immutable(int))*foo is not an lvalue
auto bar = foo!(immutable(int))();
// Error: cast(shared(int))*foo is not an lvalue
auto bar = foo!(shared(int))();
}
Why do I get this error when casting to an immutable or shared byRef return type?
In the following code, the `foo` function doesn't work when
casting to an immutable or shared type. Can anyone please explain
what is happening here? Is there any way of returning such
variables byRef from a malloc'd chunk of memory?
import core.stdc.stdlib;
ref T foo(T)()
{
int* foo = cast(int*) malloc(int.sizeof * 8);
return *foo;
}
void main(string[] args)
{
// Works!
auto bar = foo!(int)();
// Works!
auto bar = foo!(const(int))();
// Error: cast(immutable(int))*foo is not an lvalue
auto bar = foo!(immutable(int))();
// Error: cast(shared(int))*foo is not an lvalue
auto bar = foo!(shared(int))();
}
Re: Unmanaged drop in replacemet for [] and length -= 1
On Saturday, June 18, 2016 21:55:31 Joerg Joergonson via Digitalmars-d-learn wrote: > I wanted to switch to std.container.Array but it doesn't seem to > mimic [] for some odd ball reason. D's dynamic arrays are really quite weird in that they're sort of containers and sort of not. So, pretty much nothing is ever going to act quite like a dynamic array. But when dynamic arrays are used as ranges, their semantics definitely are not that of containers. Having a container which is treated as a range is just begging for trouble, and I would strongly advise against attempting it. When it comes to containers, ranges are intended to be a view into a container, just like an iterator is intended to be a pointer into a container. Neither ranges are iterators are intended to _be_ containers. Treating a container as a range is going to get you weird behavior like foreach removing every element from the container. - Jonathan M Davis
Re: Dub generate visuald, multiple configurations?
On Sunday, 19 June 2016 at 07:25:29 UTC, Tofu Ninja wrote: On Friday, 17 June 2016 at 08:49:47 UTC, Tofu Ninja wrote: Is there a way to generate a single visuald project file for all dub configurations, selecting the configuration from the visual studio configuration manager? Or do I have to generate a separate project for each configuration? I am guessing no? No. You have to regenerate each time you switch compiler, arch or configuration. shell aliases help!
Re: Dub generate visuald, multiple configurations?
On Friday, 17 June 2016 at 08:49:47 UTC, Tofu Ninja wrote: Is there a way to generate a single visuald project file for all dub configurations, selecting the configuration from the visual studio configuration manager? Or do I have to generate a separate project for each configuration? I am guessing no?
