On Thursday, 27 March 2025 at 06:20:25 UTC, cc wrote:
I got in the habit of using `static immutable` whenever
possible as enum just can't be trusted to use CTFE.
```d
enum string RfuncName = fullyQualifiedName!...
// Oops! Allocates on runtime every frame this is referenced
enum string funcName
On Monday, 24 February 2025 at 16:07:07 UTC, Ian wrote:
Hello,
What's the recommended D way to declare a string constant? Say,
for example, for a path used inside a class constructor? I've
seen const string, immutable, enum etc...
Is this the place for these kinds of questions? Is there a D
On Monday, 17 March 2025 at 08:27:17 UTC, Jonathan M Davis wrote:
In any case, the normal way in D to declare a string constant
is to use enum. So, that's primarily what you're going to see
in most code. Whether you choose to do that in your own code is
up to you.
- Jonathan M Davis
Hi Jo
On Sunday, 16 March 2025 at 15:22:04 UTC, Ian wrote:
It seems that in some cases static immutable is preferred, so
why not use that always then, rather than having to keep two
cases in my head?
Enum is the indispensable one, immutable isnt important just
theres a subsection of the community t
On Sunday, March 16, 2025 9:22:04 AM MDT Ian via Digitalmars-d-learn wrote:
> On Tuesday, 25 February 2025 at 00:34:45 UTC, Jonathan M Davis
> wrote:
> > For strings, the way that you normally do constants is with
> > enum, e.g
> >
> > enum foo = "dlang";
> >
> > An enum like this is called a m
On Tuesday, 25 February 2025 at 00:34:45 UTC, Jonathan M Davis
wrote:
For strings, the way that you normally do constants is with
enum, e.g
enum foo = "dlang";
An enum like this is called a manifest constant. And you use
manifest constants for most constants in D, with the caveat
that fo
On Monday, February 24, 2025 9:07:07 AM MST Ian via Digitalmars-d-learn wrote:
> Hello,
>
> What's the recommended D way to declare a string constant? Say,
> for example, for a path used inside a class constructor? I've
> seen const string, immutable, enum etc...
>
> Is this the place for these kin
On Monday, February 24, 2025 11:19:48 AM MST Elias Batek (0xEAB) via
Digitalmars-d-learn wrote:
> For string constants you’ll usually want to mark them as `static
> immutable`. Strings with this combination will usually be put
> into read-only sections (ROM) of the resulting binaries.
>
> Unlike `
On Monday, 24 February 2025 at 16:07:07 UTC, Ian wrote:
Hello,
What's the recommended D way to declare a string constant? Say,
for example, for a path used inside a class constructor? I've
seen const string, immutable, enum etc...
Is this the place for these kinds of questions? Is there a D
On Monday, 24 February 2025 at 16:07:07 UTC, Ian wrote:
Hello,
What's the recommended D way to declare a string constant? Say,
for example, for a path used inside a class constructor? I've
seen const string, immutable, enum etc...
enum vs value is a tradeoff of when a decision is made; not s
Hello,
What's the recommended D way to declare a string constant? Say,
for example, for a path used inside a class constructor? I've
seen const string, immutable, enum etc...
Is this the place for these kinds of questions? Is there a D
stack overflow?
Cheers,
Ian
On 2013-12-30 23:51, John Colvin wrote:
Anyway, the big problem I've hit is that AFAICT std.algorithm makes a
complete mess of unicode and i can't find a byCodeUnit range anywhere in
order to make it correct.
There's a "byGrapheme" and a "byCodePoint" function in std.uni. It was
recently adde
Thanks for all your replies, guys! I have done some further
research in the meantime and I have found out that I am, in fact,
an idiot. There is actually a standard library function that does
exactly what I am trying to do! As it turns out,
std.string.split():
1) It automatically discards emp
Thomas Gann:
I've written a Markov bot in D, and I have function whose job
it is to take an input string, convert all newline characters
to spaces and all uppercase letters to lowercase, and then
return an array of words that are generated by splitting the
string up by whitespace.
Take a lo
On Monday, 30 December 2013 at 22:38:43 UTC, Brad Anderson wrote:
On Monday, 30 December 2013 at 22:30:02 UTC, John Colvin wrote:
On Monday, 30 December 2013 at 22:17:21 UTC, John Colvin wrote:
On Monday, 30 December 2013 at 21:40:58 UTC, Thomas Gann
wrote:
I've written a Markov bot in D, and I
On Monday, 30 December 2013 at 22:30:02 UTC, John Colvin wrote:
On Monday, 30 December 2013 at 22:17:21 UTC, John Colvin wrote:
On Monday, 30 December 2013 at 21:40:58 UTC, Thomas Gann wrote:
I've written a Markov bot in D, and I have function whose job
it is to take an input string, convert al
On Monday, 30 December 2013 at 21:40:58 UTC, Thomas Gann wrote:
I've written a Markov bot in D, and I have function whose job
it is to take an input string, convert all newline characters
to spaces and all uppercase letters to lowercase, and then
return an array of words that are generated by s
On Monday, 30 December 2013 at 22:17:21 UTC, John Colvin wrote:
On Monday, 30 December 2013 at 21:40:58 UTC, Thomas Gann wrote:
I've written a Markov bot in D, and I have function whose job
it is to take an input string, convert all newline characters
to spaces and all uppercase letters to lowe
On Monday, 30 December 2013 at 21:40:58 UTC, Thomas Gann wrote:
I've written a Markov bot in D, and I have function whose job
it is to take an input string, convert all newline characters
to spaces and all uppercase letters to lowercase, and then
return an array of words that are generated by s
I've written a Markov bot in D, and I have function whose job it
is to take an input string, convert all newline characters to
spaces and all uppercase letters to lowercase, and then return an
array of words that are generated by splitting the string up by
whitespace. Here is the function is qu
On 12/29/2013 10:58 AM, Jonathan wrote:
> Given a struct
>
> struct Foo{
>enum INT_C {Yes, No}
>INT_C a;
> }
[...]
> The second choice is: do we qualify by the struct name:
>
> this(int y)
> {
>//option 1
>a = Foo.INT_C.Yes;
That's what I do without thinking much about it.
>
On Sunday, 29 December 2013 at 18:58:07 UTC, Jonathan wrote:
Given a struct
struct Foo{
enum INT_C {Yes, No}
INT_C a;
}
-- we wish to make a constructor. We want to set the answer to
Yes if we construct the struct with an integer. There are some
stylistic choices to be made.
The first
Given a struct
struct Foo{
enum INT_C {Yes, No}
INT_C a;
}
-- we wish to make a constructor. We want to set the answer to
Yes if we construct the struct with an integer. There are some
stylistic choices to be made.
The first choice is: do we use this (I seem to recall being told
in Ja
On 2013-07-11, 20:22, Namespace wrote:
What should he do?
As far as I can see he has 3 options:
1. An external file with the enum information. Both classes would import
it and could use the same enum. But he cannot change the API, so this is
no real option.
2. Change test1 into this:
On Thu, 11 Jul 2013 19:22:10 +0100, Namespace
wrote:
I have a style question, because a friend of mine has a similar problem
currently and I have no good advice for him.
Let's assume we have this classes:
class MyClass {
public:
enum A {
Fo
On Friday, 12 July 2013 at 06:54:40 UTC, Jacob Carlborg wrote:
On 2013-07-11 20:22, Namespace wrote:
[snip]
Does anyone have any advice?
Who is supposed to access these enums? Can you put it in a
separate module but in the same package with package protection?
No. Both modules are in differ
On 2013-07-11 20:22, Namespace wrote:
[snip]
Does anyone have any advice?
Who is supposed to access these enums? Can you put it in a separate
module but in the same package with package protection?
--
/Jacob Carlborg
On Thursday, 11 July 2013 at 20:15:52 UTC, Namespace wrote:
The whole situation looks strange. If you can change both
files, than it is unclear what made you to write such
inconsistent code. If you can change only one of them, then it
should be adjusted to another (meaning importing external fi
The whole situation looks strange. If you can change both
files, than it is unclear what made you to write such
inconsistent code. If you can change only one of them, then it
should be adjusted to another (meaning importing external file
and using that enum instead of trying to define different
On Thursday, 11 July 2013 at 18:22:11 UTC, Namespace wrote:
I have a style question, because a friend of mine has a similar
problem currently and I have no good advice for him.
Let's assume we have this classes:
The whole situation looks strange. If you can change both files,
than
On 2013-07-11, 21:05, Namespace wrote:
It seems to me that MyClass has access to MyStaticClass, and thus should
also have access to B. If this is the case, why is MyClass using an A
instead of a B?
No, they are sadly not part of the same file / module.
The // should symbolize that. :D
I
It seems to me that MyClass has access to MyStaticClass, and
thus should
also have access to B. If this is the case, why is MyClass
using an A
instead of a B?
No, they are sadly not part of the same file / module.
The // should symbolize that. :D
One option might be to use alias A = B; T
On 2013-07-11, 20:22, Namespace wrote:
What should he do?
As far as I can see he has 3 options:
1. An external file with the enum information. Both classes would import
it and could use the same enum. But he cannot change the API, so this is
no real option.
2. Change test1 into this:
I have a style question, because a friend of mine has a similar
problem currently and I have no good advice for him.
Let's assume we have this classes:
class MyClass {
public:
enum A {
Foo = 0,
Bar = 1
}
private:
A _a;
p
34 matches
Mail list logo
