On Sunday, 22 June 2025 at 15:53:45 UTC, Richard (Rikki) Andrew
Cattermole wrote:
An int is a basic type, by itself it can live in a register and
does not have a unique memory address.
The location its in on the stack is irrelevant unless you take
a pointer to it. In essence its a implementati
On Friday, 30 May 2025 at 00:31:56 UTC, luafyn wrote:
Hi everyone, so dmd includes several -preview flags and I was
wondering if there were any that are recommended to enable?
I always use -preview=all, this also buys you dip1000, but
otherwise the list is just too long and everything else has
On Thursday, 29 May 2025 at 01:50:51 UTC, Murilo wrote:
I've written a code in D which implements the RSA algorithm, so
that others may learn how to do it.
Here is the link:
You messed up the link (the parentheses are wrong somehow).
This works:
https://github.com/MuriloMir/RSA-algorithm
On Saturday, 17 May 2025 at 13:09:40 UTC, Jonathan M Davis wrote:
On Friday, May 16, 2025 1:19:41 PM Mountain Daylight Time H. S.
Teoh via Digitalmars-d-learn wrote:
Welcome to your first encounter with why I hate D's narrow
integer promotion rules.
It's because C (and I'm pretty sure the CPU
On Wednesday, 14 May 2025 at 11:38:59 UTC, Nick Treleaven wrote:
On Wednesday, 14 May 2025 at 03:36:40 UTC, Jonathan M Davis
wrote:
to!string definitely deals with null-terminated strings, or it
wouldn't work at all. It's not the kind of thing that would
work by accident.
I don't think it's g
On Tuesday, 8 April 2025 at 15:54:52 UTC, Timon Gehr wrote:
In any case, casting a memory allocator to `pure` should be
fine. Any reasonable definition of `pure` we can come up with
in the future would be compatible with that.
Yes, this is also what I think. Of course an allocator cannot be
s
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
You basically have to lie to the compiler and cast the function
pointer to pure [...].
That being said, core.memory has pureMalloc and pureFree which
do that for you already, including mucking around with errno to
ensure that
Hi.
I want to create my own allocator, but using malloc is not pure
(it internally has to have some "global state"). But the GC also
has this "global state" and still is considered "pure".
So internally the impurity of the allocators has been hidden.
How can I do this?
adding @trusted doesn't
On Friday, 14 February 2025 at 15:58:26 UTC, Paul Backus wrote:
In your example, both overloads have match level 2: "match with
implicit conversions". So the compiler attempts to figure out
which one is more specialized by checking whether the
parameters of one overload can be used to call the
Why does this happen:
```d
void foo(long x) { }
void foo(ulong x) { }
main()
{
foo(short(17)); // error: `foo` called with argument types
`(short)` matches both: `foo(long x)` and: foo(ulong x)`
}
```
Why does a short match an unsigned type with same priority as a
signed type?!?
Clearly a
On Friday, 24 January 2025 at 19:12:59 UTC, monkyyy wrote:
On Friday, 24 January 2025 at 10:50:15 UTC, Dom DiSc wrote:
do they have some other, more specific property?
complete solutions: probably not, partial solutions well
```d
import std;
bool isctfe(alias i)(){
bool _isctfe
Is it possible in D to find out if the parameter given to a
function is a literal or a compile time constant?
Of course, if it has _only_ parameters known at compile time, the
function will be executed during CTFE, so I can check for the
execution time. But if it has also runtime-parameters, i
On Friday, 3 January 2025 at 04:28:36 UTC, Jo Blow wrote:
On Wednesday, 25 December 2024 at 11:24:00 UTC, Dom DiSc wrote:
On Wednesday, 25 December 2024 at 01:45:18 UTC, Jo Blow wrote:
I think the real problem is that we've been building on
systems that were build on very primitive ideas and so
On Wednesday, 25 December 2024 at 01:45:18 UTC, Jo Blow wrote:
I think the real problem is that we've been building on systems
that were build on very primitive ideas and so it's a
constantly piling on of ad-hoc changes that may or may not
evolve into something more and then a constant need to
On Monday, 18 November 2024 at 21:59:43 UTC, Andrey Zherikov
wrote:
Is this a correct/safe way to go since I'm copying `const
string[]` to `string[]`?
Copying constants to variables is something absolutely normal. If
this wouldn't work, how would you program at all?
So, yes this is safe and c
On Thursday, 14 November 2024 at 17:27:54 UTC, user1234 wrote:
You define a contract that Dscanner does not understand. The
more simple solution, as you seem to be careful about bounds,
is to disable the specific check that worries you.
Ok. Somewhat sad, but at least it works.
Thanks for all t
No, no. My problem is: I want to access the last element of an
array and assign it to the element of same index in another array
(so I can't use $), and I checked that the source array has at
least one element.
The questions are:
- Why is it considered dangerous to use the expression a.length-
I _very_ often use this pattern:
```
fun(ref int[] a)
{
assert(a.length && a.length<=100);
int[100] b;
b[0 .. a.length-1] = a[];
b[a.length .. 100] = 5;
}
```
I consider this perfectly safe, but DScanner gives warnings for
this, no matter if a check is present or not.
What's the rec
On Sunday, 4 August 2024 at 10:06:49 UTC, aberba wrote:
So if I have a feature request, but I don't have the necessary
technical skills to draft a DIP with the implementation
details, is there a process in D community to submit such a
request?
DIP Ideas?
On Friday, 26 July 2024 at 10:04:45 UTC, Jonathan M Davis wrote:
On Friday, July 26, 2024 2:17:21 AM MDT Dom DiSc via
Digitalmars-d-learn wrote:
If you are not able to construct a mutable copy of a type, why
on earth are you handing it over by value?!?
Why not?
Because you can't m
On Thursday, 25 July 2024 at 13:07:03 UTC, Jonathan M Davis wrote:
On Thursday, July 25, 2024 6:00:58 AM MDT Dom DiSc via
But a parameter given by value is ALWAYS a copy.
It has to be a _full_, independent copy. If you're talking
about integer types, that's a non-issue, but if you're talking
On Friday, 26 July 2024 at 02:34:12 UTC, Andy Valencia wrote:
On Thursday, 25 July 2024 at 13:07:03 UTC, Jonathan M Davis
wrote:
It's most definitely not a bug that IFTI (Implicit Function
Template Instantiation) instantiates the template with the
exact type that it's given.
The "principle
On Thursday, 25 July 2024 at 15:40:29 UTC, Nick Treleaven wrote:
On Thursday, 25 July 2024 at 15:06:35 UTC, IchorDev wrote:
I think your function most likely has a safe interface, so it
can be marked as `@trusted` as-per [the
spec](https://dlang.org/spec/function.html#safe-interfaces).
Just t
On Thursday, 25 July 2024 at 13:20:59 UTC, IchorDev wrote:
On Thursday, 25 July 2024 at 13:01:53 UTC, Dennis wrote:
That's true for the other function attributes, but `@safe:`
actually does penetrate scopes
The spec doesn’t mention this at all! Is this the case for any
other `AttributeSpecifi
On Thursday, 25 July 2024 at 08:42:29 UTC, Jonathan M Davis wrote:
It's not a cast. Casts in D use the keyword, cast - e.g.
return --(cast(T)x);
Rather, Dennis' solution is constructing a value of the given
type. For it to work, T must be constructible from an immutable
T - which works wi
I have copied some source from C++, where the following pattern
is common (operator== already renamed):
```d
@safe:
struct S
{
bool opEquals(const ref S x) const
{
if(&x==&this) return true;
...
}
}
```
Can I replace this pattern with ```(x is this)``` or are there
some sp
On Wednesday, 24 July 2024 at 15:40:28 UTC, Dennis wrote:
Is there a way to tell the compiler that it should discard
"const" and "immutable" if it needs to create a copy?
Unqual!T doesn't work :-(
When you add `const` or `immutable` before the template type
parameter, it will infer T as simpl
In following code:
```d
int test(int x) { return --x; }
T test2(T)(T x) { return --x; }
void main()
{
const int v = 3;
writeln(test(v));
writeln(test2(v)); // doesn't compile
}
```
test2 (just like test) works on a copy of x. Why is this copy
const?!? If I copy a const or immutable obj
On Monday, 8 April 2024 at 07:03:40 UTC, Alexandru Ermicioi wrote:
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only p
On Sunday, 7 April 2024 at 23:32:24 UTC, MrJay wrote:
A better way to apply a attribute to an entire file is to use
an explicit scope you can still apply this to basically the
entire file but leave the tests out of it.
Better than an explicit impure (or pure=false) attribute?
I don't think so.
On Sunday, 24 March 2024 at 09:16:20 UTC, Jonathan M Davis wrote:
So, yes, you've run into a problem that it would be nice to
have a better fix for, but even if we could negate attributes
in general, there are good reasons to prefer to avoid
mass-applying attributes.
I don't see it as "mass-a
On Monday, 5 February 2024 at 17:28:38 UTC, Iain Buclaw wrote:
Padding.
x86 ABI prefers things to be aligned, so on x86 it's 12 bytes,
x86_64 16 bytes. In both cases you don't get any extra
precision over the 80-bits that x87 gives you.
This is exactly what I mean. The ABI may pad it, but
On Thursday, 30 November 2023 at 12:15:04 UTC, Dennis wrote:
The syntax was inherited from C. The 'special place' is called
initialization, and it's special because the target type of the
initializer is known in advance
This is no different from `S fun(){ return { 5, 2 }; }` It
creates a new
On Thursday, 30 November 2023 at 14:10:35 UTC, zjh wrote:
On Wednesday, 29 November 2023 at 16:38:36 UTC, Dom DiSc wrote:
```d
struct S { int a; int b; }
S2 fun3() { return S2( 5, 2 ); }
```
Here,`S2( 5, 2 );` violeit `DRY` principle.
Yes. I think if we have the brackets form, it should be
On Wednesday, 29 November 2023 at 16:48:09 UTC, Paul Backus wrote:
You can use this syntax without an explicit constructor:
struct S3 { int a; int b; }
S3 fun() { return S3(5, 2); }
The language spec calls this a struct literal
Ok, so we have
```d
struct S { int a; int b; }
S s = S
Sorry, I meant
```d
fun2({4, 4}); // doesn't work
```
```d
struct S { int a; int b; }
S s = { 5, 2 }; // works fine
S fun() { return { 5, 2 }; } // doesn't work :-(
S fun2() { S s = { 5, 2 }; return s; } // works but is ugly
struct S2 { int a; int b; this(int c, int d) { a=c; b=d; } }
S2 fun3() { return S2( 5, 2 ); } // works but requires explic
On Tuesday, 28 November 2023 at 11:01:14 UTC, Antonio wrote:
```d
I aOrB(bool check){
if(check)
return new A();
else
return new B();
}
```
**Is it the expected behaviour for ternary conditional?**
Here the compiler knows what type to return (from the function
signature).
But the t
On Tuesday, 28 November 2023 at 08:51:21 UTC, Mark Davies wrote:
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
```
import std.stdio;
char[10] longToString(long n) @nogc
```
For a 'long' 10 characters is likely to be not enough (long max
is 9223372036854775808 which has 19 chars, a
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote:
I have another question if I may, what do we do about getting
makefiles right given that we have imports ?
You can replace your whole makefile by calling the compiler with
-I (not always, but if you don't do funny things in your
make
On Tuesday, 30 May 2023 at 04:11:00 UTC, Cecil Ward wrote:
static immutable T foo;
T bar() {
return foo;
}
Should we get an error from the D compiler here as the
initialiser has been forgotten? What do you think ?
No.
There are no un-initialized values in D.
It gets its default value,
On Wednesday, 31 May 2023 at 03:29:33 UTC, Cecil Ward wrote:
I have to admit that I don’t really understand immutable. I
have an idea that it could mean that an object has an address
in ROM, so its value will never change. Maybe const doesn’t
give you such a strong guarantee, disallows ‘you’ fr
On Saturday, 27 May 2023 at 19:16:18 UTC, vushu wrote:
It depends. This example is quite small and a `static if` is
sufficient, if you have a lot of cases it would make sense to
split thing up into overloaded functions.
Even with a lot of cases you can simply call in each static if a
(private
On Friday, 12 May 2023 at 15:00:48 UTC, Salih Dincer wrote:
```d
struct Fraction {
int num, den;
this(int n, int d)
{
num = n;
den = d;
}
// Cast Expression : convert float value of fraction
auto opCast(T : float)(
On Tuesday, 11 April 2023 at 14:13:17 UTC, slectr wrote:
I want to make software like krita inkscape and my own
language using D
Although i previosly learned C and C++ i left it in the middle
and for some reasons i dont want to learn those so i searched
for alternatives and found D but there
On Monday, 23 January 2023 at 16:36:21 UTC, Leonardo wrote:
Hello. How to use @safe when a C library integration needed?
Everything need a system function...
```d
@safe fn()
{
// lot of safe stuff
() @trusted {
// in this block[*] @system function like extern C can be
called.
On Wednesday, 4 January 2023 at 14:21:46 UTC, bauss wrote:
```d
class Foo {
int bar;
void setBar(Foo foo, int value) {
foo.bar = value;
}
}
void main() {
foo.setBar(100); // Not UFCS - just method call to the class
foo.setBar = 100; // Not UFCS - simply a setter function call
(eq
On Tuesday, 9 August 2022 at 22:58:16 UTC, Paul Backus wrote:
On Tuesday, 9 August 2022 at 22:36:23 UTC, Dom Disc wrote:
On Tuesday, 9 August 2022 at 22:32:23 UTC, Dom Disc wrote:
On Tuesday, 9 August 2022 at 21:16:22 UTC, Paul Backus wrote:
Yes, this syntax allows anything that implicitly conv
On Tuesday, 9 August 2022 at 22:32:23 UTC, Dom Disc wrote:
On Tuesday, 9 August 2022 at 21:16:22 UTC, Paul Backus wrote:
Yes, this syntax allows anything that implicitly converts to
`BigInt`;
Oh, or do you mean I will get two different instances of the
template, if I call it with two differen
On Tuesday, 9 August 2022 at 21:16:22 UTC, Paul Backus wrote:
Yes, this syntax allows anything that implicitly converts to
`BigInt`; for example:
```d
import std.bigint;
void fun(T : BigInt)(T t)
{
pragma(msg, "Instantiated with T = `" ~ T.stringof ~ "`");
}
struct S
{
BigInt n;
a
On Monday, 8 August 2022 at 12:46:48 UTC, bauss wrote:
On Monday, 8 August 2022 at 12:02:02 UTC, Dom Disc wrote:
```D
pure @nogc @safe BigInt opAssign(T : BigInt)(T x);
```
This will only be included in the object file if used.
```D
pure @nogc @safe BigInt opAssign(BigInt x);
```
This wil
Hello.
I found in the documentation functions declared like this:
```D
pure @nogc @safe BigInt opAssign(T : BigInt)(T x);
```
What is the difference to declaring it like:
```D
pure @nogc @safe BigInt opAssign(BigInt x);
```
To me the first declaration seems to be unnecessarily bloated, so
I a
And then you can instantiate it with
```D
auto val = TestArray!10(ubyte(60)); // if you want type to be
ubyte
```
On Monday, 8 August 2022 at 06:58:42 UTC, bauss wrote:
On Monday, 8 August 2022 at 05:38:31 UTC, rempas wrote:
In the following struct (as an example, not real code):
```
struct TestArray(ulong element_n) {
int[element_n] elements;
this(string type)(ulong number) {
pragma(msg, "The typ
On Monday, 8 August 2022 at 00:40:11 UTC, TTK Ciar wrote:
On the other hand, I've noticed that D's idiomatic brevity can
be diluted by the extremely verbose function names used in the
standard library.
For long function names you can define short aliases, for syntax
you can't. So having short
On Saturday, 6 August 2022 at 11:25:28 UTC, Dom Disc wrote:
I once did a completely inline implementation of xlcmplx
Sorry, one function is NOT inline:
```C
class xlcmplx
{
uint32 Decimal(char* s, uint32 max) const; // string
representation
}
```
But you should forget about that, because D
On Friday, 5 August 2022 at 14:25:39 UTC, Ruby The Roobster wrote:
I'm currently working on an arbitrarily precise division
algortihm based off of the done-by-hand standard algorithm, but
I need to get it to work for complex numbers, [which it's just
not](https://forum.dlang.org/post/czidpbdyws
On Sunday, 29 May 2022 at 01:35:23 UTC, frame wrote:
Is there a compiler switch to catch this kind of error?
```d
ulong v = 1;
writeln(v > -1);
```
IMHO the compiler should bail a warning if it sees a logic
comparison between signed and unsigned / different integer
sizes. There is 50% chance
On Tuesday, 17 May 2022 at 06:28:10 UTC, cc wrote:
having had this leave a pretty bad taste in my mouth, I now
avoid the GC whenever possible, even when I don't have to.
Bad idea. You should only avoid GC if your profiling shows that
it is bad in a specific piece of code (e.g. some inner loop
On Tuesday, 17 May 2022 at 09:30:12 UTC, forkit wrote:
On Tuesday, 17 May 2022 at 04:37:58 UTC, Ali Çehreli wrote:
In you OOP example, I am curious why you chose Shape to be an
interface, rather than a base class.
You can inherit from multiple interfaces, but only from one base
class.
So
On Monday, 11 April 2022 at 22:10:07 UTC, Ali Çehreli wrote:
1) I will not mutate data through this reference. For example,
a parameter that is pointer to const achieves that:
void foo (const(int)[] arr);
2) This variable is const:
const i = 42;
Well, there is the confusion: There is no
On Friday, 29 October 2021 at 14:20:09 UTC, Ali Çehreli wrote:
Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
{
static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
return x;
}
void main() {
int a = -5;
int b = -4;
writeln(a + abs(b)); // -5 + 4 == -1? (No!)
}
The program prin
On Friday, 29 October 2021 at 08:33:07 UTC, Imperatorn wrote:
Imo abs should never be able to return a negative value
Yes, but phobos defines it to return a signed type, so
theoretical it can return negative values. And they won't change
that.
I really think it should return an unsigned typ
On Thursday, 28 October 2021 at 21:26:04 UTC, kyle wrote:
Okay I checked the phobos docs and it does say "Limitations
Does not work correctly for signed intergal types and value
Num.min." Should have looked there first, I know. Still seems
pretty silly.
I recommend to implement your own abs
64 matches
Mail list logo
