Re: string, char[], overloaded functions.
On Saturday, 1 November 2014 at 03:28:36 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 01 Nov 2014 00:05:19 + Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: BTW one could argue that char[] ~ operator should yield something that's implicitly convertable, since it allocates a new memory block anyway, but that's not how it works right now. it's not necessarily allocates. but `(buf~hoo).idup` does, so it can be used. ;-) No, it's `~=` that may or may not allocate, but `~` always does. I think it's an instance of this bug [1]; `buf~hoo` should be inferred as unique, and therefore convert to `immutable`. https://issues.dlang.org/show_bug.cgi?id=1654
Re: string, char[], overloaded functions.
On Sat, 01 Nov 2014 08:36:40 + via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: No, it's `~=` that may or may not allocate, but `~` always does. you a right. sorry, i was wrong here. signature.asc Description: PGP signature
Re: shallow copy of const(Object)[]
On Saturday, 1 November 2014 at 00:08:23 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
So, by shallow copy, you mean that you want an array that
contains the same
elements but is a new array?
yes
If that's what you want, just slice the array.
auto b = a[];
This is the same as `auto b = a;`.
Sure, they'll point to the same spot in memory still, but
because all of the
elements are const, you can't mutate them, so it really doesn't
matter. All it
affects is that because both arrays have the same block of
memory after them,
appending to one of them would make it so that appending to the
other would
force it to reallocate. For for most intents and purposes, you
essentially
have two different arrays.
Except I don't. The elements are not immutable, so they may be
pulled from under my feet from elsewhere. And more importantly,
`a` may refer to non-GC memory. Like the stack, for example:
class C
{
const(Object)[] objects;
this(const(Object)[] objects ...)
{
this.objects = objects;
}
}
C f()
{
return new C(new Object);
}
void main()
{
auto c = f();
auto o = c.objects[0];
f(); /* writing over the previous array */
assert(o is c.objects[0]); /* fails */
}
Re: pop popFront combined
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
If you want move semantics, use `moveFront`.
But x.moveFront doesn't modify x.
What I want is to transform my uses of std.range from
if (!x.empty)
{
x.front.doStuff;
x.popFront;
}
into
if (!x.empty)
if (auto front = x.stealFront)
{
front.doStuff;
}
This is more functional/atomic, that is it reduces the risk of
accidentally forgetting to call popFront at the end.
Destroy!
Re: pop popFront combined
On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
if (!x.empty)
if (auto front = x.stealFront)
{
front.doStuff;
}
This is more functional/atomic, that is it reduces the risk of
accidentally forgetting to call popFront at the end.
Forgot my explicit question:
So why isn't something like x.stealFront already in Phobos?
Re: pop popFront combined
On Saturday, 20 September 2014 at 19:40:02 UTC, AsmMan wrote: Is this function part of phobos library? if so, where? It's in std.range.
Re: string, char[], overloaded functions.
On Friday, 31 October 2014 at 23:59:54 UTC, dajones wrote: is there a better way than doing... cast(string)(buf~hoo) to get it to pick the correct overload? text(buf,hoo)
Re: pop popFront combined
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote: So why isn't something like x.stealFront already in Phobos? First try here: https://github.com/nordlow/justd/blob/master/range_ex.d#L14 Please comment!
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote: https://github.com/nordlow/justd/blob/master/range_ex.d#L14 Please comment! What's the recommended way of making stealFront and stealBack inout here? Can I somehow use auto ref together with inout?
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
That is:
auto ref stealFront(R)(ref R r)
{
import std.range: moveFront, popFront;
auto e = r.moveFront;
r.popFront;
return e;
}
`auto ref` is nonsense here. You can't return a reference to `e`
as
it's a local variable.
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote: On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote: https://github.com/nordlow/justd/blob/master/range_ex.d#L14 Please comment! What's the recommended way of making stealFront and stealBack inout here? Can I somehow use auto ref together with inout? I don't see what you'd need inout for here. stealFront/stealBack are not methods.
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
That is:
auto ref stealFront(R)(ref R r)
{
import std.range: moveFront, popFront;
auto e = r.moveFront;
r.popFront;
return e;
}
`auto ref` is nonsense here. You can't return a reference to `e`
as
it's a local variable.
It's probably intended to mean `auto` + `ref`, not `auto ref`.
`ref` alone is already sufficient to get type deduction.
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:36:05 UTC, Marc Schütz wrote:
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
[...]
auto ref stealFront(R)(ref R r)
{
import std.range: moveFront, popFront;
auto e = r.moveFront;
r.popFront;
return e;
}
[...]
It's probably intended to mean `auto` + `ref`, not `auto ref`.
`ref` alone is already sufficient to get type deduction.
But ref is wrong. The function returns a local. Just auto would
be fine.
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote: On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote: https://github.com/nordlow/justd/blob/master/range_ex.d#L14 Please comment! What's the recommended way of making stealFront and stealBack inout here? Can I somehow use auto ref together with inout? If you want to avoid the temporary variable, you could write: scope(success) r.popFront; return r.moveFront;
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote: If you want to avoid the temporary variable, you could write: scope(success) r.popFront; return r.moveFront; Does this solution cost performance?
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote: `auto ref` is nonsense here. You can't return a reference to `e` as it's a local variable. My mistake. Thanks.
Re: pop popFront combined
On Saturday, 1 November 2014 at 13:36:05 UTC, anonymous wrote: I don't see what you'd need inout for here. stealFront/stealBack are not methods. inout can be used on free functions aswell. See for example https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L674
Interfacing with C++
Hello. I really really need to be able to interface well with a C++ library which contains lots of classes if I am going to further invest time into D. Now from the http://dlang.org/cpp_interface I find out the current status of built-in C++ interfacing support. I'm working on Linux so using the COM support is not an option for me (whatever COM may be!). A few queries: 1) How mature is the SWIG support for wrapping a library into D? Specifically does the above SWIG support take advantage of the built-in C++ support features like connecting directly to virtual functions? 2) Is there any further work underway to implement support for static and non-virtual class member functions? Or is this not at all possible? If so, why? 3) The page speaks about having to integrate an entire C++ compiler into the D compiler. Could the usage of libclang help here in having to avoid writing a new C++ compiler module or am I talking through my (non-existent) hat? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
char16_t and char32_t
In the following pages (which have differing file naming patterns for
whatever reason!):
http://dlang.org/interfaceToC.html
http://dlang.org/cpp_interface
I would suggest to add the info that wchar is compatible with the
char16_t and dchar with char32_t of C11. See:
http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Changes_from_C99
Currently wchar and dchar are marked as being compatible with wchar_t
depending on the sizeof(wchar_t). That's true, but I guess
char{16,32}_t provide a stable mapping.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: pop popFront combined
On Saturday, 1 November 2014 at 14:01:42 UTC, Nordlöw wrote: On Saturday, 1 November 2014 at 13:36:05 UTC, anonymous wrote: I don't see what you'd need inout for here. stealFront/stealBack are not methods. inout can be used on free functions aswell. See for example https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L674 Sure, but it doesn't buy you anything in these cases, does it? You can just drop inout from overlapInOrder. It's fully templated. T can be const/immutable and you get a const/immutable result. Works fine.
D int and C/C++ int etc not really compatible when interfacing to C/C++
In the following pages: http://dlang.org/interfaceToC.html http://dlang.org/cpp_interface the Data Type Compatibility section says D int is compatible with C/C++ int. Isn't this actually false because D's integer types are fixed-size whereas C/C++'s are variable? So D int is only compatible with C++ int32_t, and who knows what that is typedef-ed to? Likewise for uint, long, short etc. So how to ensure, when calling C/C++, that the D int etc are being mapped to the correctly-sized C/C++ type? Does the compiler ensure that since the compatibility is being advertised as built-in? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Problem with spec doc?
Hello. I already posted this via the forum interface: http://forum.dlang.org/thread/yqhwwpskwmkdefarj...@forum.dlang.org But for whatever reason I didn't get any replies so I worry if it actually reached people or not... -- Original message -- At http://dlang.org/spec.html I read: This is also available as a PDF document where PDF document is a link to http://dlang.org/dlangspec.pdf. However, the PDF is just as 4 page doc with only the TOC. The individual pages don't seem to have PDFs either. I hope this is not intentional. Can the full spec please be posted as a single PDF? Thanks. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Problem with spec doc?
On Saturday, 1 November 2014 at 15:02:44 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: Hello. I already posted this via the forum interface: http://forum.dlang.org/thread/yqhwwpskwmkdefarj...@forum.dlang.org But for whatever reason I didn't get any replies so I worry if it actually reached people or not... -- Original message -- At http://dlang.org/spec.html I read: This is also available as a PDF document where PDF document is a link to http://dlang.org/dlangspec.pdf. However, the PDF is just as 4 page doc with only the TOC. The individual pages don't seem to have PDFs either. I hope this is not intentional. Can the full spec please be posted as a single PDF? Thanks. This pull request may answer your question: https://github.com/D-Programming-Language/dlang.org/pull/687 Mike
Re: Problem with spec doc?
Thank you very much. But this is curious -- isn't Andrei himself able to directly commit or answer that pull request?!! -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: Problem with spec doc?
On Sat, Nov 01, 2014 at 09:18:19PM +0530, Shriramana Sharma via Digitalmars-d-learn wrote: Thank you very much. But this is curious -- isn't Andrei himself able to directly commit or answer that pull request?!! [...] Andrei appears to be very busy these days and rarely responds to PRs unless personally asked to. T -- Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be algorithms.
Re: Problem with spec doc?
On Saturday, 1 November 2014 at 15:48:27 UTC, Shriramana Sharma via Digitalmars-d-learn wrote: Thank you very much. But this is curious -- isn't Andrei himself able to directly commit or answer that pull request?!! All pull requests need to be peer reviewed, even those submitted by committers. Even if the pull request is merged, it won't appear on the website until it is published. From what I can tell, it appears the website is published with each release of DMD. Andrei was kind enough to post a link to a working copy of dlang.org on his own personal website. You should be able to obtain the PDF from there. Mike
Re: pop popFront combined
On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum
wrote:
If you want move semantics, use `moveFront`.
But x.moveFront doesn't modify x.
It does modify `x` as it leaves `front` in a destroyed and
default-initialized state, as required by move semantics.
What I want is to transform my uses of std.range from
if (!x.empty)
{
x.front.doStuff;
x.popFront;
}
into
if (!x.empty)
if (auto front = x.stealFront)
{
front.doStuff;
}
This is more functional/atomic, that is it reduces the risk of
accidentally forgetting to call popFront at the end.
Destroy!
The other half of my post explained why such a `stealFront` is
problematic.
compile w/ ms32coff fails with 2.067B1
Is it supposed to ? Is this feature planned for 2.067 ? error messages: ...\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module std.c.stdio import 'FHND_WCHAR' not found ...\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module std.c.stdio import 'FHND_TEXT' not found
Re: pop popFront combined
On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote: The other half of my post explained why such a `stealFront` is problematic. Got it. Thanks!
Re: pop popFront combined
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote: Sometimes after popping, the previous `front` is no longer valid, such as in the case of a buffer being reused. We should This seems like a error-prone design to me. I guess performance is the motivation right? Maybe a future data-flow analysis á lá Rust could come to the rescue here ;)
how to expand tuple?
Few questions. 1. In examples tuples are created with keyword auto. Can I create them with another keyword. Or auto mean structure of data, that have not standard type like (int or string)? 2. How ti expend tuple? I tried to do: auto imglist = tuple(aaa); imglist.expand[sss]; writeln(imglist); but got very strange error: app.d(30): Error: cannot implicitly convert expression (sss) of type string to uint
Re: pop popFront combined
On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote: Sometimes after popping, the previous `front` is no longer valid, such as in the case of a buffer being reused. Is there a suitable trait we can use to detect this and in turn use to disallow stealFront() and stealBack() in these cases? We should be careful about promoting using a previously read `front` after `popFront` until we figure out what we want to do about these transient ranges.
Re: pop popFront combined
On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote: problematic. What about turning stealFront and stealBack at https://github.com/nordlow/justd/blob/master/range_ex.d into mixins?
Re: how to expand tuple?
On Sat, Nov 1, 2014 at 9:34 PM, Suliman via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Few questions. 1. In examples tuples are created with keyword auto. Can I create them with another keyword. Or auto mean structure of data, that have not standard type like (int or string)? `tuple' is a function defined in the std.typecons module. It's a helper function to create Tuple!(T...), a templated struct acting as a tuple. Don't forget the type will depend on the types of the arguments, so: auto tup = tuple(1.0, abc, [2,3]); contains a float, a string and an array of int's, so it's type is Tuple!(float, string, int[]): Tuple!(float, string, int[]) tup = tuple(1.0, abc, [2,3]); It's a bit long to type, so most people prefer using `auto' for such declarations. 2. How ti expend tuple? I tried to do: auto imglist = tuple(aaa); imglist.expand[sss]; writeln(imglist); but got very strange error: app.d(30): Error: cannot implicitly convert expression (sss) of type string to uint Expand, you mean, as in appending to a tuple? It can be done, but it will create a new type. First, tup.expand gives you access to the 'raw' tuple ( a template parameter list, to be precise) underneath Tuple!(T...). The returned value can be indexed, sliced and its length is known at compile time. Continuing with my example: auto first = tup.expand[0]; // 1.0 auto slice = tup.expand[1..$]; // (abc, [2,3]) auto len = tup.expand.length; // 3, since tup has three elements. That explains the error you get: imglist.expand is a bit like a vector: it can be indexed, but with uint, not with a string. I thought you were expanding it, but to the compiler you were trying to index using a string. If you really want to append to a tuple, you must create a new variable, since the augmented tuple will have a different type: auto tup2 = tuple(tup.expand, 'd'); // tup2 == (1.0, abc, [2,3], 'd') The type of tup2 is then Tuple!(float, string, int[], char) Note that, in your case, as you're using only strings, an array of strings would probably be easier to use.
Re: how to expand tuple?
I thought you were expanding it Drat. *You* thought you were expanding it.
Re: D int and C/C++ int etc not really compatible when interfacing to C/C++
D claims compatibility with system C compiler, which usually have 32-bit int.
Re: compile w/ ms32coff fails with 2.067B1
http://forum.dlang.org/post/xqjosrzoswakjcdgq...@forum.dlang.org
Re: compile w/ ms32coff fails with 2.067B1
Oops, this: http://forum.dlang.org/post/vybptydvdxultfnfq...@forum.dlang.org
Re: Interfacing with C++
You can see http://wiki.dlang.org/DIP61 and linked discussions. Static and virtual functions probably work. Constructors and destructors probably don't. What's difficult is multiple inheritance. The information on C++ support is largely considered private to the compiler team.
Restrict Combination of moveFront and popFront to Suitable Element Types
As a follow-up question to http://forum.dlang.org/thread/jkbhlezbcrufowxtt...@forum.dlang.org?page=3#post-zyuqclyjitbhavemmwto:40forum.dlang.org discussing the motivation for a new range primitive stealFront that combines moveFront and popFront implemented at https://github.com/nordlow/justd/blob/master/range_ex.d#L14 I then wonder if there's a way to check, using a type-trait, whether the value returned from moveFront is safe to use after popFront has been called on it. If so I want to restrict stealFront/Back with this trait.
Re: pop popFront combined
On Saturday, 1 November 2014 at 20:48:45 UTC, Nordlöw wrote: Is there a suitable trait we can use to detect this and in turn use to disallow stealFront() and stealBack() in these cases? Made it a separate new question at http://forum.dlang.org/thread/onibkzepudfisxtri...@forum.dlang.org#post-onibkzepudfisxtrigsi:40forum.dlang.org
Re: how to expand tuple?
On 11/01/2014 01:34 PM, Suliman wrote: Or auto mean structure of data, that have not standard type like (int or string)? D is a strongly typed language, so every variable has its specific type. D also has type inference, meaning that we don't need to specify types explicitly. In theory, even the following could work: t = tuple(42, 1.5); and the type of t would be Tuple!(int, double). However, the syntax rules require a keyword before t. If t could be either one of the following, we could simply write: const t = ... immutable t = ... shared t = ... static t = ... The problem is when t is not either one of those. In that case auto comes to the rescue: auto t = ... Note that auto (meaning automatic storage duration) is actually redundant there but works well because it kind of means infer the type automatically. Hm. It is redundant even there because infer implies automatic :p. Ali
state of the art with Typedef
What are the known pitfalls of std.typecons.Typedef as of now? Things I know: Have to use a cookie string to get a proper unique type. Have to explicitly specify an init in order to specify a cookie. Doesn't support is keyword. Isn't nice to look at in error messages. Relies on optimisations to alias itself away. Are there any more?
Re: state of the art with Typedef
On Saturday, 1 November 2014 at 23:18:35 UTC, John Colvin wrote: Doesn't support is keyword. Another good use-case for allowing a user-defined operator for is.
How are theads, Tid and spawn related?
Ok, a newbie question ahead. I want to create new thread which calls given function with some parameters. Thus, I think spawn is the right function for me. However that functions returns Tid and not a Thread object. So I want to know how can I make a Thread object out of it. What I would like to achieve is to wait for spawned thread to finish its execution, that is join with main thread.
Re: compile w/ ms32coff fails with 2.067B1
On Saturday, 1 November 2014 at 21:12:58 UTC, Kagamin wrote: Oops, this: http://forum.dlang.org/post/vybptydvdxultfnfq...@forum.dlang.org Ok. I see. Each static library used by the source must be build manually with ms32coff, and even in the final version those lib wont be included because it's too much work for a too small audience. It makes sense indeed. Maybe a small wiki or manual html page could be added to explain this.
Re: shallow copy of const(Object)[]
On Saturday, November 01, 2014 10:30:05 anonymous via Digitalmars-d-learn
wrote:
On Saturday, 1 November 2014 at 00:08:23 UTC, Jonathan M Davis
via Digitalmars-d-learn wrote:
So, by shallow copy, you mean that you want an array that
contains the same
elements but is a new array?
yes
If that's what you want, just slice the array.
auto b = a[];
This is the same as `auto b = a;`.
Sure, they'll point to the same spot in memory still, but
because all of the
elements are const, you can't mutate them, so it really doesn't
matter. All it
affects is that because both arrays have the same block of
memory after them,
appending to one of them would make it so that appending to the
other would
force it to reallocate. For for most intents and purposes, you
essentially
have two different arrays.
Except I don't. The elements are not immutable, so they may be
pulled from under my feet from elsewhere. And more importantly,
`a` may refer to non-GC memory. Like the stack, for example:
class C
{
const(Object)[] objects;
this(const(Object)[] objects ...)
{
this.objects = objects;
}
}
C f()
{
return new C(new Object);
}
void main()
{
auto c = f();
auto o = c.objects[0];
f(); /* writing over the previous array */
assert(o is c.objects[0]); /* fails */
}
Okay. Dynamic arrays don't care what kind of memory backs them. If you have
auto b = a;
or
auto b = a[];
you end up with two different dynamic arrays which are slices of the same
memory. Appending to one does not affect the other, but as long as they're
slices of the same memory, then altering the elements of one will affect the
other, which is impossible if the element type is const or immutable. However,
if a were a const slice of an array of mutable elements
Object[] x;
const(Object)[] a = x;
then because that array has mutable elements, then mutating those elements
would mutate a and b. However, the type of memory that's backing the arrays is
irrelevant. It could be GC-allocated, or malloc-allocated, or even a static
array. The only 2 differences that you have if the memory is not GC-allocated
are
1. It is guaranteed that the extra capacity in the array is 0, meaning that
any append or reserve operations will reallocate and make it a GC-allocated
array, whereas a GC-allocated array could have extra capacity and avoid being
reallocated.
2. It's possible that the memory is freed, screwing up the dynamic array.
That's why slicing a static array or pointers should be @system. Slicing
pointers is, but unfortunately, slicing a static array is not currently
treated as being @system ( https://issues.dlang.org/show_bug.cgi?id=8838 ).
Regardless, it's up to the code that's doing the slicing to make sure that it
doesn't give the slice to anything that's going to keep it around beyond the
lifetime of the memory.
So, while I can see why having a dynamic array backed by a static one (or
malloc-ed memory) would make it so that you want to make sure that you've
copied the array's elements into a new block of memory, it's not actually
relevant to discussing how such a copy would be made.
If you want to make sure that a dynamic array refers to new memory and is not
a slice of another one, then you'd typically use dup or idup, and in almost
all cases, that's exactly what you want. However, you have the rather odd case
of trying to make sure that you end up with a new block of memory, but you're
dealing with an array of const reference types. Most of the time when dealing
with const, you're dealing with it, because the function took const so that it
could operate on both mutable and immutable types, and you wouldn't be trying
to create a new array from those values - doing so would then lock in const
instead of mutable or immutable, which tends to be limiting. It's generally
discouraged to keep stuff around as const beyond simply operating on it that
way to avoid having to duplicate code or to give code temporary access to
something without allowing it to mutate it.. And most functions that would
have to allocate a new array would be templated so that the original constness
could be retained (e.g. Foo[] or immutable(Foo)[]) rather than having to
allocate a const(Foo)[]. If Foo is a value type, then const(Foo)[] is
pointless anyway, because you've copied the elements. However, with Foo being
a reference type - as in your case - that's not going to work.
If you really do need to make a copy of the memory, then you're going to need
to actually end up with const(Object)[], because you can't convert
const(Object) to Object or immutable(Object)[] without doing a deep copy
(which is why dup and idup are failing for you). If we had cdup, then that
would presumably do what you want, but since in most cases, it would be
discouraged to be allocating a dynamic array of const elements (rather than
slicing it or allocating one with mutable or immutable elements), I
spawnProcess() not child?
Is there a way to spawn a process that won't be a child process,
because I can't seem to kill any processes created with
spawnProcess() It keeps giving me access denied for the processes
and it's necessary for me to kill a process, compile it and then
spawn it again.
Currently what I do is save the pid of the spawned process and
then call kill() using that pid then calling dmd which compiles
it again, but after first compilation and spawning of the process
I cannot do it again unless I restart the process that's handling
the compilation etc. so I would like to have the process that
updates to be a seperate process from the compiled process.
This is my code.
void end() {
if (lastPid)
kill(lastPid);
}
void clear() {
if (exists(processFolder)) {
foreach (string name;
dirEntries(processFolder, SpanMode.depth)) {
remove(name);
}
rmdir(processFolder);
}
}
void compile() {
if (lastPid)
end();
clear();
string[] cmd = [dmd.exe, -of ~ processFile, -m32];
foreach (string e; dirEntries(srcFolder, SpanMode.depth))
cmd ~= e;
auto pid = spawnProcess(cmd);
wait(pid);
lastPid = spawnProcess(processFile);
}
Then I call compile() for everytime I need to update.
I have been looking through various code in the documents and
google etc. but I cannot seem to achieve what I want. Is there no
simple way to create a process that isn't associated with any
processes using spawnProcess?
Re: How are theads, Tid and spawn related?
On 11/01/2014 04:32 PM, Neven wrote:
Ok, a newbie question ahead. I want to create new thread which calls
given function with some parameters. Thus, I think spawn is the right
function for me. However that functions returns Tid and not a Thread
object.
So I want to know how can I make a Thread object out of it. What I would
like to achieve is to wait for spawned thread to finish its execution,
that is join with main thread.
You don't need a Thread object to wait for a thread to finish. One
option is to wait for a specific message:
import std.concurrency;
struct Done
{}
void func(int i)
{
ownerTid.send(Done());
}
void main()
{
spawn(func, 42);
receiveOnly!Done();// -- Waiting for the Done message
}
Another option is to wait for all child threads by thread_joinAll():
import core.thread;
// ...
thread_joinAll();
The reason I suggest the above is because I don't know the answer to
your question. :)
Ali
