Re: D threading and shared variables
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote: This generally works OK when tied to a Console but when link options are changed to be SUBSYSTEM:WINDOWS and ENTRY:mainCRTStartup it rarely does. Manually setting the entry point sounds problematic if no other precautions are taken. Are you sure that druntime is initialized? See [1]. - Johan [1] https://wiki.dlang.org/D_for_Win32
Re: D threading and shared variables
On Sunday, 7 April 2019 at 17:52:40 UTC, Mike Wey wrote:
How are you using the GUI, GTK is not thread safe, all gui
function calls should be made from the GUI thread.
Last time i checked threadsEnter and threadsLeave didn't work
properly on windows.
All GUI updates are sent from a worker thread to the GUI thread
using the D message passing system and immutable object
arguments. I'm pretty satisfied it's not a problem.
The general principle of the classes doing the comms are:
class name :Thread
{
Mutex m;
Condition sig;
shared char[] shared_buffer;
CommunicationClass comm;
this()
{
m = new Mutex;
sig = new Condition(m);
comm = new CommunicationClass;
super(&receive_thread);
start();
}
//the main routine being called
void packet_transaction()
{
comm.send_data();
synchronized(m)
{
if (sig.wait(dur!("seconds")(1)) == true)
do_something();
else
do_timeout();
}
}
void receive_thread()
{
local_buffer;
while(true)
{
local_buffer += comm.get_data();
if (some condition)
{
synchronized(m)
{
copy local_buffer to shared_buffer;
sig.notify();
}
}
}
}
};
Re: Iterate/sort associative array by value?
On 04/07/2019 08:41 AM, Robert M. Münch wrote:
> I have an AA int[ulong] and would like to traverse the AA from biggest
> to smallest by value. Is there an elegant way to do this?
Because associative array is a data structure to use when the order is
not important, it comes down to getting the values and then sorting.
Since there is already a .values that returns a copy of the values, I
would just sort that one:
auto arr = aa.values;
sort(arr);
use(arr);
I think that method might be faster than others because .values is
provided by the AA implementation but I shouldn't say that without
testing. :) So, with dmd v2.085.0, .values is 4 times faster than .byValues:
import std.algorithm;
import std.stdio;
import std.array;
import std.range;
import std.typecons;
import std.format;
enum aaElementCount = 100_000;
enum testCount = 100;
ulong expectedResult;
// So that the whole operation is not optimized out
void use(int[] aa) {
const result = aa.sum;
if (expectedResult == 0) {
expectedResult = result;
}
// Make sure that all methods produce the same result
assert(expectedResult != 0);
assert(result == expectedResult, format!"%s != %s"(result,
expectedResult));
}
void main() {
auto aa = aaElementCount.iota.map!(i => tuple(i, i)).assocArray();
import std.datetime.stopwatch;
auto measurements = benchmark!(
{
auto arr = aa.byValue.array;
// sort(arr);
use(arr);
},
{
auto arr = aa.values;
// sort(arr);
use(arr);
},
)(testCount);
writefln("%(%s\n%)", measurements);
}
450 ms, 424 μs, and 8 hnsecs<-- .byValue.array
108 ms, 124 μs, and 6 hnsecs<-- .values
Of course the difference is much less when we comment-in the sort() lines.
Ali
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 18:22:00 UTC, Robert M. Münch wrote:
On 2019-04-07 17:16:12 +, Seb said:
Then you can do:
---
["a": 1].byPair.array.sort!((a, b) => a.value <
a.value).release.each!writeln;
---
You'll have a sorted array with key and value props.
This seems to be really tricky:
int[uint] myArray;
foreach(key, value; myArray.byPair.array.sort!((a, b) =>
a.value < a.value)){...}
Error: no property sort for type Tuple!(uint, "key", int,
"value")[]
You forgot to import std.algorithm.
In doubt, use std.experimental.all or with 2.086 it will just be
`import STD;`
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 20:02:15 UTC, Seb wrote:
On Sunday, 7 April 2019 at 18:22:00 UTC, Robert M. Münch wrote:
On 2019-04-07 17:16:12 +, Seb said:
Then you can do:
---
["a": 1].byPair.array.sort!((a, b) => a.value <
a.value).release.each!writeln;
---
You'll have a sorted array with key and value props.
This seems to be really tricky:
int[uint] myArray;
foreach(key, value; myArray.byPair.array.sort!((a, b) =>
a.value < a.value)){...}
Error: no property sort for type Tuple!(uint, "key", int,
"value")[]
You forgot to import std.algorithm.
In doubt, use std.experimental.all or with 2.086 it will just
be `import STD;`
*import std;
(auto-correct from my phone was too eager.)
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 18:22:00 UTC, Robert M. Münch wrote: Error: no property sort for type Tuple!(uint, "key", int, "value")[] Did you import it? import std.algorithm;
Re: Iterate/sort associative array by value?
On 2019-04-07 17:16:12 +, Seb said:
Then you can do:
---
["a": 1].byPair.array.sort!((a, b) => a.value < a.value).release.each!writeln;
---
You'll have a sorted array with key and value props.
This seems to be really tricky:
int[uint] myArray;
foreach(key, value; myArray.byPair.array.sort!((a, b) => a.value <
a.value)){...}
Error: no property sort for type Tuple!(uint, "key", int, "value")[]
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Iterate/sort associative array by value?
On 2019-04-07 17:35:23 +, bauss said: Import std.array :-/ Thanks... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D threading and shared variables
On 07-04-2019 16:49, Archie Allison wrote: The codebase is a reasonable size so too big (and proprietary) to share. It's always run with a GUI (GTKD), it's just the difference in linking so launching (a)GUI + attached console for stdout.writeln vs. (b)just the GUI window. There's nothing I'd expect to cause races or deadlocks. How are you using the GUI, GTK is not thread safe, all gui function calls should be made from the GUI thread. Last time i checked threadsEnter and threadsLeave didn't work properly on windows. -- Mike Wey
Re: Overloads not returning appropriate info. [Field reflunkory]
On Sunday, 7 April 2019 at 15:35:46 UTC, FeepingCreature wrote: On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote: rules are meant to be broken. No they're not! Almost by definition not! More comprehensively, if you break a rule you take responsibility for the outcome. You wanna use stringof? "Don't use stringof for that." "rules are meant to be broken." -- "Wah, my code doesn't work, stringof is shit, bad design, fix D pls." Don't ask questions if you don't care about the answers. More importantly, don't ignore advice and then complain about it. You are a moron. Almost by definition? Here is some advice, don't be a pscyhopath. You come in to a thread without any desire to help in any way but to throw your 2c's and pretend you have something useful to say. You really are an idiot. The problems I faced had nothing to do with stringof. I did a search and replace and replaced ALL instances and the EXACT same code and issues were generated. That alone proves you are a moron. You can't expect to lead by authority. Give a good reason why I should avoid it and change my current ways and I will. Your code will break in surprising and unfixable ways. `stringof` is not *for* mixin. If you use it for mixin, you will be on your own design-wise. The language will not be changed to "fix" the "bugs" you run into. It will work until it won't work, and then you'll have to rewrite the entire thing anyway. Don't use stringof for mixin. go screw yourself. Please don't EVER respond to me again. I will ignore ALL your replies. I don't give a shit about your "advice". You clearly have no idea what you are talking about but have some need to act like an authority. I just hope you don't have a badge and a gun... People like you end up killing other people because they don't do shit the way you think they should. I'm just wondering if your that Adam guy... kinda fishy you both show up spouting the same BS and don't even back up your claims and when I say prove your claim by an example you spout the same BS. Morons make claims, experts prove them, neither of you have proven anything but you have made a lot of claims. It amazes me people like you freely exist in the world. Again, LEAVE ME ALONE! But I bet you won't! Psychopaths like yourself just can't shut the fuck up when told to go away.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Sunday, 7 April 2019 at 15:26:47 UTC, Adam D. Ruppe wrote: On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote: What you need to tell me is why using .stringof is bad. You have simply conjured up a rule and are stating it but not giving any reason why it is not a good idea to follow when, in fact, not following can be shown to be beneficial. You can't expect to lead by authority. Give a good reason why I should avoid it and change my current ways and I will. I have a couple times times now. https://forum.dlang.org/post/nvpsrxxkfmbbxognj...@forum.dlang.org https://forum.dlang.org/post/fahrmmocegtthztzg...@forum.dlang.org I go into a lot of detail in the link on the second link. And the pains you are personally experiencing are a direct result of stringof. If you were to actually following my rule, you'd learn by doing how much better it is. That is blatantly wrong. The code works EXACTLY the same way with and without using stringof. You have not stated one type the reason why T string of is bad, you have just stated that it is bad, that is totally different. I have removed all T.stringof's in the code and I still get the exact same errors. Your assessment that all the errors are due to T.stringof is wrong. You need to provide code where using T directly works but T.stringof fails. I did a search and replace for all the T.stringof's and the code produced the exact same output, so to say that is the source of all my problems is BS, and since I have already fixed most of the problems(the main ones of inout and protection still exist) after that, it shows that it had nothing to do with it. I'm not saying it is a good idea, what I'm saying is that you haven't yet given any proof why it is a bad idea. Those links are you just stating it is bad. If you want this not to be a waste of both of our times, next time post an example code that demonstrates the problem. So it seems like the same design flaw exists? Have any work arounds for that? It won't work for private, you can use static if __traits(compiles) as a filter to get rid of them. That doesn't help. It is compile time, one should be able to get the information. It is pointless to exclude it at CT because one could just open the source if there was anything to "hide". Protection is a runtime thing(except for CTFE).
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 16:44:01 UTC, Robert M. Münch wrote: On 2019-04-07 16:24:52 +, Cym13 said: You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a] That doesn't work: Error: no property array for type Result With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with? At the point where I need this sorted array, nothing will change it. It's a log output. So, not necessary to make things more complex. Import std.array
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 16:44:01 UTC, Robert M. Münch wrote: On 2019-04-07 16:24:52 +, Cym13 said: You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a] That doesn't work: Error: no property array for type Result With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with? At the point where I need this sorted array, nothing will change it. It's a log output. So, not necessary to make things more complex. Then you can do: --- ["a": 1].byPair.array.sort!((a, b) => a.value < a.value).release.each!writeln; --- You'll have a sorted array with key and value props.
Re: == comparison of string literals, and their usage
Le 07/04/2019 à 14:23, bauss via Digitalmars-d-learn a écrit :
On Saturday, 6 April 2019 at 19:47:14 UTC, lithium iodate wrote:
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers myself [1], and
get valid results, meaning: pointer equality implies (literal) string
equality. Or am I wrong? The point is, the parser, operating on an array of
prescanned lexemes, will constantly check whether a valid lexeme is present
simply by checking the lexeme "class". I don't want that to be a real string
comp, too expesensive and for no gain.
[1] As in the second comp of your example:
void main()
{
auto c2 = "one" == "two";
auto c1 = "one".ptr is "two".ptr;
}
Not quite. D-strings strictly consist of pointer *and* length, so you need to
compare the .length properties as well to correctly conclude that the strings
equal. You can concisely do that in one go by simply `is` comparing the array
references as in
string a = "hello";
string b = a;
assert(a is b);
assert(a[] is b[]);
Of course, if the strings are never sliced, you can just compare the pointers
and be done, just make sure to document how it operates. Depending on the
circumstances I'd throw in some asserts that do actual strings comparison to
verify the program logic.
To add onto this.
Here is an example why it's important to compare the length as well:
string a = "hello";
string b = a[0 .. 3];
assert(a.ptr == b.ptr);
assert(a.length != b.length);
Thank you! Very clear :-).
--
diniz {la vita e estranj}
Re: What's the correct way to interface with a intptr_t?
On Sunday, 7 April 2019 at 13:45:15 UTC, Paul Backus wrote: On Sunday, 7 April 2019 at 12:19:10 UTC, bauss wrote: On Saturday, 6 April 2019 at 20:16:06 UTC, Paul Backus wrote: On Saturday, 6 April 2019 at 19:31:15 UTC, Robert M. Münch wrote: I have a C interface that uses a parameter of type intptr_t. Wondering if size_t is the correct D equivalent? The correct equivalent is `intptr_t` from `core.stdc.stdint`. Which is just an alias for ptrdiff_t. Unless this is guaranteed to be the case on every platform druntime is ever ported to, it is technically better to use the `intptr_t` alias. It should be guaranteed since it's just supposed to be a signed integer of either 32 bit or 64 bit depending on the architecture you're on. D isn't supported below 32 bit systems so it's irrelevant there and thus it can be a guarantee.
Re: Iterate/sort associative array by value?
On 2019-04-07 16:24:52 +, Cym13 said: You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a] That doesn't work: Error: no property array for type Result With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with? At the point where I need this sorted array, nothing will change it. It's a log output. So, not necessary to make things more complex. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Iterate/sort associative array by value?
On Sunday, 7 April 2019 at 15:41:51 UTC, Robert M. Münch wrote: I have an AA int[ulong] and would like to traverse the AA from biggest to smallest by value. Is there an elegant way to do this? The only way I can imagine is to create an "reverse" AA of the form ulong[int] and than sort by keys. Traverse this AA and use the value as the lookup key in the orginial array. But this feels all a bit wired... You could use sort to gather the indexes in order then traverse from there: aa.byKey.array.sort!((a, b) => aa[a]With a wrapper caching that order and making it transparent as well as update on insertion (which should be in log(n) since you know have an ordered list of indexes, you can use dichotomy to update the indexes without walking all your AA again) I think you could have a nice little container. However if double entry is necessary maybe a simpler 2D array would be easier to work with?
Re: Alias to struct memembers of a function paramater as a shortcut => need this for XYZ of type void*
On 07.04.19 17:36, Robert M. Münch wrote: The docs state that an alias can either be related to the type or the symbol. Hence, in my case I expected it to be the symbol... The symbol is `X.a`. A field of an instance doesn't make a distinct symbol.
Iterate/sort associative array by value?
I have an AA int[ulong] and would like to traverse the AA from biggest to smallest by value. Is there an elegant way to do this? The only way I can imagine is to create an "reverse" AA of the form ulong[int] and than sort by keys. Traverse this AA and use the value as the lookup key in the orginial array. But this feels all a bit wired... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Overloads not returning appropriate info. [Field reflunkory]
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote: rules are meant to be broken. No they're not! Almost by definition not! More comprehensively, if you break a rule you take responsibility for the outcome. You wanna use stringof? "Don't use stringof for that." "rules are meant to be broken." -- "Wah, my code doesn't work, stringof is shit, bad design, fix D pls." Don't ask questions if you don't care about the answers. More importantly, don't ignore advice and then complain about it. You can't expect to lead by authority. Give a good reason why I should avoid it and change my current ways and I will. Your code will break in surprising and unfixable ways. `stringof` is not *for* mixin. If you use it for mixin, you will be on your own design-wise. The language will not be changed to "fix" the "bugs" you run into. It will work until it won't work, and then you'll have to rewrite the entire thing anyway. Don't use stringof for mixin.
Re: Alias to struct memembers of a function paramater as a shortcut => need this for XYZ of type void*
On 2019-04-07 14:05:13 +, ag0aep6g said: You can't make an alias to a field of an object. The alias will be made in relation to the type instead. (If that makes sense. I'm not sure how to phrase it best.) The docs state that an alias can either be related to the type or the symbol. Hence, in my case I expected it to be the symbol... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Overloads not returning appropriate info. [Field reflunkory]
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote: What you need to tell me is why using .stringof is bad. You have simply conjured up a rule and are stating it but not giving any reason why it is not a good idea to follow when, in fact, not following can be shown to be beneficial. You can't expect to lead by authority. Give a good reason why I should avoid it and change my current ways and I will. I have a couple times times now. https://forum.dlang.org/post/nvpsrxxkfmbbxognj...@forum.dlang.org https://forum.dlang.org/post/fahrmmocegtthztzg...@forum.dlang.org I go into a lot of detail in the link on the second link. And the pains you are personally experiencing are a direct result of stringof. If you were to actually following my rule, you'd learn by doing how much better it is. So it seems like the same design flaw exists? Have any work arounds for that? It won't work for private, you can use static if __traits(compiles) as a filter to get rid of them.
Re: Overloads not returning appropriate info. [Field reflunkory]
On 4/6/19 11:47 PM, Alex wrote: > What you need to tell me is why using .stringof is bad. You have simply > conjured up a rule and are stating it but not giving any reason why it > is not a good idea to follow when, in fact, not following can be shown > to be beneficial. I'm not Adam, but I've also run into problems with .stringof, and have found avoiding it to be a good idea in a lot of situations. The problem with .stringof and string mixins is that types and symbols carry information about their context with them--what module they're from, what scope they're defined in, etc. This is why, for example, you can pass a type defined in module a to a template defined in module b and have it work without needed to add `import a` to module b. When you convert a type or symbol to a string using .stringof, all of this context information is stripped away. And in many cases, once that information has been lost, it's impossible to recover. For example, if all you have is the string "S", and two modules in your program define a `struct S`, there's no way to know which one of those types your string refers to. If you say, "fine, I'll just use fully-qualified names," well, that doesn't work either, because some types in D don't *have* externally-visible names [1]. If you convert a type like that to a string, you can never get the original type (with its context info) back, no matter what you do. All that said, it's perfectly fine to use .stringof for debugging and custom error messages. But if you're using it to generate code, you are almost certainly making a mistake. [1] https://wiki.dlang.org/Voldemort_types
Re: Easiest way to use Linux system C files / tiny C libraries
On 3/29/19 7:52 PM, H. S. Teoh wrote: On Fri, Mar 29, 2019 at 10:48:47PM +, Chris Katko via Digitalmars-d-learn wrote: ...> There are probably other similar gotchas, but these are the ones off the top of my head. Feel free to ask if you're having trouble correctly translating something from C. If all else fails, run the header through a C processor and inspect the output to find out what the *real* definition of something is, if the original C source is so obfuscated you can't easily tell otherwise. Sorry I'm late to the party but another one that we have come across quite a bit is in function signatures: C: const char *stringparam D: const(char)* stringparam Best wishes
Re: D threading and shared variables
On Sunday, 7 April 2019 at 14:35:24 UTC, Doc Andrew wrote: When you say it "rarely works" when run as a GUI app (vs console), it makes me think that there's probably a race condition going on, and the extra context switching that takes place in GUI mode makes it more likely. I haven't tried it in D, but you may be able use Application Verifier with your app to add checks for lock contention. Without more information about the way your threads are synchronized it's hard to say for sure though. The codebase is a reasonable size so too big (and proprietary) to share. It's always run with a GUI (GTKD), it's just the difference in linking so launching (a)GUI + attached console for stdout.writeln vs. (b)just the GUI window. There's nothing I'd expect to cause races or deadlocks.
Re: Error: template instance `Reflect!(type)` cannot use local `type` as parameter to non-global template `Reflect(Ts...)()`
On 4/7/19 1:30 AM, Nicholas Wilson wrote: > On Sunday, 7 April 2019 at 05:24:38 UTC, Alex wrote: >> Error: template instance `Reflect!(type)` cannot use local `type` as >> parameter to non-global template `Reflect(Ts...)()` >> >> mixin(`import `~moduleName!(T)~`;`); >> mixin(`alias X = T.`~name~`;`); >> super.Reflect!(X); >> >> I realize X is local but I'm trying to figure out why it can't be >> passed to a "non-global" template. > > See > https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/ > > > TL;DR > > At global scope > alias Identity(alias X) = X; > > then where the error is issued from use `Identity!(type)` instead of type. This template is actually in Phobos now, as `std.meta.Alias`.
Re: D threading and shared variables
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote: I have written an industrial control program which uses serial ports to communicate with hardware but am having problems, perhaps with shared memory, on Windows. The SerialPort class calls C object-file functions. Transmits are on one thread and receives on another (all within a class derived from Thread), with a signal(created from a mutex) notifying the transmit thread when a packet has arrived. This generally works OK when tied to a Console but when link options are changed to be SUBSYSTEM:WINDOWS and ENTRY:mainCRTStartup it rarely does. Compiling with -vtls shows the serial port is in thread local storage. As a hardware resource, I wasn't sure if this matters. I've tried casting to a shared object so it no longer appears in the -vtls list, with no difference. Does anyone have ideas about where I may have misunderstood the threading and shared-memory design of D or what I can look at? When you say it "rarely works" when run as a GUI app (vs console), it makes me think that there's probably a race condition going on, and the extra context switching that takes place in GUI mode makes it more likely. I haven't tried it in D, but you may be able use Application Verifier with your app to add checks for lock contention. Without more information about the way your threads are synchronized it's hard to say for sure though.
Re: Alias to struct memembers of a function paramater as a shortcut => need this for XYZ of type void*
On 07.04.19 14:23, Robert M. Münch wrote:
struct X {
TYPE a;
TYPE b;
}
myFunc(X _struct){
alias a = _struct.a;
a = myOtherFunc();
}
X myStruct;
myFun(myStruct);
This gives an error: need this for a of type void*
I don't understand why, because all I want is a shortcut the symbol of
the parameter.
You can't make an alias to a field of an object. The alias will be made
in relation to the type instead. (If that makes sense. I'm not sure how
to phrase it best.)
In code, this:
alias a = _struct.a;
is the exact same as this:
alias a = X.a;
The instance `_struct` is not part of the alias.
D threading and shared variables
I have written an industrial control program which uses serial ports to communicate with hardware but am having problems, perhaps with shared memory, on Windows. The SerialPort class calls C object-file functions. Transmits are on one thread and receives on another (all within a class derived from Thread), with a signal(created from a mutex) notifying the transmit thread when a packet has arrived. This generally works OK when tied to a Console but when link options are changed to be SUBSYSTEM:WINDOWS and ENTRY:mainCRTStartup it rarely does. Compiling with -vtls shows the serial port is in thread local storage. As a hardware resource, I wasn't sure if this matters. I've tried casting to a shared object so it no longer appears in the -vtls list, with no difference. Does anyone have ideas about where I may have misunderstood the threading and shared-memory design of D or what I can look at?
Re: What's the correct way to interface with a intptr_t?
On Sunday, 7 April 2019 at 12:19:10 UTC, bauss wrote: On Saturday, 6 April 2019 at 20:16:06 UTC, Paul Backus wrote: On Saturday, 6 April 2019 at 19:31:15 UTC, Robert M. Münch wrote: I have a C interface that uses a parameter of type intptr_t. Wondering if size_t is the correct D equivalent? The correct equivalent is `intptr_t` from `core.stdc.stdint`. Which is just an alias for ptrdiff_t. Unless this is guaranteed to be the case on every platform druntime is ever ported to, it is technically better to use the `intptr_t` alias.
Re: == comparison of string literals, and their usage
On Saturday, 6 April 2019 at 19:47:14 UTC, lithium iodate wrote:
On Saturday, 6 April 2019 at 15:35:22 UTC, diniz wrote:
So, I still could store and use and compare string pointers
myself [1], and get valid results, meaning: pointer equality
implies (literal) string equality. Or am I wrong? The point
is, the parser, operating on an array of prescanned lexemes,
will constantly check whether a valid lexeme is present simply
by checking the lexeme "class". I don't want that to be a real
string comp, too expesensive and for no gain.
[1] As in the second comp of your example:
void main()
{
auto c2 = "one" == "two";
auto c1 = "one".ptr is "two".ptr;
}
Not quite. D-strings strictly consist of pointer *and* length,
so you need to compare the .length properties as well to
correctly conclude that the strings equal. You can concisely do
that in one go by simply `is` comparing the array references as
in
string a = "hello";
string b = a;
assert(a is b);
assert(a[] is b[]);
Of course, if the strings are never sliced, you can just
compare the pointers and be done, just make sure to document
how it operates. Depending on the circumstances I'd throw in
some asserts that do actual strings comparison to verify the
program logic.
To add onto this.
Here is an example why it's important to compare the length as
well:
string a = "hello";
string b = a[0 .. 3];
assert(a.ptr == b.ptr);
assert(a.length != b.length);
Alias to struct memembers of a function paramater as a shortcut => need this for XYZ of type void*
struct X {
TYPE a;
TYPE b;
}
myFunc(X _struct){
alias a = _struct.a;
a = myOtherFunc();
}
X myStruct;
myFun(myStruct);
This gives an error: need this for a of type void*
I don't understand why, because all I want is a shortcut the symbol of
the parameter.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: alias sequences of sequences
On Sunday, 7 April 2019 at 04:58:13 UTC, Alex wrote: Is there any way to get sequences of sequences? Using RT, I have to use strings [[`string`, `0`], ...] when it would be much better to use [[string, 0], ...] Ideally it wouldn't add so much overhead that it defeats the purpose. https://aliak00.github.io/bolts/bolts/meta/AliasPack.html
Re: What's the correct way to interface with a intptr_t?
On Saturday, 6 April 2019 at 20:16:06 UTC, Paul Backus wrote: On Saturday, 6 April 2019 at 19:31:15 UTC, Robert M. Münch wrote: I have a C interface that uses a parameter of type intptr_t. Wondering if size_t is the correct D equivalent? The correct equivalent is `intptr_t` from `core.stdc.stdint`. Which is just an alias for ptrdiff_t.
Re: § 28.3 Pointers and the Garbage Collector
On Sunday, 7 April 2019 at 10:17:53 UTC, AltFunction1 wrote: On Sunday, 7 April 2019 at 10:05:26 UTC, kdevel wrote: In § 28.3 Pointers and the Garbage Collector [1] we read Do not add or subtract an offset to a pointer such that the result points outside of the bounds of the garbage collected object originally allocated. [...] No the foo() code would work in D too but in D since we have a true array type with ptr+length you should not write this kind of code, which is not @safe BTW. I appreciate your constructive reply. What about the formal validity wrt. to the documentation? Is char *e = p + 10; outside of the bounds of the garbage collected object? Does for (q = p; q < e; ++q) depend on the ordering of pointers?
Re: § 28.3 Pointers and the Garbage Collector
On Sunday, 7 April 2019 at 10:05:26 UTC, kdevel wrote: In § 28.3 Pointers and the Garbage Collector [1] we read Do not add or subtract an offset to a pointer such that the result points outside of the bounds of the garbage collected object originally allocated. [...] No the foo() code would work in D too but in D since we have a true array type with ptr+length you should not write this kind of code, which is not @safe BTW.
§ 28.3 Pointers and the Garbage Collector
In § 28.3 Pointers and the Garbage Collector [1] we read
Do not add or subtract an offset to a pointer such that the
result points
outside of the bounds of the garbage collected object
originally allocated.
char* p = new char[10];
char* q = p + 6; // ok
q = p + 11; // error: undefined behavior
q = p - 1; // error: undefined behavior
C and C++ allow a pointer to point to the (non-existing) element
after the end
of the array:
char *e = p + 10;
Does this point "outside of the bounds of the garbage collected
object"?
In § 28.3 we also read
Do not depend on the ordering of pointers:
if (p1 < p2) // error: undefined behavior
...
since, again, the garbage collector can move objects around in
memory.
In C and C++ we are used to read code like this:
void foo ()
{
char *p = new char [10];
char *e = p + 10;
char *q;
for (q = p; q < e; ++q)
...
}
Does this for-loop "depend on the ordering of pointers"?
[1] https://dlang.org/spec/garbage.html#pointers_and_gc
Re: alias sequences of sequences
On 07.04.19 06:58, Alex wrote:
Is there any way to get sequences of sequences?
Using RT, I have to use strings
[[`string`, `0`], ...]
when it would be much better to use
[[string, 0], ...]
Ideally it wouldn't add so much overhead that it defeats the purpose.
You can make a template that doesn't expand the sequence automatically,
and then make a sequence of those:
template Box(stuff ...) { alias contents = stuff; }
import std.meta: AliasSeq;
alias s = AliasSeq!(Box!(string, 0), Box!(int, 42));
Instead of `s[0][0]`, you'd have to write `s[0].contents[0]`. Don't know
if that's too much overhead.
Re: CTFE & code generators based on PEG grammars?
On 07.04.19 05:32, Alex wrote:
readlin is not a CT function. You misinterpreted what I said.
Yeah, bad example from me. This would probably have been better:
auto v = "foo";
enum y = f(v); /* Error: variable v cannot be read at compile time */
Also, the `readln` example wasn't meant to contradict anything you said.
The one after it (`auto z = f("foo"); /* not CTFE */`) is supposed to
clarify your statement that "CTFE [happens] when the inputs are CT".
It's true that CTFE can only happen when the inputs are known at CT, but
that alone doesn't force CTFE.
[...]
If you think of it the way I have said and understand what it means then
it is much easier to understand CTFE because you really are just doing
"normal" programming of RT functions but you just execute them at CT if
possible(and the possibility simply is if the inputs are known at CT).
There's that same slight unclarity again. You may have the right
understanding of CTFE, but your phrasing is a bit misleading. CTFE
doesn't kick in whenever it's possible to precompute something at CT. It
only kicks in when the result is required at CT by language rules.
[...]
CTFE programming is RT
programming but where one can optimize before RT.
Optimization is not the only use for CTFE. It can also be used to
generate compile-time constants, like lengths for static arrays or D
code itself that is then mixed in. Can't do that stuff with run-time calls.
Re: CTFE & code generators based on PEG grammars?
On Sunday, 7 April 2019 at 06:39:05 UTC, zabruk wrote: On Sunday, 7 April 2019 at 03:32:45 UTC, Alex wrote: just execute them at CT if possible(and the possibility simply is if the inputs are known at CT). imho, Bastiaan Veelo want to say about citate above: not just "if possible", but "only if needed and possible" True, but the only if needed is vacuous. As the meta parser does it's thing it will come across RT function usage and it can easily tell if the arguments are known at CT and then will evaluate them. So, unless I'm mistaken about how the meta compiler works, it won't ever trigger CTFE on any CTFE'able functions that are not used. The reason being is that any time a function call is made, the arguments must be known(including hidden/global arguments) and if they are determined at CT already then a CT call can and must be made(that is what makes CTFE what it is). One can't CTFE if one doesn't have the inputs to the function... and the compiler doesn't just randomly compile RT functions without knowing the inputs... and the inputs are found at the use site. I don't even thing the "only if needed" makes a lot of sense. The only time they are needed is exactly when they are needed, there is no other use cause in CTFE. Can you give me a simple example that shows where a CTFE occurs that isn't needed and the compiler would try to CTFE it? By need, we mean with all optimizations, else CTFE is never needed.
Re: What's the correct way to interface with a intptr_t?
On 2019-04-06 20:16:06 +, Paul Backus said: On Saturday, 6 April 2019 at 19:31:15 UTC, Robert M. Münch wrote: I have a C interface that uses a parameter of type intptr_t. Wondering if size_t is the correct D equivalent? The correct equivalent is `intptr_t` from `core.stdc.stdint`. Ha, thanks... RTFM. Will do in the future. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: CTFE & code generators based on PEG grammars?
On 2019-04-06 20:16:14 +, Bastiaan Veelo said: On Saturday, 6 April 2019 at 12:06:22 UTC, Robert M. Münch wrote: The idea is, that I can write a string (or maybe even a scope block?) in my DSL and use a CTFE grammer to transpile the code. Are you aware of Pegged[1]? It’s for exactly that. [1] http://code.dlang.org/packages/pegged Yes, I'm but I didn't remember/thought about using a mixin(...) to use the parsed and transformed result at compiler time. Thanks. BTW: The reference for this specific use-case is here: https://github.com/PhilippeSigaud/Pegged/wiki/Generating-Code -- Robert M. Münch http://www.saphirion.com smarter | better | faster
