Need help to understand how to work with tkd
Now I am trying to learn how to build GUI apps in D. But I have
some troubles.
http://code.dlang.org/packages/tkd
1. I can't understand how to set window size in example on page
above. I looked at docs and found only how to create new window.
But here I do not see any procedure that create window and set
it's params. I see only initInterface.
2. Do I right understand that all GUI stuff should be placed only
in:
class Application : TkdApplication
3. I need to get file name from dialog and use it's for example
in main
override protected void initInterface()
{
...
string fileToOpen = dialog.getResult();
}
How I can get fileToOpen from main or another instance. Could you
show example?
Re: Need help to understand how to work with tkd
Yeah, the docs navigation sucks http://htmlpreview.github.io/?https://github.com/nomad-software/tkd/master/docs/tkd/tkdapplication.html
Re: Mimicking C++'s indexing behavior in D associative arrays
Rikki Cattermole: Foo*[string] bar; Foo v = *bar.grab(mykey); Is this the setdefault of Python dicts? If this need is strong a new function could be added to Phobos (or even druntime if you want to reduce the number of hash computations). Bye, bearophile
Re: Mimicking C++'s indexing behavior in D associative arrays
// Assume bar is some associative array of type Foo[string]
Foo* value = key in bar;
if (!value) {
bar[key] = Foo.init;
value = bar[key];
}
This seems sub-optimal, given that in involves three hashes (two lookups
and one insertion). Is there a more efficient or cleaner way to do so?
So basically:
Foo v = bar.get(key, Foo.init)
bar[key] = v;
Get is like an ordinary index but it will return the given value if it does not
exist in the AA.
Of course you probably want to create a new UFCS function to wrap your check +
default initialize if it doesn't exist.
T grab(T, U)(T[U] aa, U key) if (is(T == struct)) {
if (key !in aa)
aa[key] = new T;
return aa[key];
}
You are searching for the key twice and the original example used pointers.
There is a function called _aaGetX in the runtime that has exactly the required
behaviour:
// Get pointer to value in associative array indexed by key.
// Add entry for key if it is not already there.
void* _aaGetX(AA* aa, const TypeInfo keyti, in size_t valuesize, in void*
pkey)
however, using it in normal code could be considered a hack, because it belongs
to the internal implementation of associative arrays. Anyway, while waiting for
a better solution to present itself, we might as well have a look at this very
dirty one. ;)
extern(C) void* _aaGetX(void* aa, const TypeInfo keyti, in size_t
valuesize, in void* pkey);
V* aaGet(K, V)(V[K] arr, K key) {
return cast(V*)_aaGetX(cast(void*)arr, typeid(K), V.sizeof,
cast(void*)key);
}
unittest {
int[int] arr = [1: 10, 2: 20, 3: 30];
int *val = arr.aaGet(3); // an existing value
assert(*val == 30);
val = arr.aaGet(4); // aa[4] will be created
assert(*val == int.init);
assert(arr[4] == int.init);
}
Re: Need help to understand how to work with tkd
For my regret I need example to understand how to work with шею Could you show me at last passing fileToOpen to another instance?
Re: Undefined symbol?
On Wednesday, 18 February 2015 at 08:55:51 UTC, Tofu Ninja wrote: When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be? These errors are normally caused by combining object files or libraries that were compiled by different compiler versions. The biggest mistake is accidentally linking to an older/newer version of phobos.
Undefined symbol?
When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be?
Re: Dividing D Module between multiple files
On 02/17/2015 11:23 PM, Muahmmad Adel wrote: I have searched online and I found no way for dividing D Module between multiple files. As always, documentation can be better. :) There is the relatively new package module: http://dlang.org/module.html#package-module http://ddili.org/ders/d.en/modules.html#ix_modules.package%20import high probability of merge conflicts (as more developers are working on the same file) A merge conflict at the file level yes, but if the developers are touching different parts of that file, then most merge tools wouldn't see that as a merge conflict. Ali
deliberately failing compilation when errors are in embedded DSL
I'm developing an embedded DSL using CTFE. The DSL code is translated into D code and mixin-ed into the D code of user's application. In order to provide meaningful error messages the DSL compiler always intercepts all errors in the DSL code and reports them at compile-time using pragma(msg, ...). The DSL compiler never generates incorrect D code to avoid reporting errors in the generated D code obscurely related to the original DSL code. The problem is that the D compiler always exits as if the compilation was successful (for D compiler it is successful, since the generated D code is correct). Is there any way to force the D compiler to fail compilation other than generating incorrect D code when translating erroneous DSL code?
Re: deliberately failing compilation when errors are in embedded DSL
On 2/18/15 12:43 PM, Dmitri Makarov wrote: I'm developing an embedded DSL using CTFE. The DSL code is translated into D code and mixin-ed into the D code of user's application. In order to provide meaningful error messages the DSL compiler always intercepts all errors in the DSL code and reports them at compile-time using pragma(msg, ...). The DSL compiler never generates incorrect D code to avoid reporting errors in the generated D code obscurely related to the original DSL code. The problem is that the D compiler always exits as if the compilation was successful (for D compiler it is successful, since the generated D code is correct). Is there any way to force the D compiler to fail compilation other than generating incorrect D code when translating erroneous DSL code? static assert(0, message) -Steve
Re: Alias delegates and @nogc
On Wed, 18 Feb 2015 18:13:58 +, ketmar wrote: it doesn't really cost *that* much (especially if you'll remember that DMD optimiser is far from... well, optimal ;-) i mean that there are alot of other code that isn't optimal for speed, so delegate call is rarely an issue. signature.asc Description: PGP signature
Re: Alias delegates and @nogc
ketmar wrote: On Wed, 18 Feb 2015 19:09:50 +0300, Ivan Timokhin wrote: Is there any way to pass a delegate that: 1. avoids indirect calls (like alias); 2. does not allocate (like scope delegate); 3. captures local variables? i don't think that you can do it. but what is wrong with delegate version? it doesn't really cost *that* much (especially if you'll remember that DMD optimiser is far from... well, optimal ;-), and if you really doing something where indirect function call matters, you'd better use mixins anyway. Thank you for the answer, I suspected as much.
Re: Alias delegates and @nogc
On 2/18/15 11:09 AM, Ivan Timokhin wrote:
With dmd 2.066.1, this compiles:
void bar(scope int delegate() a) @nogc {}
void foo(int x) @nogc
{
bar(() = x);
}
but this doesn't:
void bar(alias a)() {}
void foo(int x) @nogc
{
bar!(() = x)();
}
Fails with
Error: function test.foo @nogc function allocates a closure with the GC
Is there any way to pass a delegate that:
1. avoids indirect calls (like alias);
2. does not allocate (like scope delegate);
3. captures local variables?
Building on ketmar's point, I think you should not worry about tricking
the compiler into avoiding indirect calls. The compiler could and should
avoid indirect calls and GC closures when it can do so. In particular,
it should be able to inline bar, and (I assume in a full version of the
code) any uses of the delegate.
But it just doesn't yet.
-Steve
GC deadlocks on linux
I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Adding core.memory.GC.disable; to main causes the application to work correctly (and quickly till it runs out of memory :D ) I am running in a vagrant VM for test, but this should not be the issue. I am developing this for a future product so I wont have control over the environment that it runs in. I am not sure how to debug or work around this issue. My boss is a little concerned that I am using D but does think its cool. I really want to make this stable and get D in to one of our products, if not I will have to switch to C++ or even worse JAVA! Any help would be appreciated. -Byron System: DMD 2.066.1 Linux vagrant-ubuntu-precise-64 3.2.0-76-virtual #111-Ubuntu SMP Tue Jan 13 22:3 3:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.5 LTS NAME=Ubuntu VERSION=12.04.5 LTS, Precise Pangolin ID=ubuntu ID_LIKE=debian PRETTY_NAME=Ubuntu precise (12.04.5 LTS) VERSION_ID=12.04
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 21:05:10 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it. My guess is this is going to be related to forking, going to see if I can make a test case.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 21:21:11 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 21:05:10 UTC, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it. My guess is this is going to be related to forking, going to see if I can make a test case. Might be related: https://issues.dlang.org/show_bug.cgi?id=6846
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote: Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890 Dont think so $dpkg --get-selections | grep gdm doesn't return anything also running via ssh
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) signature.asc Description: PGP signature
Re: GC deadlocks on linux
Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). signature.asc Description: PGP signature
Re: Dividing D Module between multiple files
On Wednesday, 18 February 2015 at 07:34:13 UTC, Daniel Kozák wrote: On Wed, 18 Feb 2015 07:23:24 + Muahmmad Adel via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I have searched online and I found no way for dividing D Module between multiple files. You are not force to do so I do not see any trouble here. For eg. I have lots of file where I have only one class (similar to java concept). The problem with this approach is that you will end with ugly class names like mypackage.myclass.MyClass. I'm porting some C# code where I need the type name at runtime and I ended with a huge package.d file just to keep pretty names like mypackage.MyClass. Another way to trick the compiler is to mixin import all modules in the package.d file but you'll loose features like code completion in your editor.
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize p.s. and check if you don't disable signals. druntime uses SIGUSR1 to communicate with threads (even if you aren't using more that one thread in your code). it doesn't on windows though (there are no signals there ;- ), but your posix code can accidentally block/intercept the signals druntime uses for internal bookkeeping. signature.asc Description: PGP signature
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:55:56 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:35:44 +, Byron Heads wrote: On Wednesday, 18 February 2015 at 20:33:40 UTC, ketmar wrote: On Wed, 18 Feb 2015 20:27:07 +, Byron Heads wrote: are you forking? ;-) I am in the daemonize library https://github.com/NCrashed/daemonize can you drop that and just let the program run on foreground? i suspect that it may solve your problem. you can detach your program with setsid and to avoid forking. `fork()` is a very fragile thing, and it may be the source of heisenbugs. stop `fork()`ing may be the easiest solution (if it solves something, of course ;-). By passing daemonize with the GC enabled is working.. going to dig into the signals and see if thats it.
Re: Is this a bug in dmd 2.067 for struct initializers?
On 02/18/2015 10:39 PM, stewarth wrote:
This works under dmd 2066.1 but fails under dmd 2.067-b2.
I don't know whether it is a bug.
struct B {
A* a;
In any case, that must be immutable(A)*.
}
static immutable B[] someB = [{a:someA[0]}, {a:someA[1]}];
I want it to initialize at runtime before main(). I don't
actually want any CTFE stuff here.
Then you need 'static this()' (or 'shared static this()'):
static immutable B[] someB;
static this() {
someB = [ B(someA[0]), B(someA[1]) ];
}
Note that I could not use the named member syntax because in my case the
compiler cannot know what the right-hand side expression is. However, it
is still possible with a temporary where the type is explicit as in your
case:
static this() {
immutable B[] tmp = [ {a:someA[0]}, {a:someA[1]} ];
someB = tmp;
}
Ali
Is this a bug in dmd 2.067 for struct initializers?
Hi All,
This works under dmd 2066.1 but fails under dmd 2.067-b2.
---
struct A {
int val;
}
static immutable A[] someA = [{val:1}, {val:2}];
struct B {
A* a;
}
static immutable B[] someB = [{a:someA[0]}, {a:someA[1]}];
void main()
{
writefln(a:%s, someA);
writefln(b:%s, someB);
}
---
Error under DMD 2.067-b2:
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][0]'
hack.d(27): Error: cannot use non-constant CTFE pointer in an
initializer '[A(1), A(2)][1]'
Is this a bug, or a deliberate change?
I'm thinking a bug because I want it to initialize at runtime
before main(). I don't actually want any CTFE stuff here.
Thanks,
stew
Alias delegates and @nogc
With dmd 2.066.1, this compiles:
void bar(scope int delegate() a) @nogc {}
void foo(int x) @nogc
{
bar(() = x);
}
but this doesn't:
void bar(alias a)() {}
void foo(int x) @nogc
{
bar!(() = x)();
}
Fails with
Error: function test.foo @nogc function allocates a closure with the GC
Is there any way to pass a delegate that:
1. avoids indirect calls (like alias);
2. does not allocate (like scope delegate);
3. captures local variables?
Re: Type-Strict Indexes: IndexedBy
On Tuesday, 17 February 2015 at 19:46:09 UTC, Nordlöw wrote: Superb! I'd like to see this getting into std.typecons. Having this in the language will attract (more) Ada programmers to D. Should I do PR for std.typecons.[iI]ndexedBy? I'm not familiar with Ada, and I don't immediately see what indexedBy is good for. So maybe gather some examples where it's beneficial, before going for Phobos.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:59:43 UTC, Nordlöw wrote:
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath
wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This makes usage of storing internal state in Ranges bug-prone.
Isn't there some way to store an AA in reference wrapper?
This would simplify my .save member.
Because y does not alias x, it's a null pointer like AA. This
class is clearly a reference type, but the assert holds as well.
class C { int i; }
void main()
{
C c1;
C c2 = c1;
c1 = new C(12);
assert(c1.i != c2.i);
}
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:07:01 UTC, Steven Schveighoffer wrote: But once initialized, it DOES have reference semantics: string[int] x; x[0] = zero; auto y = x; x[1] = one; assert(x == y); Ok, great! I always initialize distMap with firstNd in the DijkstraWalk.this so that avoids the problem then. Thanks alot!
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:07:01 UTC, Steven Schveighoffer wrote: An UNINITIALIZED AA has not yet been allocated, and so it's reference is null. What's reason for uninitialized AA not behaving in the same way as arrays do?
Re: Type-Strict Indexes: IndexedBy
On Wednesday, 18 February 2015 at 12:44:22 UTC, anonymous wrote: Should I do PR for std.typecons.[iI]ndexedBy? I'm not familiar with Ada, and I don't immediately see what indexedBy is good for. So maybe gather some examples where it's beneficial, before going for Phobos. Ok, I have a use case in one my applications I'll bring up. Thanks for now.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:37:57 UTC, Nordlöw wrote: I've written a Dijkstra-style graph traversal range at https://github.com/nordlow/justd/blob/master/knet/traversal.d#L105 that needs to internally store the AA distance map in member variable distMap. 1. All the data members except distMap have reference semantics. I thought AAs had reference semantics. Therefore I've made my range a class instead of a struct. Is this the correct way to do it? Neither false nor necessary. You could use a struct just as well. 2. To make it a ForwardRange I've also add a save() member. For now I've hardcoded the single member that needs to be duped. Is this correct way of doing it? That's how I'd do it.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath
wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This makes usage of storing internal state in Ranges bug-prone.
Isn't there some way to store an AA in reference wrapper?
This would simplify my .save member.
Re: Reference or Value Semantics for Graph Traversal Range
On 2/18/15 8:59 AM, Nordlöw wrote:
On Wednesday, 18 February 2015 at 13:53:17 UTC, Tobias Pankrath wrote:
All the data members except distMap have reference semantics.
I thought AAs had reference semantics.
Me too, but the indeed have value semantics. See for example:
unittest
{
string[int] x;
auto y = x;
x[0] = zero;
assert(x != y);
}
This is a well known problem.
An UNINITIALIZED AA has not yet been allocated, and so it's reference is
null.
But once initialized, it DOES have reference semantics:
string[int] x;
x[0] = zero;
auto y = x;
x[1] = one;
assert(x == y);
And to anticipate your question, no there is no way (yet) to create an
empty but initialized AA.
-Steve
Re: Type-Strict Indexes: IndexedBy
Having this in the language will attract (more) Ada programmers to D. “Having this or that will attract (XY)-programmers / magically make D successful in niche Z” is an argument too weak for phobos inclusion, IMO.
Reference or Value Semantics for Graph Traversal Range
I've written a Dijkstra-style graph traversal range at https://github.com/nordlow/justd/blob/master/knet/traversal.d#L105 that needs to internally store the AA distance map in member variable distMap. 1. All the data members except distMap have reference semantics. Therefore I've made my range a class instead of a struct. Is this the correct way to do it? 2. To make it a ForwardRange I've also add a save() member. For now I've hardcoded the single member that needs to be duped. Is this correct way of doing it?
Re: Structs on the heap and destructors.
On Wednesday, 18 February 2015 at 15:22:47 UTC, John Colvin wrote: doOtherStuff must be called before doStuff. That'll never happen; B is still valid until after A is destroyed, if they weren't on the heap you'd see doStuff goes first too. You should probably make a method to clean B up yourself, I wouldn't even use the destructor, just a regular like dispose method that you can guard with a flag. I think that's the best way to do it.
Re: Need help to understand how to work with tkd
On Wednesday, 18 February 2015 at 08:19:25 UTC, Suliman wrote: Now I am trying to learn how to build GUI apps in D. But I have some troubles. Read the README file in the repository. Then fully read the documentation inside the `docs` folder. Then there is an example application in `source/example/example.d` which shows you everything you've asked for. At least try and help yourself!
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:55:58 UTC, Tobias Pankrath wrote: It's the same with arrays. Ahh, you're right. Thanks.
Re: Reference or Value Semantics for Graph Traversal Range
On Wednesday, 18 February 2015 at 14:38:24 UTC, Nordlöw wrote: On Wednesday, 18 February 2015 at 14:07:01 UTC, Steven Schveighoffer wrote: An UNINITIALIZED AA has not yet been allocated, and so it's reference is null. What's reason for uninitialized AA not behaving in the same way as arrays do? It's the same with arrays.
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 21:21:10 +, Byron Heads wrote: My guess is this is going to be related to forking, going to see if I can make a test case. it's better to avoid forking at all. it's *very* hard to do forking right, it's almost impossible to do it right even in single-threaded app, and it's impossible to do it right in multithreaded app. `fork()` is a can full of worms, it may surprise you even on seemingly simple code. i suggest you to just drop forking and use shell script instead. you can lost alot of time trying to force your forked code to work right, and then it will break again on any move (or even when moon will change it's phase). signature.asc Description: PGP signature
Avoiding Range Postblits
At https://github.com/nordlow/justd/blob/master/knet/association.d#L59 I'm constructing an array of ranges that are used further down in the function contextOf. The expression nds.map!(nd = gr.dijkstraWalker(nd, ...)).array; however triggers postblits for the range DijkstraWalker returned by the instantiator dijkstraWalker. Can this be avoided somehow? I'm guessing that move construction plays a key role here. Note that I can't remove the .array as they required to be l-values because their iteration to have side-effects at the end of the function contextOf().
Re: GC deadlocks on linux
On Wed, 18 Feb 2015 21:21:10 +, Byron Heads wrote: p.s. if you really-really-really need to avoid shell scripts, you can `exec` your program with STDIN, STDOUT and STDERR redirected to /dev/ null, passing some special argument to it. i.e. it shouldn't fork, just exec itself again with added command-line option. just make sure that you did `setsid()` and so on, so the second instance is completely detached. signature.asc Description: PGP signature
Re: Avoiding Range Postblits
On Wed, 18 Feb 2015 22:51:17 +, Nordlöw wrote: Can this be avoided somehow? i don't think so. you can use heap-allocated structs, of course, or maybe `RefCounted!` can do the trick, but i not tried it. signature.asc Description: PGP signature
Quick help on version function parameter
Does anyone know a good way to support versioned function
parameters? Say, in one version I want a variable to be a global
and in another I want it to be a parameter.
version(GlobalVersion)
{
int x;
void foo()
{
// A huge function that uses x
}
} else {
void foo(int x)
{
// A huge function that uses x (same code as
GlobalVersion)
}
}
The problem with this is that the code is duplicated. Is there a
way to do this versioning without having 2 copies of the same
function body? The following definitely does not work:
version(GlobalVersion)
{
int x;
void foo()
} else {
void foo(int x)
}
{
// A huge function that uses x
}
Re: Quick help on version function parameter
I'd write a foo_impl which always takes a parameter. Then do the
versioned foo() functions which just forward to it:
void foo_impl(int x) { long function using x here }
version(globals) {
int x;
void foo() {
foo_impl(x);
}
} else {
void foo(int x) { foo_impl(x); }
}
Minimal duplication with both interfaces.
Re: Quick help on version function parameter
On Wednesday, 18 February 2015 at 23:49:26 UTC, Adam D. Ruppe
wrote:
I'd write a foo_impl which always takes a parameter. Then do
the versioned foo() functions which just forward to it:
void foo_impl(int x) { long function using x here }
version(globals) {
int x;
void foo() {
foo_impl(x);
}
} else {
void foo(int x) { foo_impl(x); }
}
Minimal duplication with both interfaces.
That kinda defeats the purpose of why I want this. It's for
performance reasons. I need one version to have NO arguments and
one version to have one ref argument.
Re: Avoiding Range Postblits
On 02/18/2015 02:51 PM, Nordlöw wrote:
I'm guessing that move construction plays a key role here.
move() does avoid the post-blit but you get many destructions in return:
import std.stdio;
import std.algorithm;
import core.memory;
struct Graph
{}
struct DW
{
int i;
this(int i)
{
writefln( this() for %s, i);
this.i = i;
}
~this()
{
writefln(~this() for %s, i);
}
this(this)
{
writefln(this(this) for %s, i);
assert(false, Oops);
}
}
DW dw(Graph gr, int i)
{
return DW(i);
}
void main()
{
auto gr = Graph();
auto arr = [ 1, 2, 3 ];
auto dws = new DW[arr.length];
foreach (i, el; arr) {
auto source = gr.dw(el);
move(source, dws[i]);
}
writeln(dws);
}
The output:
this() for 1
~this() for 0
~this() for 0
this() for 2
~this() for 0
~this() for 0
this() for 3
~this() for 0
~this() for 0
[DW(1), DW(2), DW(3)]
~this() for 3
~this() for 2
~this() for 1
Ali
Re: Undefined symbol?
On Wednesday, 18 February 2015 at 10:47:50 UTC, John Colvin wrote: On Wednesday, 18 February 2015 at 08:55:51 UTC, Tofu Ninja wrote: When I compile my project in release dmd suddenly starts complains about missing symbols that look like they are from phobos. Symbol Undefined _D3std9exception134__T12errnoEnforceTbVAyaa50_433a5c445c646d64325c77696e646f77735c62696e5c2e2e5cA7E6C89DF0A958C3336C905AF5DE Any idea what is causing it and what a fix might be? These errors are normally caused by combining object files or libraries that were compiled by different compiler versions. The biggest mistake is accidentally linking to an older/newer version of phobos. I am not sure what could be the offending obj. I re downloaded dmd and phobos(pre compiled for windows), cleaned out all my builds and removed all of the tempfiles for dub that I could find.
