Re: Question regarding readf
Le 23/04/2019 à 00:23, Adam D. Ruppe via Digitalmars-d-learn a écrit :
(my personal feeling though is readf is just a pile of confusion and should
almost never be used. I hate that it is introduced so early in most tutorials...
I'd rather have it in an appendix for special cases only rather than like page 3.)
agreed
--
diniz {la vita e estranj}
Re: I really don't understand DUB
Le 15/04/2019 à 09:57, Paolo Invernizzi via Digitalmars-d-learn a écrit :
I guess that just killing all that educated dub guess will turn dub into a much
easier tool to grasp.
Probably. I had similar issues as well. Now I keep all as simple and explicit as
possible. (And it works, at least in simple cases like my uses are as of now.)
--
diniz {la vita e estranj}
Re: Subtyping of an enum
Le 15/04/2019 à 10:39, Anton Fediushin via Digitalmars-d-learn a écrit :
This seems to work just fine for assigning and comparisons but passing Enum as a
function argument does not work:
```
void fun(Enum e) {}
fun(Enum.foo);
---
Error: function fun(Enum e) is not callable using argument types (internal)
Cannot pass argument foo of type internal to parameter Enum e.
```
I don't understand why you just don't call fun with an Enum (struct) param,
since that is how fun is defined. This works by me (see call in main):
struct Enum {
private {
enum internal {
foo,
bar
}
internal m_enum;
}
this (internal i) { m_enum = i; }
alias m_enum this;
string toString() {
switch (this.m_enum) {
case internal.foo : return "FOO" ;
case internal.bar : return "BAR" ;
default : assert(0) ;
}
}
}
void fun (Enum e) {
writeln(e) ;
}
void main() {
auto e = Enum(Enum.foo) ;
fun(e) ;// -> "FOO"
}
[And I wouldn't make the enum (little e) private, this just risks complicating
code, also eg in testing, I would just not export it.]
--
diniz {la vita e estranj}
Re: Transparent cast from class to member pointer?
Le 15/04/2019 à 08:30, Robert M. Münch via Digitalmars-d-learn a écrit :
The C side requires that *impl is the 1st member in the struct/class whereever
it is stored. Hence, the wrapping in a struct and not directly putting it into a
D class.
All right! Did not think at this usage case, interfacing with C.
--
diniz {la vita e estranj}
Re: Transparent cast from class to member pointer?
Le 14/04/2019 à 20:03, Robert M. Münch via Digitalmars-d-learn a écrit :
struct IM;
struct C {
IM *impl;
};
int cInit(C* self);
class I {
C handler;
this(){cInit();}
}
Is there a simple way that I can use handler without the address-of operator and
automatically get *impl?
Something like:
class I {
C handler;
this(){cInit(handler);}
}
And later can use I in a way like this without having to define/write explicit
casts everywhere?
someFunc(C* self);
I myI;
someFunc(myI);
Do you have a clear and correct view of what you want to express, of the
application? How does it look (for us), if you replace IM, C, impl, cInit, I,
handler, with meaningful (and correctly chosen) terms?
--
diniz {la vita e estranj}
Re: Iterate/sort associative array by value?
Le 07/04/2019 à 19:16, Seb via Digitalmars-d-learn a écrit :
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.
That's what I would do: just operating on an array of {k,v} pairs.
--
diniz {la vita e estranj}
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: == comparison of string literals, and their usage
Le 06/04/2019 à 21:47, lithium iodate via Digitalmars-d-learn a écrit :
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.
Thank you very much! And yes, properly documenting is also important to me.
--
diniz {la vita e estranj}
Re: == comparison of string literals, and their usage
Le 06/04/2019 à 16:07, AltFunction1 via Digitalmars-d-learn a écrit :
On Friday, 5 April 2019 at 14:49:50 UTC, diniz wrote:
Hello,
Since literal strings are interned (and immutable), can I count on the fact
that they are compared (==) by pointer?
No. "==" performs a full array comparison and "is" is apparently simplified at
compile time. In the compiler there's no notion of string literal as a special
expression. It's always a StringExp. See https://d.godbolt.org/z/K5R6u6.
However you're right to say that literal are not duplicated.
Thank you very much.
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;
}
--
diniz {la vita e estranj}
== comparison of string literals, and their usage
Hello,
Since literal strings are interned (and immutable), can I count on the fact that
they are compared (==) by pointer?
Context: The use case is a custom lexer for a custom language. I initially
wanted to represent lexeme classes by a big enum 'LexClass'. However, this makes
me write 3 times all constant lexemes (keywords and keysigns):
1- in the enum of lexeme classes
2- in an array of constants (for the contant-scanning func)
3- in an associative array mapping constants to their classes
However, if literal strings are compared by equality, then they are kinds of
Scheme or Ruby symbols: read enum values representing *cases*, which is exactly
what I need. I would thus use the constants' strings themselves as lexeme
classes... the parser would not be slown down.
What do you think?
--
diniz {la vita e estranj}
