On Friday, 10 May 2024 at 13:27:40 UTC, Dukc wrote:
Steven Schveighoffer kirjoitti 10.5.2024 klo 16.01:
On Friday, 10 May 2024 at 11:05:28 UTC, Dukc wrote:
This also gets inferred as `pure` - meaning that if you use
it twice for the same `WeakRef`, the compiler may reuse the
result of the firs
Steven Schveighoffer kirjoitti 10.5.2024 klo 16.01:
On Friday, 10 May 2024 at 11:05:28 UTC, Dukc wrote:
This also gets inferred as `pure` - meaning that if you use it twice
for the same `WeakRef`, the compiler may reuse the result of the first
dereference for the second call, without checking w
On Friday, 10 May 2024 at 11:05:28 UTC, Dukc wrote:
This also gets inferred as `pure` - meaning that if you use it
twice for the same `WeakRef`, the compiler may reuse the result
of the first dereference for the second call, without checking
whether the referred value has changed!
This wou
evilrat kirjoitti 9.5.2024 klo 18.19:
```d
struct WeakRef(T) {
private size_t _handle; // same size as a pointer
this(T* ptr) {
_handle = cast(size_t) ptr;
}
T* getRef() {
return cast(T*) _handle;
}
// do the rest ...
}
```
[1] https://code.dlan
de for ref counted struct we can't help
you.
As for weak references, maybe you could "trick" the GC by using
the fact that simple types are not scanned, i.e. do something
like this but I have no idea if this is going to work at all,
alternatively you can also try using `ubyte[s
A "weak reference" (in the sense that I'm referring to) is a
feature in some programming languages for a reference to an
object that doesn't prevent the GC from destroying that object.
My current understanding is that D doesn't have weak references,
though I've
(as I the destructor was
never called), why would some of the array elements be null?
I'll answer my own question; because the thing assigned to the
array was already null.
Anyway, I managed to fix the segfaults. In the latest two
commits, I have turned some pointers into references.
On 09/03/2024 8:49 PM, Liam McGillivray wrote:
But that begs the question; why? Don't dynamic arrays always start with
a length of 0? If the array was only extended when valid objects were
appended using the append operator |~=|, and none of those objects were
deleted (as I the destructor was n
class reference is inherently a pointer.
So when you checked for nullability in the foreach loop of
mission:
```d
if (startTile.occupant !is null && (*startTile.occupant) !is
null) {
```
I think I'm starting to understand better. I was thrown off
somewhere when I read that &qu
Something that I have noticed that you are still doing that was pointed
out previously is having a pointer to a class reference.
Stuff like ``Tile* currentTile;`` when it should be ``Tile currentTile;``
A class reference is inherently a pointer.
So when you checked for nullability in the forea
With [my game project](https://github.com/LiamM32/Open_Emblem), I
have been getting segmentation faults that are unexplainable at
my knowledge level. They seem to happen when doing a "foreach"
loop through an array of references.
Skip to the bolded text if you don't want to re
On Thursday, 15 February 2024 at 20:10:15 UTC, Paul Backus wrote:
On Thursday, 15 February 2024 at 18:12:42 UTC, realhet wrote:
There was an attempt to fix it, but it looks like the PR author
wasn't able to get it working correctly in all cases.
That means I will solve this by putting the UDAs
On Thursday, 15 February 2024 at 18:12:42 UTC, realhet wrote:
Hello,
Today I tried to upgrade my sources to the latest LDC, but
failed with this unfortunate error.
```
import std;
struct S{ E e; }
enum E
{
@S(e2) e1,
@S(e1) e2
}
```
Looks like someone reported a similar bug in 201
On Thursday, 6 July 2023 at 22:44:27 UTC, Alexibu wrote:
I just encountered this problem in recently released debian
bookworm (gdc 12.2.0), I was able to fix these undefined
lambdas inside std library with -fall-instantiations, and a
bunch of other undefined lambdas in my own code by changin
On Saturday, 28 May 2022 at 14:44:56 UTC, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you
want most the time.
But I know what's going on now, it is the template emissi
On Monday, 14 November 2022 at 20:37:12 UTC, kdevel wrote:
On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote:
Just came here to say I hit the same bug, here's my import
list:
* https://issues.dlang.org/show_bug.cgi?id=19937
object._d_assert_fail linker error if compiling with
-ch
On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote:
Just came here to say I hit the same bug, here's my import list:
* https://issues.dlang.org/show_bug.cgi?id=19937
object._d_assert_fail linker error if compiling with
-checkaction=context
* https://issues.dlang.org/show_bug.cgi?
On Saturday, 28 May 2022 at 23:02:45 UTC, kdevel wrote:
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote:
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest p
On Saturday, 28 May 2022 at 22:23:34 UTC, kdevel wrote:
On Saturday, 28 May 2022 at 15:10:25 UTC, Steven Schveighoffer
wrote:
[...]
Is this specific to gdc, or does it happen for other compilers
as well?
The former.
Please check the dlang versions of all compilers. The template
emission sc
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote:
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
https://run.dlang.io
On Saturday, 28 May 2022 at 15:10:25 UTC, Steven Schveighoffer
wrote:
[...]
Is this specific to gdc, or does it happen for other compilers
as well?
The former.
On Saturday, 28 May 2022 at 14:37:07 UTC, kdevel wrote:
dmd:
```
$ dmd -c ppinsta.d
$ dmd -c parser.d
$ dmd -of=ppinsta ppinsta.o parser.o
$ ./ppinsta
[]
```
(checking ldc/ldmd2 later)
```
$ ldc2 -c ppinsta.d && ldc2 -c parser.d && ldc2 -of=ppinsta
ppinsta.o parser.o && ./ppinsta
[]
$ ldmd2
On 5/28/22 10:44 AM, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you want most
the time.
But I know what's going on now, it is the template emission thing, the
compil
On Saturday, 28 May 2022 at 14:44:56 UTC, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you
want most the time.
But I know what's going on now, it is the template emissi
On Saturday, 28 May 2022 at 14:16:51 UTC, kdevel wrote:
$ gdc -o ppinsta ppinsta.d parser.d
Compiling together is faster anyway this is prolly what you want
most the time.
But I know what's going on now, it is the template emission
thing, the compiler thinks, since it is from std, it was al
On Saturday, 28 May 2022 at 13:55:09 UTC, Tejas wrote:
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
I am trying to build a project with GDC. It successfully
compiles with dmd and ldmd2. When I use gdc in one go the
binary is successfully build:
[...]
Is seperate compilation worki
On Saturday, 28 May 2022 at 14:03:13 UTC, Adam D Ruppe wrote:
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
gdc -o ppinsta ppinsta.o esah.o evaluate.o jsr.o jsw.o
parser.o ptvr.o stack.o testdatagenerator.o
You might need to add -lgphobos or -lgphobos2 or whatever it is
called too e
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
Any ideas?
ppinsta.d
```
import std.stdio : write, writeln;
import parser; // <- comment this out and gdc links
void main ()
{
string [string] h;
writeln (h);
}
```
parser.d
```
module parser;
import std.regex : regex;
private imm
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
gdc -o ppinsta ppinsta.o esah.o evaluate.o jsr.o jsw.o parser.o
ptvr.o stack.o testdatagenerator.o
You might need to add -lgphobos or -lgphobos2 or whatever it is
called too explicitly.
On Saturday, 28 May 2022 at 13:12:46 UTC, kdevel wrote:
I am trying to build a project with GDC. It successfully
compiles with dmd and ldmd2. When I use gdc in one go the
binary is successfully build:
[...]
Is seperate compilation working successfully for dmd and ldc?
The only bug I know of
I am trying to build a project with GDC. It successfully compiles
with dmd and ldmd2. When I use gdc in one go the binary is
successfully build:
```
$ gdc -o ppinsta esah.d evaluate.d jsr.d jsw.d parser.d ppinsta.d
ptvr.d stack.d testdatagenerator.d
```
Though after compiling separately the
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote:
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
https://run.dlang.io/is/GYDUBz
File an issue, I'd say. The worst thing that can
zstack.d:
```
module zstack;
import std.stdio: writeln;
void bar (int [] i)
{
writeln ("i: ", i);
}
unittest {
int [] arr;
bar (arr);
}
```
zrepo.d:
```
module parser;
import std.regex;
import zstack;
```
```
$ dmd -g -i -unittest -checkaction=context -main -run zrepro
2>&1 | ddem
On Saturday, 12 March 2022 at 13:12:25 UTC, vit wrote:
```d
enum touch_T = __traits(hasMember, T, "touch");
```
I think you meant build instead of touch?
```d
struct Query {
public const SharedPtr!Builder builder;
}
interface Builder {
void build(ref Query query);
}
struct SharedPtr(T) {
}
```
```
src/app.d(3,1): Error: no size because of forward references
src/app.d(4,18): Error: template instance
`app.SharedPtr!(Builder)` error instantiating
```
Hello there,
I got a weird compilation error which was hard to debug (even for
just a little program) and I thought, this is quite related to
this thread. This is my error message:
```
***search.d(42,1): Error: class ***.XXX has forward references
***box.d(21,32): Error: template instance
n every reallocation, as references to the array
could exist anywhere in the program, be that on the stack,
heap, even on other threads. That's the performance side of it.
No... Not true. But either way, D and Golang only have simple
windows onto memory rather than dynamic array ADTs. Tha
Alright, thanks for sharing this thoughts and arguments!
e chosen to define
it'. A more involved answer is that changing every reference is
prohibitively expensive - it would require the equivalent of a GC
collection on every reallocation, as references to the array
could exist anywhere in the program, be that on the stack, heap,
even on othe
On Wednesday, 11 November 2020 at 10:17:09 UTC, zack wrote:
I am new to D. Appending to an array can lead to reallocation,
that's clear. But why is the "reference" b not changed
accordingly to the new position and still points to "old"
memory? Why is b not also changed when reallocating array a
I am new to D. Appending to an array can lead to reallocation,
that's clear. But why is the "reference" b not changed
accordingly to the new position and still points to "old" memory?
Why is b not also changed when reallocating array a and the old
data getting invalid/freed?
auto a = [55,10,2
On Monday, 2 November 2020 at 10:50:06 UTC, Severin Teona wrote:
Hi guys!
I build the druntime for an ARM Cortex-M based microcontroller
and I trying to create an application and link it with the
druntime. I am also using TockOS[1], which does not implement
POSIX thread calls and other OS-dep
On 11/2/20 1:50 PM, Severin Teona wrote:
Hi guys!
I build the druntime for an ARM Cortex-M based microcontroller and I
trying to create an application and link it with the druntime. I am also
using TockOS[1], which does not implement POSIX thread calls and other
OS-dependent implementations.
Hi guys!
I build the druntime for an ARM Cortex-M based microcontroller
and I trying to create an application and link it with the
druntime. I am also using TockOS[1], which does not implement
POSIX thread calls and other OS-dependent implementations. As I
was looking through the errors I got
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote:
Could you help me by telling me what libraries (and how) should
I statically compile and link to the druntime? The
microcontroller's CPU is an ARM Cortex-M4, and the libraries
should be able to be compiled for this architecture.
On Monday, 19 October 2020 at 06:25:17 UTC, Severin Teona wrote:
- 'munmap'
- 'clock_gettime'
- `pthread_mutex_trylock'
etc.
These are typically calls found in a Unix system, Linux for
example. In a microcontroller you will likely not support these
at all except clock_gettime.
You need to
h the flag
'BUILD_SHARED_LIBS=OFF' (as the microcontrollers don't work with
dynamic libraries), and when I try to link the druntime with the
application for the microcontroller, I get many errors about
undefined references (references that would normally be present
in those dynamic li
On Thursday, 28 November 2019 at 21:49:09 UTC, Per
Also, what happens if `C` doesn't fit on the stack?
This is OS specific I think. For example on Linux at the end of
the stack there is a guard page and when you hit it the process
will segfault.
On Monday, 25 November 2019 at 13:09:44 UTC, mipri wrote:
class C {
int x;
this(int n) { x = n; }
}
int heap() {
auto x = new C(2); // vgc: `new` causes a GC allocation
return x.x;
}
/+
int example.heap():
sub rsp, 8
mov edi, OFFSET FLAT:example.C.__Class
On Monday, 25 November 2019 at 13:09:44 UTC, mipri wrote:
gdc assembly. ldc eliminates the object entirely.
DIP-1000 kicks comes to the rescue here aswell:
class C
{
@safe pure nothrow @nogc:
this(int x)
{
this.x = x;
}
int x;
}
C leakClass() @safe pure nothrow
{
On Monday, 25 November 2019 at 13:09:44 UTC, mipri wrote:
gdc assembly. ldc eliminates the object entirely.
Thanks.
On Monday, 25 November 2019 at 12:08:54 UTC, Per Nordlöw wrote:
On Monday, 25 November 2019 at 08:22:02 UTC, Jacob Carlborg
wrote:
On Sunday, 24 November 2019 at 21:49:19 UTC, Per Nordlöw wrote:
I guess we need a builtin language qualifier for scoped
classes for that to work, right?
We have t
On Monday, 25 November 2019 at 08:22:02 UTC, Jacob Carlborg wrote:
On Sunday, 24 November 2019 at 21:49:19 UTC, Per Nordlöw wrote:
I guess we need a builtin language qualifier for scoped
classes for that to work, right?
We have that:
scope a = new Object;
—
/Jacob Carlborg
Ahh, nice.
Does
On Sunday, 24 November 2019 at 21:49:19 UTC, Per Nordlöw wrote:
I guess we need a builtin language qualifier for scoped classes
for that to work, right?
We have that:
scope a = new Object;
—
/Jacob Carlborg
On Sunday, 24 November 2019 at 14:21:48 UTC, Adam D. Ruppe wrote:
On Sunday, 24 November 2019 at 14:19:23 UTC, Per Nordlöw wrote:
Why doesn't DIP-1000 include such escape analysis?
did you enable it with the command line switch?
furthermore i *think* it onyl works o @safe stuff, not @trusted
On Sunday, 24 November 2019 at 14:19:23 UTC, Per Nordlöw wrote:
Why doesn't DIP-1000 include such escape analysis?
did you enable it with the command line switch?
furthermore i *think* it onyl works o @safe stuff, not @trusted
stuff.
On Sunday, 24 November 2019 at 12:51:53 UTC, rikki cattermole
wrote:
"Allocates a class object right inside the current scope,
therefore avoiding the overhead of new. This facility is
unsafe; it is the responsibility of the user to not escape a
reference to the object outside the scope."
http
"Allocates a class object right inside the current scope, therefore
avoiding the overhead of new. This facility is unsafe; it is the
responsibility of the user to not escape a reference to the object
outside the scope."
https://dlang.org/phobos/std_typecons.html#.scoped
Why doesn't DMD detect invalid out-of-scope references to scoped
class instances?
Example:
@safe:
class C
{
@safe pure:
this()
{
}
int x;
}
@trusted unittest
{
C f()
{
import std.typecons : scoped;
auto x = scoped!C();
return x;
}
On Thursday, 31 October 2019 at 12:37:55 UTC, user1234 wrote:
struct S
{
S*[] children;
}
because otherwise when you declare the array the compiler has
not finished the semantic ana of S.
---
struct Test
{
Test[] t;
}
---
Works today. Putting pointers into the container (and thus ha
On Thursday, 31 October 2019 at 12:37:55 UTC, user1234 wrote:
On Thursday, 31 October 2019 at 12:29:28 UTC, Tobias Pankrath
wrote:
[...]
Try
struct S
{
S*[] children;
}
because otherwise when you declare the array the compiler has
not finished the semantic ana of S.
so S size is not
On Thursday, 31 October 2019 at 12:29:28 UTC, Tobias Pankrath
wrote:
My Problem:
--- (https://run.dlang.io/is/CfLscj)
import std.container.array;
import std.traits;
struct Test
{
Test[] t;
}
struct Test2
{
Array!Test2 t;
}
int main()
{
return FieldTypeTuple!Test.length + FieldTy
My Problem:
--- (https://run.dlang.io/is/CfLscj)
import std.container.array;
import std.traits;
struct Test
{
Test[] t;
}
struct Test2
{
Array!Test2 t;
}
int main()
{
return FieldTypeTuple!Test.length + FieldTypeTuple!Test2;
}
---
I've found https://issues.dlang.org/show_bug.cgi
On Saturday, 7 September 2019 at 13:01:38 UTC, Jacob Carlborg
wrote:
On 2019-09-06 21:03, Max Samukha wrote:
Is there any practical use of having identically named .d and
.di alongside?
Same as in C/C++. This allows you to have a header file if you
want to distribute a closed source library.
On 2019-09-06 21:03, Max Samukha wrote:
Is there any practical use of having identically named .d and .di
alongside?
Same as in C/C++. This allows you to have a header file if you want to
distribute a closed source library.
--
/Jacob Carlborg
On Friday, 6 September 2019 at 17:54:51 UTC, Adam D. Ruppe wrote:
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:
That file was silently imported by the compiler (probably, a
bug).
That's by design - the automatic module import lookups actually
always look for .di file first,
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:
That file was silently imported by the compiler (probably, a
bug).
That's by design - the automatic module import lookups actually
always look for .di file first, then .d files.
On Friday, 6 September 2019 at 16:55:31 UTC, Max Samukha wrote:
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
If that is happening you hit a bug.
It seems unlikely though.
Could you elaborate a bit? How should extern(C/C++) definitions
be mangled - fully qualified or not,
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When co
On Friday, 6 September 2019 at 15:32:07 UTC, 0xEAB wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
What compiler version are you using?
DMD64 D Compiler v2.088.0-1-g4011382ea, linux
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the
function
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
What compiler version are you using?
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the
function in 'a.o' is mangled as 'foo', but the reference in
'test.o' is
On 2019-04-28 16:18:59 +, kdevel said:
This compiles with dmd v2.085.1:
$ cat A/a.d
module A.a;
import A.b;
$ cat A/b.d
module A.b;
struct myStruct {
int i;
}
$ cat A/c.d
module A.c;
import A.a;
import A.b;
struct myOtherStruct {
myStruct ms;
}
void main ()
{
import std.stdi
On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote:
On 2019-04-28 11:44:03 +, Mike Parker said:
They're different symbols because they're in different
modules. The module and package name is part of the symbol
name.
Ok, that's what I assumed too.
Just import A.b in A.a.
On 2019-04-28 11:44:03 +, Mike Parker said:
They're different symbols because they're in different modules. The
module and package name is part of the symbol name.
Ok, that's what I assumed too.
Just import A.b in A.a.
Won't help. I just commented the lines DStep generated for forward
On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote:
One more problem now showing up, when I do this:
A/a.d
module A.a;
struct myStruct;
A/b.d
module A.b;
struct myStruct {...}
A/c.d
module A.c;
import A;
struct myOtherStruc
On 2019-04-27 16:30:48 +, Adam D. Ruppe said:
This will never work in D. The module needs to work by itself. It can
see public imports from another module it itself imports:
module A.c;
import A; // thanks to this, it can see a `public import A.a;` from the
A package..
But without tha
On 2019-04-27 16:30:48 +, Adam D. Ruppe said:
There is no "same level" really (except for the `package` protection
level); it is just inside the module or outside the module for imports.
Hi Adamn, ok, got it. The docs are indicating that the "public import"
is only working along the neste
On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote:
I thought that public only applies to the upward chain, not to
the same level.
There is no "same level" really (except for the `package`
protection level); it is just inside the module or outside the
module for imports.
But
a bit more:
I use DStep to convert some C library headers. And these use forward
references to structs.
A/a.d
module A.a;
struct myStruct;
A/b.d
module A.b;
struct myStruct {...}
A/c.d
module A.c;
struct myOtherStruct {
myStru
On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:
import A.a;
`import` by itself is a private import, meaning it cannot be seen
from outside the module.
Make it `public import` and it can be seen from the outside; the
other modules importing it can access them too.
A/a.d has module A.a;
A/b.d has module A.b;
A/package.d
import A.a;
import A.b;
A.b needs to access something from A.a
I assumed if I do
import package.d
that A.b sees the content of A.a now and doens't need an explicit line with
a/b.d
import A.a;
But this
("has forward references");
return;
}
// ...
}
}
Does that mean that the scope pointer is already set when this
AggregateDeclaration is being visited? If it's a bug, perhaps someone
can think of a way of reproducing it.
Ali
On Tuesday, 12 June 2018 at 20:30:22 UTC, Steven Schveighoffer
wrote:
On 6/12/18 4:14 PM, bauss wrote:
What could cause that error?
I cannot find anything in the documentation nor does the error
message itself give much information.
A forward reference that can't be figured out by the compil
On 6/12/18 4:14 PM, bauss wrote:
What could cause that error?
I cannot find anything in the documentation nor does the error message
itself give much information.
A forward reference that can't be figured out by the compiler. This is
one of the DMD front end's real weak spots.
I can't real
What could cause that error?
I cannot find anything in the documentation nor does the error
message itself give much information.
I can't really give a good example, but I can tell as much as I
have a few inheritances of classes using templates.
I just don't think that would be the issue.
still seems to be some
strangeness about forward references.
There are frequently issues with forward references. They are supposed
to always work, but it's not always the case.
-Steve
about forward references.
Thanks till now i guess :P
On 2/25/18 4:25 PM, Jiyan wrote:
Hi,
is there any document or text describing forward references?
It is kinda strange, i implemented a list structure which is kinda like
this:
struct list(T)
{
private:
struct node
{
T val;
node* next;
node* prev;
}
node* head;
node* last;
size_t size
works for me with 2.076.
Hi,
is there any document or text describing forward references?
It is kinda strange, i implemented a list structure which is
kinda like this:
struct list(T)
{
private:
struct node
{
T val;
node* next;
node* prev;
}
node* head;
node* last;
size_t size;
.
}
The thing is when i
On Sunday, 14 January 2018 at 00:55:27 UTC, Jonathan M Davis
wrote:
[...]
It the simplest case, it means that the compiler does a bitwise
copy rather than a deep copy, but in other cases, it means that
the compiler is able to use the object in-place rather than
creating a deep copy that it
On Friday, January 12, 2018 01:59:49 Tony via Digitalmars-d-learn wrote:
> On Monday, 8 January 2018 at 23:31:27 UTC, Jonathan M Davis wrote:
> > auto foo(T)(auto ref T t)
> > {
> >
> > return t;
> >
> > }
> >
> > foo(42);
> >
> > will result in foo being instantiated as
> >
> > int foo(int t)
On Monday, 8 January 2018 at 23:31:27 UTC, Jonathan M Davis wrote:
auto foo(T)(auto ref T t)
{
return t;
}
foo(42);
will result in foo being instantiated as
int foo(int t)
{
return t;
}
whereas
int i;
foo(i);
will result in foo being instantiated as
int foo(ref int t)
{
retur
would recommend to ignore auto ref for rvalue references. It
generates 2^N functions where N is the amount of auto ref parameters.
That the most awful template bloat I've ever seen.
It only generates 2^N functions if you call it 2^N different ways.
Most of the time you call it the same way.
rvalue references. It
generates 2^N functions where N is the amount of auto ref
parameters. That the most awful template bloat I've ever seen.
It only generates 2^N functions if you call it 2^N different
ways. Most of the time you call it the same way.
-Steve
If that would be tr
On 1/10/18 3:08 AM, Dgame wrote:
On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote:
But current auto ref is what we have, so I would recommend using it.
I would recommend to ignore auto ref for rvalue references. It generates
2^N functions where N is the amount of
On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven
Schveighoffer wrote:
But current auto ref is what we have, so I would recommend
using it.
I would recommend to ignore auto ref for rvalue references. It
generates 2^N functions where N is the amount of auto ref
parameters. That the most
On 1/8/18 6:07 PM, Jiyan wrote:
Sry i know i asked it already in IRC:
Are rvalue references already solved with auto ref?
https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it
Says rvalues are moved!
But an rvalue move is cheaper. You construct
1 - 100 of 423 matches
Mail list logo
