string-int[] array
Is it possible to create such an array in which you can store strings and numbers at the same time? string-int[] array = [4, five];
Re: Documentation confusion
On Sun, Mar 08, 2015 at 09:29:28PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: Hi, I just want to be sure that I'm not missing something, as I'm a bit confused: 1. The docs at http://dlang.org/phobos/ are not complete, right? Even not complete in that all runtime / phobos modules are listed with a comment no docs yet. I'm missing stuff like: import std.c.windows.windows; import core.sys.windows.dll; This is a defect in the documentation. Please file an issue at http://issues.dlang.org/. [...] 3. Then there is http://wiki.dlang.org which is the new wiki for http://www.prowiki.org/wiki4d , right? Was all content moved / copied to the new wiki? And the old wiki is read-only now? Why not just use a redirection then? [...] I don't know the reason it's not just a redirection, but wiki.dlang.org is now the official wiki. T -- If you compete with slaves, you become a slave. -- Norbert Wiener
Re: string-int[] array
On Sunday, 8 March 2015 at 18:05:33 UTC, Dennis Ritchie wrote: Is it possible to create such an array in which you can store strings and numbers at the same time? string-int[] array = [4, five]; As there's no mention of performance, what's wrong with a plain old string array with a bit of conversion and error checking? string[] soup = [4, Test, 5, More Test];
Re: Template pred is true for pred!(pred!(pred)) but not for value true
On Sunday, 8 March 2015 at 20:36:34 UTC, anonymous wrote:
I get an error on your code: test.d(16): Error: static assert
(canBeAlias!(true)) is false. But when commenting out the
first assert (line 15), there's no error.
Hmm, I might have made a mistake reducing my actual code.
Played around with it, and I think it's a bug in the compiler:
/* The differently numbered 'canBeAliasN' are all the same. */
enum true_ = true;
enum canBeAlias1(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias1!true); /* false */
enum canBeAlias2(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias2!true_); /* true */
enum canBeAlias3(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias3!true, , canBeAlias3!true_); /*
false false */
enum canBeAlias4(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias4!true_, , canBeAlias4!true); /* true
true */
On their own, `canBeAlias!true` = false and `canBeAlias!true_`
= true. This makes sense, because `true_` is a symbol whereas
`true` is a value.
But the two instantiations are apparently recognized as
equivalent. Whichever is instantiated first, its value is used
for the other instantiation, too. I think this behaviour is
wrong.
Yeah, definitely wrong.
template canBeAlias(T...)
if (T.length == 1)
{
static if (is(typeof({alias _ = T[0];})))
{
enum canBeAlias = true;
}
else
{
enum canBeAlias = false;
}
}
void main()
{
pragma(msg, canBeAlias!canBeAlias); //prints true
static assert(canBeAlias!(canBeAlias!canBeAlias)); //passes?!
static assert(!canBeAlias!true); //Error: static
assert(!true) is false
}
OR
void main()
{
pragma(msg, canBeAlias!canBeAlias); //prints true
static assert(!canBeAlias!true); //passes
//Error: static assert (canBeAlias!(true)) is false
static assert(canBeAlias!(canBeAlias!canBeAlias));
}
So it definitely does depend on which comes first. This is a
weird bug...
Re: Template pred is true for pred!(pred!(pred)) but not for value true
On Sunday, 8 March 2015 at 21:17:31 UTC, Meta wrote:
Urgh, I'm all messed up now. The results in the second case are
correct, but the results in the first case are wrong, as
!canBeAlias!true should be !false, not !true.
I also get the same results with __traits(compiles, { alias _ =
T[0]; }).
Re: string-int[] array
On 2015-03-08 at 20:26, Meta wrote:
On Sunday, 8 March 2015 at 18:57:38 UTC, Kagamin wrote:
http://dpaste.dzfl.pl/2c8d4a7d9ef0 like this.
What in the world is that code doing? I'm having a hard time wrapping my head
around this.
It's a trick to reuse string internals to store an int.
A string is a struct with two values (length, ptr).
ivalue(i) is used to set ptr = i and length = 0.
Except that with this solution you will confuse empty strings with ints.
You could give such strings special treatment by replacing:
this(string s){ svalue=s; }
with:
this(string s){ svalue=s; if (!s.length) svalue =
cast(string)(cast(char*)0)[X..X]; }
// where X is some magic int value to mark that we are dealing with an
empty string,
you'd still be confused if someone actually wanted to store the X value.
Re: string-int[] array
http://dpaste.dzfl.pl/2c8d4a7d9ef0 like this.
Re: Template pred is true for pred!(pred!(pred)) but not for value true
On Sunday, 8 March 2015 at 21:11:12 UTC, Meta wrote:
Yeah, definitely wrong.
template canBeAlias(T...)
if (T.length == 1)
{
static if (is(typeof({alias _ = T[0];})))
{
enum canBeAlias = true;
}
else
{
enum canBeAlias = false;
}
}
void main()
{
pragma(msg, canBeAlias!canBeAlias); //prints true
static assert(canBeAlias!(canBeAlias!canBeAlias));
//passes?!
static assert(!canBeAlias!true); //Error: static
assert(!true) is false
}
OR
void main()
{
pragma(msg, canBeAlias!canBeAlias); //prints true
static assert(!canBeAlias!true); //passes
//Error: static assert (canBeAlias!(true)) is false
static assert(canBeAlias!(canBeAlias!canBeAlias));
}
So it definitely does depend on which comes first. This is a
weird bug...
Urgh, I'm all messed up now. The results in the second case are
correct, but the results in the first case are wrong, as
!canBeAlias!true should be !false, not !true.
Re: string-int[] array
On 2015-03-08 21:11:42 +, Paul said: On Sunday, 8 March 2015 at 18:05:33 UTC, Dennis Ritchie wrote: Is it possible to create such an array in which you can store strings and numbers at the same time? string-int[] array = [4, five]; As there's no mention of performance, what's wrong with a plain old string array with a bit of conversion and error checking? string[] soup = [4, Test, 5, More Test]; OP is fighting a loosing battle in flame war on some obscure forum. F# enthusiast trolls OP into solving stupid puzzles that are trivial in F# (or any ML-family language) and clumsy in C-family languages. In language holy wars the only winning move is not to play.
Re: Template pred is true for pred!(pred!(pred)) but not for value true
On Sunday, 8 March 2015 at 15:41:23 UTC, Meta wrote:
template canBeAlias(T...)
if (T.length == 1)
{
static if (is(typeof({alias _ = T[0];})))
{
enum canBeAlias = true;
}
else
{
enum canBeAlias = false;
}
}
pragma(msg, canBeAlias!canBeAlias); //prints true
static assert(!canBeAlias!true); //passes
static assert(canBeAlias!(canBeAlias!canBeAlias)); //passes?!
What is going on here? `canBeAlias!canBeAlias` evaluates down
to true, so why is `canBeAlias!true` false when
`canBeAlias!(canBeAlias!canBeAlias)` is true?
I get an error on your code: test.d(16): Error: static assert
(canBeAlias!(true)) is false. But when commenting out the first
assert (line 15), there's no error.
Played around with it, and I think it's a bug in the compiler:
/* The differently numbered 'canBeAliasN' are all the same. */
enum true_ = true;
enum canBeAlias1(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias1!true); /* false */
enum canBeAlias2(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias2!true_); /* true */
enum canBeAlias3(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias3!true, , canBeAlias3!true_); /* false
false */
enum canBeAlias4(T...) = is(typeof({alias _ = T[0];}));
pragma(msg, canBeAlias4!true_, , canBeAlias4!true); /* true
true */
On their own, `canBeAlias!true` = false and `canBeAlias!true_` =
true. This makes sense, because `true_` is a symbol whereas
`true` is a value.
But the two instantiations are apparently recognized as
equivalent. Whichever is instantiated first, its value is used
for the other instantiation, too. I think this behaviour is wrong.
Re: string-int[] array
On Sunday, 8 March 2015 at 21:18:31 UTC, Max Klyga wrote: On 2015-03-08 21:11:42 +, Paul said: On Sunday, 8 March 2015 at 18:05:33 UTC, Dennis Ritchie wrote: Is it possible to create such an array in which you can store strings and numbers at the same time? string-int[] array = [4, five]; As there's no mention of performance, what's wrong with a plain old string array with a bit of conversion and error checking? string[] soup = [4, Test, 5, More Test]; OP is fighting a loosing battle in flame war on some obscure forum. F# enthusiast trolls OP into solving stupid puzzles that are trivial in F# (or any ML-family language) and clumsy in C-family languages. In language holy wars the only winning move is not to play. Yawn :D
Re: string-int[] array
On Sunday, 8 March 2015 at 21:18:31 UTC, Max Klyga wrote: OP is fighting a loosing battle in flame war on some obscure forum. F# enthusiast trolls OP into solving stupid puzzles that are trivial in F# (or any ML-family language) and clumsy in C-family languages. In language holy wars the only winning move is not to play. I have not played in a Holy war.
Re: is struct delete deterministic? (cf used in Unique)
On Sun, Mar 8, 2015 at 4:36 AM, Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Sunday, March 08, 2015 04:13:28 Jonathan M Davis via Digitalmars-d-learn wrote: On Saturday, March 07, 2015 17:20:49 Timothee Cour via Digitalmars-d-learn wrote: To clarify, I'm only asking about a struct allocated via new. Unique!T is wrapped around a struct, but it allocates a struct T via 'new', so my question still holds: does 'delete t' (where t is a struct allocated via new) guarantee deterministic destruction? I'm guessing yes, otherwise Unique would be broken, but where is that specified in the docs? And if delete is to be deprecated (according to the docs), what is the correct way to do that (despite fact that Unique relies on delete). Yes, delete is deterministic. It's basically the same as what you get in C++ except that it's using the GC heap and therefore is not safe. delete is supposed to have been deprecated but has not been yet (mostly because no one has gotten around to doing it). If you're using the GC heap and want to destroy an object, that's what destroy is for - but it doesn't free the memory, because that's not safe. You can free the memory with core.memory.GC.free, but you have to have destroyed the object first, since free just frees memory. But that's just duplicating what delete does, so it's still unsafe. What's generally considered the correct way to deal with manual memory management involves allocating using C's malloc, constructing via emplace, and then using destroy and C's free to destroy the object and free its memory when you're done. But that's way more of a pain then using new and then delete, which is probably part of why some folks still use delete (in the case of Unique though, I expect that it's just because it's been around a while). Hopefully, the standard allocator stuff will make it as simple as using new and delete though - e.g. something like auto ptr = alloc.make!Myobj(arg1, arg2); alloc.free(ptr); but the standard allocator stuff isn't currently far enough along yet for us to be at that point unfortunately. I would point out though that until recently, the GC never ran the destructors for structs on the heap, because it didn't have the type information to do it. So, if you did auto s = new MyStruct; its destructor never ran, even if the GC collected it (which it's not guaranteed to do with any memory). But I don't know if the destructor was run if you expliictly called delete on the pointer to the struct. Thanks for you answers, however this last sentence worries me. According to it there's no guarantee then? However, there has recently been work done to make it so that struct destructors on the heap _are_ run when a struct is collected by the GC, so the situation there is improving, and if delete didn't call the destructor before, it probably will with the next release. - Jonathan M Davis
Strange behavior of the function find() and remove()
This is normal behavior?
import std.stdio;
import std.algorithm;
void main() {
auto a = [3, 5, 8];
writeln(find(remove(a, 1), 5).length != 0); // prints false
writeln(a); // prints [3, 8, 8] ???
}
Re: string-int[] array
On Sunday, 8 March 2015 at 21:41:44 UTC, FG wrote:
On 2015-03-08 at 20:26, Meta wrote:
On Sunday, 8 March 2015 at 18:57:38 UTC, Kagamin wrote:
http://dpaste.dzfl.pl/2c8d4a7d9ef0 like this.
What in the world is that code doing? I'm having a hard time
wrapping my head around this.
It's a trick to reuse string internals to store an int.
A string is a struct with two values (length, ptr).
ivalue(i) is used to set ptr = i and length = 0.
Except that with this solution you will confuse empty strings
with ints.
You could give such strings special treatment by replacing:
this(string s){ svalue=s; }
with:
this(string s){ svalue=s; if (!s.length) svalue =
cast(string)(cast(char*)0)[X..X]; }
// where X is some magic int value to mark that we are
dealing with an empty string,
you'd still be confused if someone actually wanted to store the
X value.
Oh, I see. What was tripping me up was
`svalue=cast(string)(cast(char*)0)[i..i];`
But I see now that it's just creating an empty string.
Dub + Optlink == ???
Since DDT (Eclipse plugin) uses Dub, I am trying to convert the DWT
build instructions into Dub. Here is my current attempt:
{
name : foo,
description : foo,
importPaths : [ d:/workspace/dwt/imp ],
stringImportPaths : [
D:/workspace/dwt/org.eclipse.swt.win32.win32.x86/res ],
lflags : [
-L+D:/workspace/dwt/lib,
-L/SUBSYSTEM:WINDOWS:4.0
],
libs : [
org.eclipse.swt.win32.win32.x86,
dwt-base
]
}
Unfortunately, this fails:
...
OPTLINK : Warning 9: Unknown Option : WORKSPACE
OPTLINK : Warning 9: Unknown Option : DWT
OPTLINK : Warning 9: Unknown Option : LIB
org.eclipse.swt.win32.win32.x86.lib
Warning 2: File Not Found org.eclipse.swt.win32.win32.x86.lib
dwt-base.lib
Warning 2: File Not Found dwt-base.lib
...
If I could figure out how to properly pass linker arguments in Dub, I
think I could get this to work. Clearly, I am doing something wrong,
but I don't know what. Any clues?
Dave
Re: Strange behavior of the function find() and remove()
On Sunday, 8 March 2015 at 21:34:25 UTC, Dennis Ritchie wrote: This is normal behavior? Yes it is normal, there are two potential points of confusion: - remove mutates the input range and returns a shortened slice to the range which excludes the removed element. - remove takes an index as its second argument, not an element. For more information see: https://issues.dlang.org/show_bug.cgi?id=10959
Re: Strange behavior of the function find() and remove()
On Sunday, 8 March 2015 at 21:58:20 UTC, safety0ff wrote: On Sunday, 8 March 2015 at 21:34:25 UTC, Dennis Ritchie wrote: This is normal behavior? Yes it is normal, there are two potential points of confusion: - remove mutates the input range and returns a shortened slice to the range which excludes the removed element. - remove takes an index as its second argument, not an element. For more information see: https://issues.dlang.org/show_bug.cgi?id=10959 Thanks.
Re: Dub + Optlink == ???
On 3/8/2015 3:55 PM, David Held wrote:
Since DDT (Eclipse plugin) uses Dub, I am trying to convert the DWT
build instructions into Dub. Here is my current attempt:
{
name : foo,
description : foo,
importPaths : [ d:/workspace/dwt/imp ],
stringImportPaths : [
D:/workspace/dwt/org.eclipse.swt.win32.win32.x86/res ],
lflags : [
-L+D:/workspace/dwt/lib,
-L/SUBSYSTEM:WINDOWS:4.0
],
libs : [
org.eclipse.swt.win32.win32.x86,
dwt-base
]
}
[...]
Figured it out. Even though lflags is a string[], the strings get
concatenated with no spaces. :/ This works:
lflags : [
-L+..\\dwt\\lib\\ -L/SUBSYSTEM:WINDOWS:4.0
],
Dave
Re: Strange behavior of the function find() and remove()
On Sunday, 8 March 2015 at 21:34:25 UTC, Dennis Ritchie wrote:
This is normal behavior?
import std.stdio;
import std.algorithm;
void main() {
auto a = [3, 5, 8];
writeln(find(remove(a, 1), 5).length != 0); // prints false
writeln(a); // prints [3, 8, 8] ???
}
Yes, works as designed. `remove` writes over removed slots and
returns shrunk (shrinked?) slice. It does not shrink the range at
the call site. To update `a`, write the result of `remove` to it:
writeln(find(a = remove(a, 1), 5).length != 0); // still false
writeln(a); // prints [3, 8]
Re: is struct delete deterministic? (cf used in Unique)
On Sunday, March 08, 2015 14:04:52 Timothee Cour via Digitalmars-d-learn wrote: On Sun, Mar 8, 2015 at 4:36 AM, Jonathan M Davis via Digitalmars-d-learn I would point out though that until recently, the GC never ran the destructors for structs on the heap, because it didn't have the type information to do it. So, if you did auto s = new MyStruct; its destructor never ran, even if the GC collected it (which it's not guaranteed to do with any memory). But I don't know if the destructor was run if you expliictly called delete on the pointer to the struct. Thanks for you answers, however this last sentence worries me. According to it there's no guarantee then? Previously, struct destructors were _never_ run by the GC, because it didn't have the required type information. What I don't know is whether delete called a struct's destructor or not. But if it didn't, then it never did. There was no maybe about it. Either it always did, or it never did. I just don't know which it is, because I haven't really used delete, and I don't recall anyone discussing whether delete had the same problem that the GC does when it runs (I'd guess not, but I'd have to test it). With the upcoming release, however, it's been changed so that struct destructors _do_ get called by the GC, which would presumably make it so that delete calls the struct's destructor if it didn't before. I guess that I can just revert my dmd to an older release and see what happens there (I'm normally sitting on master)... Yeah. delete calls the struct's destructor even though the GC doesn't. And there's nothing non-deterministic about it. The GC isn't guaranteed to collect something (so even with the recent changes with regards to structs, there's still no guarantee that their destructors will be run), but delete is, since you're explicitly telling it to. It was just a question of whether delete had the same problem that the GC did and couldn't run the struct's destructor. But fortunately, that doesn't seem to be the case. - Jonathan M Davis
