Re: DIP 1016 and const ref parameters
On Thursday, 20 June 2019 at 00:30:35 UTC, Jonathan M Davis wrote: Ultimately, if you want a function to accept both rvalues and lvalues as efficiently as posible, just templatize it and use auto ref. I'm aware of auto ref, and I've used it to solve this same problem when I had a template, but as you say it works with templates only, not plain non-templated functions. Or another possible optimization: in case the function is declared with const parameters (not ref), lvalues can be accessed by ref as an optimization; and rvalues can use the same trick they do now. As a consequence, no unnecessary copies ever -- thanks to const. This is even better because I don't have to type so many ref, which were never part of the algorithm but baby instructions for the dumb compiler (const & everywhere is one of the ugliest and most annoying things in C++). Either way, const has nothing to do with any of this. You're free to mark a ref or auto ref parameter as const, but it has nothing to do with whether rvalues are accepted, and it will never have anything to do with whether rvalues are accepted. D's const is far too restrictive for it to make any sense to base rvalue stuff on it like they do in C++. The DIP has nothing do with const and everything to do with ref. [...] Regardless, the refness of a parameter is part of its type, and I'd be very surprised if it were ever changed so that any parameter that was not marked with ref was ever ref. I know. That's why I look to the general solution to bind ref rvalues as a solution to bind const ref in particular. By the way it looks to me that most of the demand in the D community to bind to ref is for chain return ref functions. I wonder why no one in D is bothered about not being able to use const ref parameters easily, while in C++ everyone is bothered to do it, and passing a read-only struct/class by value won't pass by the least alert reviewer. My guess is that in D it's very often ranges that get passed, and these are passed as slices, which are by nature refs that don't reallocate, and can also be decorated const. Still the const ref concern stays more or less. Rust has a solution too (&) of course. My new idea about const only would be a compiler optimization, not part of the language/ABI. The same way as RVO, which under the hood (but not at the ABI level) is implemented as changing the function signature completely. This const optimization would not change the function's ABI either. However I see a practical problem to implement this optimization idea. RVO changes the function signature under the hood, but in the same way for every occurrence/call. This const optimization would need to change the signature, but only in the occurrences where the function is called with lvalues instead,not rvalues. So in practice turning every function with const struct parameters as a template; but under the hood, maintaining a single plan signature in the ABI. I wonder if this is as easy or feasible as RVO.
Re: create and initialise array
On Thursday, 20 June 2019 at 01:06:09 UTC, Alex wrote:
Is there a way of creating and initialising a dynamic array ?
for example I am doing this:
auto arr = new float[];
arr[] = 0.0f;
Profiling indicates that the compiler (gdc) is spending
significant time memsetting the whole array to something (nan
?) before I immediately memset it to 0.0f.
It would be good if there was a way of either void initialing
it so that the first memset is avoided or a way of replacing
the init value with a different one.
Thanks,
Alex
What about:
//DMD64 D Compiler 2.072.2
import std.stdio;
import std.array;
void main(){
auto s = uninitializedArray!(float[])(100);
s[] = 0.0f;
writeln(s[0]);
}
Matheus.
create and initialise array
Is there a way of creating and initialising a dynamic array ? for example I am doing this: auto arr = new float[]; arr[] = 0.0f; Profiling indicates that the compiler (gdc) is spending significant time memsetting the whole array to something (nan ?) before I immediately memset it to 0.0f. It would be good if there was a way of either void initialing it so that the first memset is avoided or a way of replacing the init value with a different one. Thanks, Alex
Re: DIP 1016 and const ref parameters
On Wednesday, June 19, 2019 4:45:04 PM MDT XavierAP via Digitalmars-d-learn
wrote:
> On Wednesday, 19 June 2019 at 21:06:48 UTC, XavierAP wrote:
> > Now with an rvalue returned from get, interesting, no copy.
> > Still, I wonder what really happened. Again, moving between
> > stacks would still be work. And a different optimization can
> > explain this non copy, for example inlining.
>
> My guess as to what may be happening (I've never used a
> disassembler and I wasn't planning on starting today yet) is
> simple. The rvalue returned by get() is possibly not popped out
> from the stack, but rather left in the same place as sum() is
> called on it. This is actually optimum, but hardly an
> optimization, rather it's the easiest and least effort for the
> compiler. Again this would mean no moving -- which is good,
> because moving is work.
>
> And also, this doesn't work in the general case. If parameters
> are by value, everything works perfect when I pass rvalues (but
> we already knew that, not answering my question); however if I
> pass lvalues they will be copied every time.
>
> So my question is open... what about const ref rvalue parameters?
>
> Or another possible optimization: in case the function is
> declared with const parameters (not ref), lvalues can be accessed
> by ref as an optimization; and rvalues can use the same trick
> they do now. As a consequence, no unnecessary copies ever --
> thanks to const. This is even better because I don't have to type
> so many ref, which were never part of the algorithm but baby
> instructions for the dumb compiler (const & everywhere is one of
> the ugliest and most annoying things in C++).
If you want to know the current state of passing rvalues by ref, watch
Andrei's talk. If you've already watched it, then you know what the current
plan is, and I don't understand what you're trying to find out. Until the
DIP is implemented, if you want a function to accept lvalues by ref and
still accept rvalues, then use auto ref. e.g.
void foo(T)(auto ref T t) {...}
The refness of the parameter will be inferred based on whether it's given an
lvalue or rvalue. If a templated function doesn't fit the bill, then you
have to overload the function based on ref. e.g.
void foo(ref T t) {...}
void foo(T t) {...}
Either way, const has nothing to do with any of this. You're free to mark a
ref or auto ref parameter as const, but it has nothing to do with whether
rvalues are accepted, and it will never have anything to do with whether
rvalues are accepted. D's const is far too restrictive for it to make any
sense to base rvalue stuff on it like they do in C++. The DIP has nothing do
with const and everything to do with ref.
Regardless, the refness of a parameter is part of its type, and I'd be very
surprised if it were ever changed so that any parameter that was not marked
with ref was ever ref. Certainly, it wouldn't work for the refness to change
based on the argument, because the refness is part of the function's type
and determines how the generated code passes the argument. The closest that
we have and likely ever will have to the same function accepting by ref and
by value is auto ref, and that only works, because it's a template, and
different versions of the function are generated based on what's passed.
It's never the case that the exact same function takes some values by ref
and some not. Even once ref parameters accept rvalues, they're going to have
to be turned into lvalues underneath the hood for that to work. It just
won't require you to do it explicitly anymore, and the lifetime of the
generated lvalue will be the same as any temporary.
Ultimately, if you want a function to accept both rvalues and lvalues as
efficiently as posible, just templatize it and use auto ref.
- Jonathan M Davis
Re: DIP 1016 and const ref parameters
On Wednesday, 19 June 2019 at 20:18:58 UTC, Max Haughton wrote: On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis wrote: On Wednesday, June 19, 2019 12:28:12 PM MDT XavierAP via Digitalmars-d-learn wrote: [...] The DIPs are here: https://github.com/dlang/DIPs [...] DIP1014 has not been implemented in DMD or druntime yet, AFAIK I have two open PRs for the druntime[1] and Phobos[2] implementations, but no dmd yet. [1] https://github.com/dlang/druntime/pull/2638 [2] https://github.com/dlang/phobos/pull/7075
Re: The problem with the conversion.
On Wednesday, 19 June 2019 at 17:28:38 UTC, XavierAP wrote:
Also, the return type of SDL_LoadBMP is a pointer, SDL_Surface*
not just SDL_Surface.
Or just use auto of course if you prefer:
void load (string path)
{
import std.string : toStringz;
auto ab = SDL_LoadBMP (path.toStringz);
Re: DIP 1016 and const ref parameters
On Wednesday, 19 June 2019 at 21:06:48 UTC, XavierAP wrote: Now with an rvalue returned from get, interesting, no copy. Still, I wonder what really happened. Again, moving between stacks would still be work. And a different optimization can explain this non copy, for example inlining. My guess as to what may be happening (I've never used a disassembler and I wasn't planning on starting today yet) is simple. The rvalue returned by get() is possibly not popped out from the stack, but rather left in the same place as sum() is called on it. This is actually optimum, but hardly an optimization, rather it's the easiest and least effort for the compiler. Again this would mean no moving -- which is good, because moving is work. And also, this doesn't work in the general case. If parameters are by value, everything works perfect when I pass rvalues (but we already knew that, not answering my question); however if I pass lvalues they will be copied every time. So my question is open... what about const ref rvalue parameters? Or another possible optimization: in case the function is declared with const parameters (not ref), lvalues can be accessed by ref as an optimization; and rvalues can use the same trick they do now. As a consequence, no unnecessary copies ever -- thanks to const. This is even better because I don't have to type so many ref, which were never part of the algorithm but baby instructions for the dumb compiler (const & everywhere is one of the ugliest and most annoying things in C++).
Re: Is it possible to escape a reserved keyword in Import/module?
On Wednesday, 19 June 2019 at 21:21:53 UTC, XavierAP wrote: On Wednesday, 19 June 2019 at 18:56:57 UTC, BoQsc wrote: I would like to make sure that my modules do not interfere with d lang. Is there any way to escape reserved words? The only reason C# allows this is for interop or code generation for other languages that use the same keyword. For example "class" is an HTML attribute. There is no excuse to do this for any other reason -- and C# gurus would also agree. I would like to make sure that my modules do not interfere Then don't name them as keywords :) I used twice a similar system (&) that exists in ObjFPC. The context was a RTTI inspector and allowed to have enum members displayed without using a prefix or a translation table. Just to say, it's rarely useful but nice to have. I would have preferred # so much more that the "body" -> "do" change, which was a bad decision because focused on a detail. You mentioned "class"...
Re: Is it possible to escape a reserved keyword in Import/module?
On Wednesday, 19 June 2019 at 18:56:57 UTC, BoQsc wrote: I would like to make sure that my modules do not interfere with d lang. Is there any way to escape reserved words? The only reason C# allows this is for interop or code generation for other languages that use the same keyword. For example "class" is an HTML attribute. There is no excuse to do this for any other reason -- and C# gurus would also agree. I would like to make sure that my modules do not interfere Then don't name them as keywords :)
Re: Is it possible to escape a reserved keyword in Import/module?
On Wednesday, 19 June 2019 at 19:07:30 UTC, Jonathan M Davis wrote: On Wednesday, June 19, 2019 12:56:57 PM MDT BoQsc via Digitalmars-d-learn wrote: I would like to make sure that my modules do not interfere with d lang. Is there any way to escape reserved words? https://dlang.org/spec/lex.html#keywords > import alias; C:\Users\Juozas\Desktop\om.d(2): Error: identifier expected following import C:\Users\Juozas\Desktop\om.d(2): Error: ; expected > module abstract; C:\Users\Juozas\Desktop\commands\alias.d(1): Error: identifier expected following module You can never use keywords as identifiers in D (or any language in the C family that I've ever heard of). C# can use them when they are prefixed with a little "@" before [1]. At some point the idea was brought for D [2]. [1] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/index [2] https://github.com/dlang/DIPs/pull/52/files
Re: DIP 1016 and const ref parameters
Hmmm I know about move semantics, and C++11 etc. I just don't
know how related all that is to my original question. :)
On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis
wrote:
though if I understand correctly with RVO, it may just place
the return value outside of the function in the first place to
avoid needing to move.
Indeed, unrelated:
https://dlang.org/glossary.html#nrvo
func(foo(), bar(42), baz("hello"));
assuming that none of these functions return by ref, func is
taking temporaries from several functions, and the spec
actually guarantees that they will not be copied.
Where does the spec say this?? (This case is actually my
question.)
However, please understand that naive moving is not an answer for
me. Moving is still work! It would still be more efficient if
foo's parameters were references/pointers -- if D functions were
able to bind rvalues as such.
Theoretically a compiler could optimize by realizing that if a
value parameter is not modified by the function (and it doesn't
fit in a register etc), it can be read at its original
location/address in the caller's stack, i.e. by
reference/pointer. Again, nothing to do with moving. But I really
doubt the D compilers do this, first because C++ probably don't,
or else all C++ programmers are wasting their fingers and screen
real state typing const & zillions of times; and second because D
would not be able to bind as ref in case the argument happened to
be an rvalue.
__
OK so I try to experiment myself:
/**/
struct XY
{
int x, y;
~this() { writeln("Destroyed!"); }
}
int sum(XY p) { return p.x + p.y; }
void main()
{
XY p;
p.sum;
}
/**/
Destroyed!
Destroyed!
Note that the compiler didn't realize that p isn't needed after
the last statement of main, as you thought.
/**/
XY get()
{
XY p;
return p;
}
void main()
{
get.sum;
}
/**/
Destroyed!
Now with an rvalue returned from get, interesting, no copy.
Still, I wonder what really happened. Again, moving between
stacks would still be work. And a different optimization can
explain this non copy, for example inlining.
__
Again, does the spec really mention any of this moving or
eliding? I have found nothing.
Re: DIP 1016 and const ref parameters
On Wednesday, 19 June 2019 at 19:25:59 UTC, Jonathan M Davis wrote: On Wednesday, June 19, 2019 12:28:12 PM MDT XavierAP via Digitalmars-d-learn wrote: [...] The DIPs are here: https://github.com/dlang/DIPs [...] DIP1014 has not been implemented in DMD or druntime yet, AFAIK
Re: DIP 1016 and const ref parameters
On Wednesday, June 19, 2019 12:28:12 PM MDT XavierAP via Digitalmars-d-learn
wrote:
> On Wednesday, 19 June 2019 at 12:55:09 UTC, Jonathan M Davis
>
> wrote:
> > Even in C++, using const ref is not as good a practice as it
> > once was, because they added move constructors, finally making
> > object moveable. The result is that in many cases, it's
> > actually more efficient to just copy values in C++ rather than
> > use const &, but which is better does depend on the code.
> >
> > As for D, unless you're dealing with large objects, odds are
> > that worrying about passing by value is pointless. D classes
> > are reference types, and D structs have move semantics
> > built-in. So, you don't get as many copies as you would in
> > C++98, and the situation is probably better than newer versions
> > of C++, since IIRC, C++ classes aren't moveable by default,
> > whereas D structs are. In general, you're probably better off
> > just passing by value unless you find that a particular piece
> > of code is inefficient when benchmarking. Either way, you don't
> > want to be slapping const on everything the way you would in
> > C++, because D's const is far more restrictive. So, while it
> > still can be quite useful, odds are that if you start using it
> > heavily, you're going to run into problems fast - especially
> > since casting away const and mutating an object is undefined
> > behavior in D. D's const has no back doors. If something is
> > const, then you can't mutate it unless you also have a mutable
> > reference to the same data. And because const is transitive,
> > you pretty much can't get mutable stuff from const stuff like
> > you frequently can in C++ (e.g. in C++, it's possible to have a
> > const container of mutable objects, wherein D, once part of
> > something is const, everything within that part is const).
> >
> > As for the DIP, I'd suggest watching Andrei's recent dconf talk
> > on the subject:
> >
> > https://www.youtube.com/watch?v=aRvu2JGGn6E=youtu.be
> >
> > - Jonathan M Davis
>
> I am not talking about cases that would be candidate for moving,
> or where const would be any problem. If you want an example for
> the sake of argument:
>
> struct Matrix3D
> {
> Matrix3D opBinary(string op)(const ref Matrix3D rhs) const;
> }
> unittest
> {
> auto a = Matrix3D.random;
> assert(a == a * Matrix3D.identity);
> assert(a == a + Matrix3D.zeros);
> }
>
> I did watch Andrei's talk, actually this is where I started and
> learned about the DIP(s), then I was confused that 1016 had been
> rejected, and smelling that it may be "reopening" I was not sure
> where I can find the "index" of DIPs under discussion or
> whatever... :)
The DIPs are here: https://github.com/dlang/DIPs
Aside from looking through the newsgroup/forum for discussions on DIPs,
that's pretty much all you're going to find on that. Andrei's talk is the
most up-to-date information that we have about this particular DIP.
> > IIRC, C++ classes aren't moveable by default, whereas D structs
> > are.
>
> What do you mean that structs are movable? I know about RVO (in
> both D and C++, supposedly guaranteed by all compilers in
> practice, but not by language spec -- why not D?), but what about
> passing up the stack as here?
I mean that the object is moved from one place in memory to another rather
than copied. There are cases where the compiler needs to take an object and
put it somewhere else. RVO may be one of those, though if I understand
correctly with RVO, it may just place the return value outside of the
function in the first place to avoid needing to move. But regardless of
whether RVO causes a move, there are cases where the compiler can move an
object rather than copying it. A very simple case of where a move could
theoretically happen (though I'm not sure how much this happens in practice)
would be with code like
void foo()
{
MyStruct m;
bar(m);
}
void bar(MyStruct m)
{
...
}
bar takes its argument by value. So, it can't take a reference to avoid a
copy. However, because when bar is called, it's the last time that m is used
inside of foo, rather than copying m to where bar would use it as a
parameter, the compiler could choose to move the object to where bar expects
its parameter to be rather than copying it - so it could just blit the bits
over. In some cases, it may be able to just place m in the right place that
bar will get it without it being copied, but with more complicated code,
that's not possible. A far more likely case where objects would be moved is
with temporaries. e.g. with this code
func(foo(), bar(42), baz("hello"));
assuming that none of these functions return by ref, func is taking
temporaries from several functions, and the spec actually guarantees that
they will not be copied. So, if the compiler needs to move them to put them
in the right place for func to get them as parameters, it will.
In C++98, it really isn't legal for the compiler to move objects. This is
because it's legal to
Re: Is it possible to escape a reserved keyword in Import/module?
On Wednesday, June 19, 2019 12:56:57 PM MDT BoQsc via Digitalmars-d-learn wrote: > I would like to make sure that my modules do not interfere with d > lang. Is there any way to escape reserved words? > https://dlang.org/spec/lex.html#keywords > > > import alias; > > C:\Users\Juozas\Desktop\om.d(2): Error: identifier expected > following import > C:\Users\Juozas\Desktop\om.d(2): Error: ; expected > > > module abstract; > > C:\Users\Juozas\Desktop\commands\alias.d(1): Error: identifier > expected following module You can never use keywords as identifiers in D (or any language in the C family that I've ever heard of). So, you can't ever declare symbols with names like alias or abstract. The way that the official D style guide tackles the problem is to say that any case where a keyword would be needed should append _ to the keyword to make it a legal identifier. https://dlang.org/dstyle.html#naming_keywords So, that's the way that it's handled in the standard library or any other code which follows the D style guide. e.g. The enum std.traits.FunctionAttribute has members such as pure_, nothrow_, and const_, since it can't use the actual keywords. - Jonathan M Davis
Is it possible to escape a reserved keyword in Import/module?
I would like to make sure that my modules do not interfere with d lang. Is there any way to escape reserved words? https://dlang.org/spec/lex.html#keywords import alias; C:\Users\Juozas\Desktop\om.d(2): Error: identifier expected following import C:\Users\Juozas\Desktop\om.d(2): Error: ; expected module abstract; C:\Users\Juozas\Desktop\commands\alias.d(1): Error: identifier expected following module
Re: DIP 1016 and const ref parameters
On Wednesday, 19 June 2019 at 12:55:09 UTC, Jonathan M Davis
wrote:
Even in C++, using const ref is not as good a practice as it
once was, because they added move constructors, finally making
object moveable. The result is that in many cases, it's
actually more efficient to just copy values in C++ rather than
use const &, but which is better does depend on the code.
As for D, unless you're dealing with large objects, odds are
that worrying about passing by value is pointless. D classes
are reference types, and D structs have move semantics
built-in. So, you don't get as many copies as you would in
C++98, and the situation is probably better than newer versions
of C++, since IIRC, C++ classes aren't moveable by default,
whereas D structs are. In general, you're probably better off
just passing by value unless you find that a particular piece
of code is inefficient when benchmarking. Either way, you don't
want to be slapping const on everything the way you would in
C++, because D's const is far more restrictive. So, while it
still can be quite useful, odds are that if you start using it
heavily, you're going to run into problems fast - especially
since casting away const and mutating an object is undefined
behavior in D. D's const has no back doors. If something is
const, then you can't mutate it unless you also have a mutable
reference to the same data. And because const is transitive,
you pretty much can't get mutable stuff from const stuff like
you frequently can in C++ (e.g. in C++, it's possible to have a
const container of mutable objects, wherein D, once part of
something is const, everything within that part is const).
As for the DIP, I'd suggest watching Andrei's recent dconf talk
on the subject:
https://www.youtube.com/watch?v=aRvu2JGGn6E=youtu.be
- Jonathan M Davis
I am not talking about cases that would be candidate for moving,
or where const would be any problem. If you want an example for
the sake of argument:
struct Matrix3D
{
Matrix3D opBinary(string op)(const ref Matrix3D rhs) const;
}
unittest
{
auto a = Matrix3D.random;
assert(a == a * Matrix3D.identity);
assert(a == a + Matrix3D.zeros);
}
I did watch Andrei's talk, actually this is where I started and
learned about the DIP(s), then I was confused that 1016 had been
rejected, and smelling that it may be "reopening" I was not sure
where I can find the "index" of DIPs under discussion or
whatever... :)
IIRC, C++ classes aren't moveable by default, whereas D structs
are.
What do you mean that structs are movable? I know about RVO (in
both D and C++, supposedly guaranteed by all compilers in
practice, but not by language spec -- why not D?), but what about
passing up the stack as here?
Re: What is the difference between extern(C++) extern(D)
On Wednesday, June 19, 2019 11:12:14 AM MDT lili via Digitalmars-d-learn wrote: > Hi Guys; > In the dmd source code, has lot of extern (C++), Why need this > and what is difference between extern(C++) extern(D), Thanks your > answer. extern(C++) is for making the name mangling match C++, extern(C) would be the same for C (though in that case, it would mean no name mangling), and extern(D) is the same as not using extern at all; it's for the normal D name mangling. extern(C) and extern(C++) are either exposing symbols from D to those languages (e.g. if you're creating a library) or for exposing symbols from those languages to D (e.g. that's what core.stdc.* does with C's standard library so that it can be used from D). https://dlang.org/spec/interfaceToC.html https://dlang.org/spec/cpp_interface.html - Jonathan M Davis
Re: Strange behavior of opEquals for structs
On Wednesday, 19 June 2019 at 17:15:31 UTC, Ali Çehreli wrote: On 06/19/2019 08:28 AM, harfel wrote: You need to define toHash() member function as well: https://dlang.org/spec/hash-map.html#using_struct_as_key Ali Thanks Ali, This fixed my problem, of course. Amazing that such a beginner's mistake still receives attention by one of the gurus :-) harfel
Re: The problem with the conversion.
On Wednesday, 19 June 2019 at 14:58:44 UTC, drug wrote:
19.06.2019 17:52, Den_d_y пишет:
void load (const (char *) path)
{
SDL_Surface ab = SDL_LoadBMP (path);
a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}
try the following:
```
void load (string path)
{
import std.string : toStringz;
SDL_Surface ab = SDL_LoadBMP (path.toStringz); // toStringz
converts string to null terminated char*
auto a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}
Also, the return type of SDL_LoadBMP is a pointer, SDL_Surface*
not just SDL_Surface.
Indeed, in your code do use the D string path, not char*, and use
toStringz when passing to C APIs.
Also, in D const(char)* would not be the same as const(char*).
But don't worry about this and use string.
Re: Strange behavior of opEquals for structs
On 06/19/2019 08:28 AM, harfel wrote: Everything works nicely if I compare the structs directly. Yet when they are used as keys in an associative array, the code throws an exception that I do not understand. You need to define toHash() member function as well: https://dlang.org/spec/hash-map.html#using_struct_as_key Ali
What is the difference between extern(C++) extern(D)
Hi Guys; In the dmd source code, has lot of extern (C++), Why need this and what is difference between extern(C++) extern(D), Thanks your answer.
Re: Where can find fix length array memory layout document
On Wednesday, 19 June 2019 at 12:53:05 UTC, Cym13 wrote:
Did you import it properly?
```
void main() {
import core.stdcpp.array;
auto a = array!(int, 4)();
}
```
compiles and runs without issue for me. You'll have to show
your code if you want people to help you there.
Ok, where has some mistake in my code. thanks.
Strange behavior of opEquals for structs
I am trying to overload opEquals for a struct. The struct will
hold class objects that define their own opEquals so the default
bitwise comparison is not good for me.
Everything works nicely if I compare the structs directly. Yet
when they are used as keys in an associative array, the code
throws an exception that I do not understand.
My minimal code example is this:
debug import std.stdio;
struct Foo(T) {
int[T] content;
bool opEquals(const(Foo!T) that) {
debug writeln("opEquals called");
return true;
}
alias content this;
}
class Bar { }
void main()
{
Foo!Bar a = Foo!Bar();
Foo!Bar b = Foo!Bar();
assert(a == b);
debug writeln("This works");
Foo!Bar[int] x = [1: Foo!Bar()];
x[1][new Bar] = 1;
Foo!Bar[int] y = [1: Foo!Bar()];
y[1][new Bar] = 1;
assert(x == y);
debug writeln("This does not work");
}
Here is what I get (using DMD64 D Compiler v2.086.0):
opEquals called
This works
object.Error@(0): TypeInfo.equals is not implemented
??:? bool object._xopEquals(const(void*), const(void*)) [0x49e844]
??:? const pure nothrow @trusted bool
object.TypeInfo_Struct.equals(const(void*), const(void*))
[0x49dcdb]
??:? _aaEqual [0x4a850b]
source/app.d:29 _Dmain [0x46c52f]
Program exited with code 1
Strange thing is that everything works nicely (but produces the
expected AssertionError) if I comment out Foo.opEquals. What is
the error message telling me and how can I fix it?
Thanks!!
Re: The problem with the conversion.
19.06.2019 17:52, Den_d_y пишет:
void load (const (char *) path)
{
SDL_Surface ab = SDL_LoadBMP (path);
a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}
try the following:
```
void load (string path)
{
import std.string : toStringz;
SDL_Surface ab = SDL_LoadBMP (path.toStringz); // toStringz
converts string to null terminated char*
auto a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}
```
The problem with the conversion.
Hello, users of this programming language! I have a question. I
use in my application Derelict SDL 2 version 2.1.4.
And when I try to specify the path to the image:
void load (const (char *) path)
{
SDL_Surface ab = SDL_LoadBMP (path);
a = SDL_CreateTextureFromSurface (ab);
SDL_FreeSurface (ab);
}
An error occurs:
"function derelict.sdl2.functions.SDL_LoadBMP (const (char) *
file) is not callable using argument types (string)".
Well, okay, I use in arguments: const (char *) path. Annoyed, the
program still writes this error. Please help with this problem.
P.S. If you see errors in spelling and stuff, then note: I am a
Russian user.
P.P.S. I am not familiar with this programming language.
Re: DIP 1016 and const ref parameters
On Wednesday, June 19, 2019 6:33:44 AM MDT XavierAP via Digitalmars-d-learn wrote: > I often use a pattern of having const ref struct parameters (as > in C++) but this doesn't work in the case of rvalues. The > workaround of defining an overload that calls its own name is > terrible. I understand there was a DIP 1016 by Manu asking for > this case to work. As far as I can tell, this was rejected, but > later reconsidered, and now Andrei is starting up a new one[1]? > Apologies but I'm not sure where these discussions are > centralized. But if anyone has any idea or guess how seriously > and in what kind of time this could be expected, that would be my > first side question. > > My main learning question is whether the const ref parameter > pattern is good in D? In C++ I see it everywhere, but are there > better alternatives, in particular in D, or is there no point > because some copy elision optimization may be guaranteed? In > short am I right in writing const ref parameters, or am I doing > something silly (and as important as this DIP may otherwise be, > it wouldn't affect me as much as I think)?? > > As far as I can see, this DIP would be helpful for two use cases: > const ref, and return ref with method chains. Are there others? > __ > [1] > https://forum.dlang.org/post/d90a7424-a986-66f1-e889-a9abd55e0e65@erdani.o > rg Even in C++, using const ref is not as good a practice as it once was, because they added move constructors, finally making object moveable. The result is that in many cases, it's actually more efficient to just copy values in C++ rather than use const &, but which is better does depend on the code. As for D, unless you're dealing with large objects, odds are that worrying about passing by value is pointless. D classes are reference types, and D structs have move semantics built-in. So, you don't get as many copies as you would in C++98, and the situation is probably better than newer versions of C++, since IIRC, C++ classes aren't moveable by default, whereas D structs are. In general, you're probably better off just passing by value unless you find that a particular piece of code is inefficient when benchmarking. Either way, you don't want to be slapping const on everything the way you would in C++, because D's const is far more restrictive. So, while it still can be quite useful, odds are that if you start using it heavily, you're going to run into problems fast - especially since casting away const and mutating an object is undefined behavior in D. D's const has no back doors. If something is const, then you can't mutate it unless you also have a mutable reference to the same data. And because const is transitive, you pretty much can't get mutable stuff from const stuff like you frequently can in C++ (e.g. in C++, it's possible to have a const container of mutable objects, wherein D, once part of something is const, everything within that part is const). As for the DIP, I'd suggest watching Andrei's recent dconf talk on the subject: https://www.youtube.com/watch?v=aRvu2JGGn6E=youtu.be - Jonathan M Davis
Re: Where can find fix length array memory layout document
On Wednesday, 19 June 2019 at 05:27:12 UTC, lili wrote:
On Tuesday, 18 June 2019 at 17:29:49 UTC, Cym13 wrote:
On Tuesday, 18 June 2019 at 17:25:42 UTC, Cym13 wrote:
On Tuesday, 18 June 2019 at 13:05:03 UTC, lili wrote:
On Tuesday, 18 June 2019 at 12:39:45 UTC, Dennis wrote:
[...]
Thanks a lot, where is a core.stdcpp.array , How to user it?
I test but get a error
```
auto aa = array!(int, 4); //error
```
Please don't shorten your code or errors to the point where
there's hardly any information left: it's hard to help you if
we can't know what you did and what went wrong.
Forgot to say that it's probably because you don't actually
build an array here, try adding parentheses:
```
auto aa = array!(int, 4)();
```
array!(int,4)(); compile occurs a error say: no overload
matches for array
Did you import it properly?
```
void main() {
import core.stdcpp.array;
auto a = array!(int, 4)();
}
```
compiles and runs without issue for me. You'll have to show your
code if you want people to help you there.
DIP 1016 and const ref parameters
I often use a pattern of having const ref struct parameters (as in C++) but this doesn't work in the case of rvalues. The workaround of defining an overload that calls its own name is terrible. I understand there was a DIP 1016 by Manu asking for this case to work. As far as I can tell, this was rejected, but later reconsidered, and now Andrei is starting up a new one[1]? Apologies but I'm not sure where these discussions are centralized. But if anyone has any idea or guess how seriously and in what kind of time this could be expected, that would be my first side question. My main learning question is whether the const ref parameter pattern is good in D? In C++ I see it everywhere, but are there better alternatives, in particular in D, or is there no point because some copy elision optimization may be guaranteed? In short am I right in writing const ref parameters, or am I doing something silly (and as important as this DIP may otherwise be, it wouldn't affect me as much as I think)?? As far as I can see, this DIP would be helpful for two use cases: const ref, and return ref with method chains. Are there others? __ [1] https://forum.dlang.org/post/d90a7424-a986-66f1-e889-a9abd55e0...@erdani.org
Re: Blog Post #0045 - Split a Window into Panes
On Tuesday, 18 June 2019 at 13:19:48 UTC, Ron Tarrant wrote: And just a quick tip of the hat Forgot to thank Russell Winder for suggesting Previous/Next buttons which have also been implemented on all pages. Should make navigation easier for those multi-part posts.
Re: is there any micro-service library in D?
On Wednesday, 19 June 2019 at 08:29:15 UTC, dangbinghoo wrote: hi there, Does anyone know the micro-service oriented design library or framework in D? thanks! binghoo dang What do you need from such a library? Some suggestions: For networking, there is vibe.d[0] which provides both a client and a server REST (or web) interface. There is also GraphQL-D[1] that provides a server-side GraphQL interface that can be used by other services. For modelling, there is Depend[2], which visualises dependencies. [0] http://code.dlang.org/packages/vibe-d [1] http://code.dlang.org/packages/graphqld [2] http://code.dlang.org/packages/depend
Re: Component based programming in D
On Tuesday, 18 June 2019 at 09:17:09 UTC, Bart wrote: I'm new to component based programming. I've read it is an alternative to oop for speed. Component based modelling is part of the OO-modelling toolbox. Also, it isn't new, e.g. database-oriented modelling techniques often use the same philosophy (e.g. SA-modelling and ER-modelling predates object-oriented-modelling). It isn't about speed, it is about being able to combine independently written frameworks (or components) using an id as an identifier for an entity. It also helps when your implementation spans over many computers (or services). So basically, if you have an independently written hotel-reservation component, a golf-course component, a flight ticket component and so on, then you can compose this to a full "vacation system" by combining the various components. Nothing new about this, but it got traction around 15-25 years ago as software got expensive to build from scratch (as programs grew larger) and you want to develop a framework of prewritten components that can be combined for easier and cheaper production. So in that respect you probably, in most cases, trade performance (slower) for easy reuse and easier debugging (in some cases). In the game community they claim to do it for performance reasons, but that is probably not the case, it is again about costs of doing multithreaded programming and splitting the codebase into specialized chunks that different teams can work on for good performance on individual parts. So yeah, the claim is "speed", but there is no real substance to that claim, in the general case. Speed isn't a result of the generic modelling-strategy. But in some scenarios it might be easier to partition the design into components and make each component perform well than doing it as a monolithic design. Although in theory the monolithic design should always perform better if done in an optimal fashion. The problem is that it is too expensive to do an optimal monolithic multi-threaded design well (and change becomes difficult). E.g. the most high performing OS-kernels are monolithic for performance reasons. However, the development costs of that approach are prohibitive for ordinary software (even games). Can someone help me understand this a little better and how I'd go about using it in D? Specifically I'm looking at the pros and cons, what are the real similarities and differences to oop, and how one implements them in D(taking in to account D's capabilities). It has precious little to do with the programming language. It has more to do with modelling. So you probably will learn more from looking at component based modelling as a tool in your OO-modelling toolbox than following a particular implementation of a component based design. Unless you want to write games, in which case you should look in that direction. (e.g. reuse an existing physics component). Ola.
Re: Hyperterminal serial port
On Wednesday, 19 June 2019 at 06:52:33 UTC, IanFisher wrote: Hi, I am wanting to establish a virtual serial port connection between an 89c51 being emulated in Proteus and Hyper Terminal running in Windows. How do I go about doing this? Thanks in advance Hello. Look at the reply above instead. The solution is there ! You need to replace Virtual Terminal with COMPIM (virtual COM interface). You must have 2 COMs free in your PC and a null modem cable (crossed). Say you have COM1 and COM2 free. Connect the null modem between the two ports as a link and set COMPIM as the port COM1. Then use Windows Terminal (or whichever program you like) and set it as COM2. You'll see that any outputs that before were sent to the Virtual Terminal are now sent to Windows Terminal (or any other you may use). Alternatively, if you don't have 2 physical COMs free then you may use some software driver, like Virtual Serial Ports Driver from https://www.serial-splitter.com/
is there any micro-service library in D?
hi there, Does anyone know the micro-service oriented design library or framework in D? thanks! binghoo dang
Hyperterminal serial port
Hi, I am wanting to establish a virtual serial port connection between an 89c51 being emulated in Proteus and Hyper Terminal running in Windows. How do I go about doing this? Thanks in advance
Re: Why after writeln the binaryHeap become empty?
On Wednesday, 19 June 2019 at 06:00:28 UTC, Jonathan M Davis wrote: On Tuesday, June 18, 2019 10:27:46 PM MDT lili via Do you known reason for why Dlang Range are consumed by iterating over them. I this design is strange. If you want an overview of ranges, you can watch this: https://www.youtube.com/watch?v=A8Btr8TPJ8c You can also read this: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis And this excerpt from Learning D: https://hub.packtpub.com/understanding-ranges/
Re: Why after writeln the binaryHeap become empty?
On Tuesday, June 18, 2019 10:27:46 PM MDT lili via Digitalmars-d-learn wrote: > On Tuesday, 18 June 2019 at 17:25:51 UTC, Johannes Loher wrote: > > The result of heapify is a BinaryHeap, which is a range. writeln > > basically prints ranges by iterating over them and printing > > each element > > (except for the types which are special cased, such as dynamic > > arrays > > etc.). However, ranges are consumed by iterating over them, > > which > > explains the behavior because writeln is not special cased for > > BinaryHeaps. > > > > Funnily enough, BinaryHeap does not implement a "save" method, > > which is the usual way of making ranges copiable, i.e. making > > them ForwardRanges. In this case I believe save could even > > simply be an alias to dup. > > Do you known reason for why Dlang Range are consumed by iterating > over them. I this design is strange. If you want an overview of ranges, you can watch this: https://www.youtube.com/watch?v=A8Btr8TPJ8c You can also read this: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis
