Re: How are theads, Tid and spawn related?
On 11/01/2014 11:13 PM, Sean Kelly wrote: > Note that thread_joinAll is called automatically when main exits Has that always been the case? I remember having to inject thread_joinAll() calls at the ends of the main()s of a couple of examples because of having trouble otherwise. Can I safely remove thread_joinAll()s if they are the last lines in main()? Ali
Re: How are theads, Tid and spawn related?
Note that thread_joinAll is called automatically when main exits, so if you just want to be sure that your spawned thread completes you don't have to do anything at all. The decision to obscure the Thread object in std.concurrency was deliberate, as it allows us to use more than just kernel threads for concurrency. The thread may even live in another process and the message sent via IPC. If you want to start an asynchronous task and wait for it to complete I suggest the method Ali outlines above. You can also create a Thread directly. What we should really have for this sort of thing is futures, but they don't exist yet. std.parallelism might be worth a look as well, since it has a task queue.
Re: How are theads, Tid and spawn related?
Note that thread_joinAll is called automatically when main exits, so if you just want to be sure that your spawned thread completes you don't have to do anything at all. The decision to obscure the Thread object in std.concurrency was deliberate, as it allows us to use more than just kernel threads for concurrency. The thread may even live in another process and the message sent via IPC. If you want to start an asynchronous task and wait for it to complete I suggest the method Ali outlines above. You can also create a Thread directly. What we should really have for this sort of thing is futures, but they don't exist yet. std.parallelism might be worth a look as well, since it has a task queue.
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
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: 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 slic
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.
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: 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.
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: 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
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: 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: compile w/ ms32coff fails with 2.067B1
Oops, this: http://forum.dlang.org/post/vybptydvdxultfnfq...@forum.dlang.org
Re: compile w/ ms32coff fails with 2.067B1
http://forum.dlang.org/post/xqjosrzoswakjcdgq...@forum.dlang.org
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: how to expand tuple?
> I thought you were expanding it Drat. *You* thought you were expanding it.
Re: how to expand tuple?
On Sat, Nov 1, 2014 at 9:34 PM, Suliman via Digitalmars-d-learn 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: 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: 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".
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. 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 ;)
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!
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 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.
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: 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?
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 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
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 ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
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 ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
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.
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 ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
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 ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: pop & popFront combined
On Saturday, 1 November 2014 at 13:54:31 UTC, Nordlöw wrote: 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? I guess we have to look at the assembler output to be sure. Is there a convenient way to do this in LDC?
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; Nice solution anyhow! 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
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: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: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: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? 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: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: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 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: 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, 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: 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: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: 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: string, char[], overloaded functions.
On Sat, 01 Nov 2014 08:36:40 + via Digitalmars-d-learn 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: 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" 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