On Monday, 17 June 2024 at 05:05:06 UTC, Jonathan M Davis wrote:
alias Unshared(T) = T;
alias Unshared(T: shared U, U) = U;
...
Unshared is an eponymous template.
https://dlang.org/spec/template.html#implicit_template_properties
And it's using a shortcut syntax.
...
The second
On Sunday, June 16, 2024 10:32:50 PM MDT Andy Valencia via Digitalmars-d-learn
wrote:
> In the alias:
>
> alias Unshared(T) = T;
> alias Unshared(T: shared U, U) = U;
>
> as used in:
>
> cast(Unshared!mytype)value
>
> turns a mytype with shared attribute into one without shared.
>
On Monday, 17 June 2024 at 04:32:50 UTC, Andy Valencia wrote:
In the alias:
alias Unshared(T) = T;
alias Unshared(T: shared U, U) = U;
as used in:
cast(Unshared!mytype)value
turns a mytype with shared attribute into one without shared.
I deduce the alias is using some sort of
In the alias:
alias Unshared(T) = T;
alias Unshared(T: shared U, U) = U;
as used in:
cast(Unshared!mytype)value
turns a mytype with shared attribute into one without shared.
I deduce the alias is using some sort of type matching and
decomposition?
I've read through the
On Friday, 10 May 2024 at 16:33:53 UTC, Nick Treleaven wrote:
Arrays evaluate to true in boolean conditions if their `.ptr`
field is non-null. This is bug-prone and I hope we can remove
this in the next edition.
...
A string literal's `.ptr` field is always non-null, because it
is
On Friday, 10 May 2024 at 15:23:39 UTC, Andy Valencia wrote:
On Friday, 10 May 2024 at 03:07:43 UTC, Steven Schveighoffer
wrote:
Yes, we say that a type has "truthiness" if it can be used in
a condition (`while`, `if`, `assert`, etc).
So if I may ask for one more small clarification... WRT
On Friday, 10 May 2024 at 03:07:43 UTC, Steven Schveighoffer
wrote:
Yes, we say that a type has "truthiness" if it can be used in a
condition (`while`, `if`, `assert`, etc).
So if I may ask for one more small clarification... WRT
"truthiness", I've observed that empty arrays are treated as
On Friday, 10 May 2024 at 01:00:09 UTC, Andy Valencia wrote:
On Friday, 10 May 2024 at 00:40:01 UTC, Meta wrote:
Yes. The reason for this is that it avoids having to
essentially do the same check twice. If `in` returned a bool
instead of a pointer, after checking for whether the element
On Friday, 10 May 2024 at 00:40:01 UTC, Meta wrote:
Yes. The reason for this is that it avoids having to
essentially do the same check twice. If `in` returned a bool
instead of a pointer, after checking for whether the element
exists (which requires searching for the element
(123));
}
Yes. The reason for this is that it avoids having to essentially
do the same check twice. If `in` returned a bool instead of a
pointer, after checking for whether the element exists (which
requires searching for the element in the associative array),
you'd then have to actually *get
tst7.d(6): Error: cannot implicitly convert expression `e in
this.members` of type `bool*` to `bool`
tst7.d(15): Error: template instance `tst7.Foo!uint` error
instantiating
I'm getting this for this bit of source (trimmed from the bigger
code). I switched to this.members.get(e, false) and
On Friday, 26 January 2024 at 11:38:39 UTC, Stephen Tashiro wrote:
On Thursday, 25 January 2024 at 20:36:49 UTC, Kagamin wrote:
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
On Friday, 26 January 2024 at 11:38:39 UTC, Stephen Tashiro wrote:
On Thursday, 25 January 2024 at 20:36:49 UTC, Kagamin wrote:
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
On Friday, 26 January 2024 at 11:38:39 UTC, Stephen Tashiro wrote:
On Thursday, 25 January 2024 at 20:36:49 UTC, Kagamin wrote:
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
On Thursday, 25 January 2024 at 20:36:49 UTC, Kagamin wrote:
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
static_array[2][1] = 6;
}
The static array has length 2, so index 2 is out
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
void main()
{
ulong [3][2] static_array = [ [0,1,2],[3,4,5] ];
static_array[2][1] = 6;
}
The static array has length 2, so index 2 is out of bounds, must
be 0 or 1.
On Thursday, 25 January 2024 at 20:11:05 UTC, Stephen Tashiro
wrote:
Can the elements of an array be accessed with a pointer using
the usual indexing notation (e.g."[2][0]") for array elements?
- or must we treat the elements associated with the pointer as
1-dimensional list and u
Can the elements of an array be accessed with a pointer using the
usual indexing notation (e.g."[2][0]") for array elements? - or
must we treat the elements associated with the pointer as
1-dimensional list and use pointer arithmetic?
A more elementary question is why array inde
On Thursday, 23 November 2023 at 20:13:59 UTC, BoQsc wrote:
Nothing wrong. It would be just a more concise compact way to
do the same.
Also I mostly wanted to know if something like that is already
possible in D language.
It's not a huge loss if it is not possible.
This is possible in Go:
On Thursday, 23 November 2023 at 20:00:31 UTC, H. S. Teoh wrote:
On Thu, Nov 23, 2023 at 07:22:22PM +, BoQsc via
Digitalmars-d-learn wrote:
Is it possible to declare empty pointer variable inside
function calls and pass its address to the function?
These are sometimes required while using
On Thu, Nov 23, 2023 at 07:22:22PM +, BoQsc via Digitalmars-d-learn wrote:
> Is it possible to declare empty pointer variable inside function calls
> and pass its address to the function?
>
> These are sometimes required while using Win32 - Windows Operating
> System API.
>
Is it possible to declare empty pointer variable inside function
calls and pass its address to the function?
These are sometimes required while using Win32 - Windows
Operating System API.
* Empty pointer variables are used by functions to return
information after the function is done.
My
On Sunday, 1 October 2023 at 09:41:39 UTC, BoQsc wrote:
The package dependency `emsi_containers` that can be found in
https://code.dlang.org/packages/emsi_containers might be a
viable way to resolve the problem.
```
/+dub.sdl:
dependency "emsi_containers" version="~>0.7"
+/
import std;
The package dependency `emsi_containers` that can be found in
https://code.dlang.org/packages/emsi_containers might be a
viable way to resolve the problem.
```
/+dub.sdl:
dependency "emsi_containers" version="~>0.7"
+/
import std;
void main(string[] args) @nogc
{
import containers;
On Friday, 29 September 2023 at 14:31:54 UTC, BoQsc wrote:
After being very happy about associative arrays of D Language,
I encountered that they are not `@nogc`friendly. Unsure if I
should wait for D language to support it, or do I need to
rethink everything.
You can work with AA's inside
After being very happy about associative arrays of D Language, I
encountered that they are not `@nogc`friendly. Unsure if I should
wait for D language to support it, or do I need to rethink
everything.
Error
```
onlineapp.d(20): Error: assigning an associative array element in
`@nogc`
Out of scope access to a variable using stored pointer address,
demonstration.
```
import std;
void outofcontext()
{
writeln("Hello D ", associative);
foreach (pointeraddress, information; associative)
{
writeln(*cast(string*)pointeraddress);
}
}
static s
Bonus: Store hexadecimal literals in associative array of
pointer addresses.
```
import std;
void main()
{
string[void *] associative;
// Store Hexadecimal as pointer address in associative array
associative[cast(void *)0x7FFCD332CD60] = "someinformation";
For some reason I thought this was something I wanted to achieve
and share.
```
import std;
void main()
{
string variable;
void * pointeraddress =
string[void *] associative;
associative[pointeraddress] = "someinformation";
writeln("Hello D ", pointeraddress);
On Friday, 8 September 2023 at 13:34:42 UTC, Richard (Rikki)
Andrew Cattermole wrote:
In case you didn't know, all you need to get unittests working
in -betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest;
On Saturday, 9 September 2023 at 10:54:34 UTC, bachmeier wrote:
Hate to be that guy, but I posted a link to a stackoverflow
question with the exact error message you were getting, and the
solution. And I told you I had experienced the same error and
that question fixed it.
No reason to not
On Saturday, 9 September 2023 at 09:30:10 UTC, rempas wrote:
Bingo! You and Brad found out!
Hate to be that guy, but I posted a link to a stackoverflow
question with the exact error message you were getting, and the
solution. And I told you I had experienced the same error and
that
On Saturday, 9 September 2023 at 09:56:59 UTC, H. S. Teoh wrote:
libc doesn't know what you intended. All it knows is that you
asked it for 20 bytes (even though you actually needed 40),
then later on its internal structures are corrupted (because
you thought you got 40 bytes; storing data
On Saturday, 9 September 2023 at 09:47:14 UTC, Steven
Schveighoffer wrote:
You are focusing on the wrong problem.
You asked for size bytes, and malloc gave you size bytes. It
doesn't "know" anything special.
Then you proceeded at some point to write *past* the size
bytes. What did you
On Sat, Sep 09, 2023 at 09:21:32AM +, rempas via Digitalmars-d-learn wrote:
> On Saturday, 9 September 2023 at 08:54:14 UTC, Brad Roberts wrote:
> > I'm pretty sure this is your problem. You're allocating size bytes
> > which is only going to work where sizeof(T) == 1. Changing to
> >
On Saturday, 9 September 2023 at 09:21:32 UTC, rempas wrote:
Now, if only one could expect how and why "libc" knows that and
doesn't just care to give me the memory I asked it for? Or it
could be than D does something additional without telling us?
Which can explain when this memory is only
On Saturday, 9 September 2023 at 09:04:18 UTC, Steven
Schveighoffer wrote:
This is not ideal. Why? Because 99% of the time, a poster has
come here with a problem they don't know how to solve, and have
focused in on where they *think* the problem is. However, the
problem isn't there. But us
On Saturday, 9 September 2023 at 08:54:14 UTC, Brad Roberts wrote:
I'm pretty sure this is your problem. You're allocating size
bytes which is only going to work where sizeof(T) == 1.
Changing to malloc(size * sizeof(T)) is likely going to work
better.
Oh man That was it! I had forget
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
...
That's some minimal code that I do have just to showcase it.
This is not ideal. Why? Because 99% of the time, a poster has
come here with a problem they don't know how to solve, and have
focused
On 9/8/2023 12:59 AM, rempas via Digitalmars-d-learn wrote:
u64 _cap = 0; // Total amount of elements (not bytes) we can
this._ptr = cast(T*)malloc(size);
I'm pretty sure this is your problem. You're allocating size bytes
which is only going to work where sizeof(T) == 1. Changing to
On Friday, 8 September 2023 at 19:48:33 UTC, Basile B. wrote:
My idea was that if you dont have defined a copy constructor
and if an instance is assigned to another, then that other
instance share the same pointer, which can cause memory errors.
To eliminate that risk and to detect where
a double-free somewhere, or there's a
buffer overrun. Or maybe some bad interaction with the GC, e.g.
if you tried to free a pointer from the GC heap. (Note that
this may not immediately show up; free() could've assumed that
everything was OK when it has in fact messed up its internal
data structures
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote:
My guess is that you have a double-free somewhere, or there's a
buffer overrun. Or maybe some bad interaction with the GC, e.g.
if you tried to free a pointer from the GC heap. (Note that
this may not immediately show up; free
On Friday, 8 September 2023 at 16:17:15 UTC, Richard (Rikki)
Andrew Cattermole wrote:
I would strongly suggest that you log all memory sizes that are
allocated, and double check that you do free.
Also turn on ASAN in ldc.
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote:
[...]
My guess is that you have a double-free somewhere, or there's a
buffer overrun. Or maybe some bad interaction with the GC, e.g.
if you tried to free a pointer from the GC heap.
That cant be a GC problem as rempas project
, then that other instance
share the same pointer, which can cause memory errors.
To eliminate that risk and to detect where default post-blitting
may happen you can add
```d
@disable this(this);
```
to the struct.
nges slightly.
My guess is that you have a double-free somewhere, or there's a buffer
overrun. Or maybe some bad interaction with the GC, e.g. if you tried to
free a pointer from the GC heap. (Note that this may not immediately
show up; free() could've assumed that everything was OK when it has in
fact mes
On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote:
Could this be a problem of copy construction ?
I don't think so. The assertion seems to be violated when
`malloc` is used. And when I assert the result in the `_ptr`
field. Really weird...
On 08/09/2023 7:59 PM, rempas wrote:
|Fatal glibc error: malloc.c:2594 (sysmalloc): assertion failed:
(old_top == initial_top (av) && old_size == 0) || ((unsigned long)
(old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long)
old_end & (pagesize - 1)) == 0)|
I would strongly suggest
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
[...]
Is there any possible that there is a compiler bug? I do use
ldc2 and `betterC`!
Could this be a problem of copy construction ?
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
[I do have ... I do use ldc2 and `betterC`!]
For anyone who is still following, first of all thanks! Second, I
have bad news and good news!
The bad news is that I tested in an Linux Mint system (mine is an
Arch Linux) and the it
On Friday, 8 September 2023 at 14:40:13 UTC, Richard (Rikki)
Andrew Cattermole wrote:
No, for this you need ModuleInfo. The order is sequential on
what it sees first.
Personally I test using full D rather than -betterC.
For dub:
```json
"configurations": [
{
"name":
On Friday, 8 September 2023 at 14:50:17 UTC, Kagamin wrote:
Did you run this example program above? Does it crash?
I didn't as I suppose that it would had no problems as it works
for you. Either that, or it will be indeed a problem with my
Glibc.
I did run it now after your reply and it
On Friday, 8 September 2023 at 13:32:00 UTC, rempas wrote:
On Friday, 8 September 2023 at 13:05:47 UTC, evilrat wrote:
```d
import core.stdc.stdlib;
import core.stdc.stdio;
alias u64 = ulong;
alias i64 = long;
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap
On 09/09/2023 2:20 AM, rempas wrote:
Do they have automatic symbol order resolution? Which is, testing
symbols that other symbol depend on first? Or is it random?
No, for this you need ModuleInfo. The order is sequential on what it
sees first.
Personally I test using full D rather than
On Friday, 8 September 2023 at 13:34:42 UTC, Richard (Rikki)
Andrew Cattermole wrote:
In case you didn't know, all you need to get unittests working
in -betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest;
In case you didn't know, all you need to get unittests working in
-betterC is:
```d
foreach (module_; allModules) {
foreach (unitTest; __traits(getUnitTests,
module_)) {
unitTest();
on your libc, tested this on ubuntu 23.04
with gcc12 install and ldc 1.32.2
```d
import core.stdc.stdlib;
import core.stdc.stdio;
alias u64 = ulong;
alias i64 = long;
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory
this on ubuntu 23.04 with
gcc12 install and ldc 1.32.2
```d
import core.stdc.stdlib;
import core.stdc.stdio;
alias u64 = ulong;
alias i64 = long;
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we can
store
u64 _len = 0
On Friday, 8 September 2023 at 09:25:59 UTC, Hipreme wrote:
Hello, not completely unrelated to your problem, I have also
done something like that, and when you're in D, don't use
simply a pointer and length like that, use the `slice` operator.
See references:
https://tour.dlang.org/tour/en
On Friday, 8 September 2023 at 09:07:12 UTC, evilrat wrote:
Hard to tell from that code but it is quite unlikely there is a
compiler bug in such simple use case.
I assume you already tried debugging your program, right?
Yep! I have spent days and it's these kinds of bugs that burn me
off
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote:
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we
can store
public:
/* Create a vector by just allocating memory
I do have the following struct:
```d
struct Vec(T) {
private:
T* _ptr = null; // The pointer to the data
u64 _cap = 0; // Total amount of elements (not bytes) we can
store
public:
/* Create a vector by just allocating memory for it. The null
terminator is not set for
strings
On Wednesday, 30 August 2023 at 21:12:57 UTC, Paul Backus wrote:
On Wednesday, 30 August 2023 at 17:48:19 UTC, Vino wrote:
Hi All,
Request your help on hot to create a pointer for a function
whose function type is Result.
```
ReturnType!(typeof()).stringof; // Result
From
Vino
On Thursday, 31 August 2023 at 10:46:53 UTC, Dukc wrote:
On Thursday, 31 August 2023 at 05:16:02 UTC, Vino wrote:
[...]
I'm assuming you want to instantiate `splitter` and take the
address of the resulting function, so that `splitter_ptr` will
be a function pointer or a delegate
ntiate `splitter` and take the
address of the resulting function, so that `splitter_ptr` will be
a function pointer or a delegate.
You are getting the compile time arguments to `splitter` utterly
wrong. It should take:
- A function that checks equality between an element
On Thursday, 31 August 2023 at 05:16:02 UTC, Vino wrote:
Hi All,
Request your help on the below error
Program
```
void main()
{
import std.stdio:writeln;
import std.algorithm.iteration : splitter;
auto splitter_ptr = !((a, b) => a.splitter(b).array);
Hi All,
Request your help on the below error
Program
```
void main()
{
import std.stdio:writeln;
import std.algorithm.iteration : splitter;
auto splitter_ptr = !((a, b) => a.splitter(b).array);
string str = "TEST1;TEST2;TEST3";
auto words =
On Wednesday, 30 August 2023 at 17:48:19 UTC, Vino wrote:
Hi All,
Request your help on hot to create a pointer for a function
whose function type is Result.
```
ReturnType!(typeof()).stringof; // Result
From
Vino
```
To get a function pointer type from a function type, you can add
Ext_PT = Ext_T*; // define a function **pointer** type
Ext_PT ext =
```
But as you can see that does not allow to capture the argument.
Also it only work as AliasDeclaration RHS.
Thank you
) = ("PATHEXT");
writeln(*ext);
}
```
Problems is that "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
a
t "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
alias atGet = {return environment.get("PATHEXT");}; // re
Hi All,
The the below code is not working, hence requesting your help.
Code:
```
import std.stdio;
import std.process: environment;
void main () {
int* ext(string) = ("PATHEXT");
writeln(*ext);
}
```
On 7/14/23 1:23 PM, Pen Hall wrote:
I think i figured out my issue...
The issue was that 'board' is a pointer, and all of the ways I tried to
de-reference it, failed. I just tried the form
`(*board)[number][symbol][letter]` which worked to de-reference it.
`&(*board)[number][symbol][le
called
`loopBoard()` that loops through certain parts of `board`. I
then create a reference to the `Tile` struct at the current
position of `board`. This all works until I try to
de-reference that pointer. The result compiles, but I get the
exit code `-1073741819` whenever I run it. Below
of `board`. I
then create a reference to the `Tile` struct at the current
position of `board`. This all works until I try to de-reference
that pointer. The result compiles, but I get the exit code
`-1073741819` whenever I run it. Below is the function in
question. Do any of you have literally any clue
at the current position
of `board`. This all works until I try to de-reference that
pointer. The result compiles, but I get the exit code
`-1073741819` whenever I run it. Below is the function in
question. Do any of you have literally any clue about where I'm
screwing up?
```d
void loopBoard(Tile
On Sunday, 11 June 2023 at 21:32:11 UTC, Andy wrote:
[...]
void main() {
import std.stdio;
struct foo {}
foo* fooptr;
static if (is(typeof(fooptr) == T*, T))
writeln("fooptr is a pointer to a ", T.stringof);
else
On 6/11/23 5:25 PM, DLearner wrote:
Is there any way of picking up, at compile-time, all pointer types in
one test?
What you want is `is(T : void *)` but probably to also catch all
constancy flavors, `is(immutable(T) : immutable(void*))`
When you use `==` in an `is` expression, it's
Just to be clear where the argument goes (from templates parameters ext.):
``is(InputType : T*, T)``
std.traits : isPointer
or
``is(int* : T*, T)``
iteln("genptr is void*");
else
writeln("genptr is not void*");
}
```
which produces:
```
fooptr is not void*
fooptr is foo*
genptr is void*
```
Since `void*` variables accept _all_ pointer types, I expected
to see `fooptr is void*`.
Is there any way of
writeln("genptr is not void*");
}
```
which produces:
```
fooptr is not void*
fooptr is foo*
genptr is void*
```
Since `void*` variables accept _all_ pointer types, I expected to
see `fooptr is void*`.
Is there any way of picking up, at compile-time, all pointer
types in one test?
On Wednesday, 12 April 2023 at 21:00:04 UTC, John Chapman wrote:
You can also express it like this:
```d
extern(C) alias FuncPtr = void* function(void*);
```
Thank you! This is how I was planning to do anyway because other
that the fact that I like the syntax of that a little bit more,
On Wednesday, 12 April 2023 at 20:36:59 UTC, H. S. Teoh wrote:
IMO this is a bug either in D's syntax or in the parser. I'd
file an enhancement request.
In the meantime, you can use alias as a workaround:
---snip---
extern(C) void* abc(void*) {return null;}
alias FuncPtr =
On Wednesday, 12 April 2023 at 20:36:59 UTC, H. S. Teoh wrote:
---snip---
extern(C) void* abc(void*) {return null;}
alias FuncPtr = typeof();
You can also express it like this:
```d
extern(C) alias FuncPtr = void* function(void*);
```
d; }
> }
>
> ```
>
> Yes, I'm trying to "encapsulate" the Pthread (POSIX threads) API.
> Normally, the function pointer that is passed to "pthread_create" must
> be "extern(C)" and this is the complaining that the compile does. So,
> I'm thinking
(pthread_attr_t*) attr = null) {
pthread_create(_id, attr, func, arg);
}
@property:
pthread_t id() { return this.thread_id; }
}
```
Yes, I'm trying to "encapsulate" the Pthread (POSIX threads) API.
Normally, the function pointer that is passed to "pthread_create"
pointer will also work in D's
version, although it's probably a bit uglier.
On Thursday, 6 April 2023 at 00:46:26 UTC, Josh Holtrop wrote:
I am trying to port a small C project to D and am getting a
compilation error I don't understand.
It seems like the compiler is just missing some type hints. Try
this:
```d
import std.stdio;
__gshared immutable ubyte[4] data =
On Thursday, 6 April 2023 at 00:46:26 UTC, Josh Holtrop wrote:
```
constarrptr.d(5): Error: cannot use non-constant CTFE pointer
in an initializer `cast(immutable(ubyte)*)data`
```
Why? And how can I do the equivalent to what I have been doing
in C? I want these pointers to be generated
On Thursday, 6 April 2023 at 00:59:12 UTC, Mathias LANG wrote:
immutable ubyte[4] data = [1, 2, 3, 4];
Using a static array instead of a slice will do the trick. You
can leave the `__gshared` if you want, but it is redundant on a
global, initialized `immutable` variable.
Yes, thank you,
really understand why.
the error message gives a slight clue:
```
cannot use non-constant CTFE pointer in an initializer ‘&[cast(ubyte)1u,
cast(ubyte)2u, cast(ubyte)3u, cast(ubyte)4u][0]’
```
That *isn't* a CTFE pointer, it's a pointer to a static immutable. Yes,
the initialization v
immutable ubyte[4] data = [1, 2, 3, 4];
Using a static array instead of a slice will do the trick. You
can leave the `__gshared` if you want, but it is redundant on a
global, initialized `immutable` variable.
;, *p);
return 0;
}
```
This fails to compile with gdc:
```
constarrptr.d:5:45: error: cannot use non-constant CTFE pointer
in an initializer ‘&[cast(ubyte)1u, cast(ubyte)2u, cast(ubyte)3u,
cast(ubyte)4u][0]’
5 | __gshared immutable(immutabl
On Saturday, 11 March 2023 at 13:37:26 UTC, ag0aep6g wrote:
On 11.03.23 14:22, rempas wrote:
On Saturday, 11 March 2023 at 12:59:59 UTC, ag0aep6g wrote:
alias Foo(T : U*, U) = Foo!U;
alias Foo(T) = T;
static assert(is(Foo!(int*) == int));
static assert(is(Foo!(int**) == int));
static
On 11.03.23 14:22, rempas wrote:
On Saturday, 11 March 2023 at 12:59:59 UTC, ag0aep6g wrote:
alias Foo(T : U*, U) = Foo!U;
alias Foo(T) = T;
static assert(is(Foo!(int*) == int));
static assert(is(Foo!(int**) == int));
static assert(is(Foo!(int***) == int));
static assert(is(Foo!(int) ==
On Saturday, 11 March 2023 at 12:59:59 UTC, ag0aep6g wrote:
alias Foo(T : U*, U) = Foo!U;
alias Foo(T) = T;
static assert(is(Foo!(int*) == int));
static assert(is(Foo!(int**) == int));
static assert(is(Foo!(int***) == int));
static assert(is(Foo!(int) == int));
Wait, but "Foo" is defined
1 - 100 of 1008 matches
Mail list logo
