*References cannot be null, whereas pointers can; every
reference refers to some object, although it may or may not be
valid. Note that for this reason, containers of references are
not allowed.
* References cannot be uninitialized. Because it is impossible
to reinitialize a reference, they m
I had totally forgotten what it says in "The book" about struct
and class construction. It's basically that all fields are
first initialized to either T.init or by using the field's
initializer. That means the use of ref inside class or struct
would be quite restricted:
int globalVal;
stru
On Thursday, 30 August 2012 at 07:35:34 UTC, Namespace wrote:
I had totally forgotten what it says in "The book" about
struct and class construction. It's basically that all fields
are first initialized to either T.init or by using the field's
initializer. That means t
On Thursday, 30 August 2012 at 08:57:24 UTC, Tommi wrote:
On Thursday, 30 August 2012 at 07:35:34 UTC, Namespace wrote:
struct MyStruct
{
// ref int defaultInitRef; // Illegal: reference variables
// can't be default initialized
But you can handle it
In D:
class A { // or struct
A(ref int host) : _host(&host) { }
private:
int* _host;
}
Since when do we have initialization lists in D? ;)
at topic: +1
That is the one thing I miss also.
The solution until now is to use a wrapper struct around a class,
but that is _very_ annoying and a good language should have
something on their own.
But it is right, for D2 this mistake is going to long as you can
change it so soon.
But maybe a Syntax like
On Monday, 17 September 2012 at 00:22:52 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2012 00:43:50 deadalnix wrote:
It shouldn't be that hard to create a Nullable!T template.
We have one, and it would be wasteful to use that for
references or pointers
when they're naturally nullable
On Saturday, 10 November 2012 at 12:51:15 UTC, bearophile wrote:
Sönke Ludwig:
It fits perfectly with what's already there, it's proven to be
sound and
practical, and IMO it's definitely what should be implemented
in D.
Seems fit to be added to Remus then :-)
Bye,
bearophile
Gladly, if yo
If nothing else, it doesn't work for classes, because templated
functions
can't be virtual. Also, it forces you to put the entire
function's
implementation in a .di file if you use .di files, which makes
it untentable for
many of the folks who actually need to use .di files.
We need a solution
What does this generate?
auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
d) { ... }
16 different functions, one for each combination? Sounds like a
bad idea.
In my opinion, this should produce only two functions:
#1: auto foo(ref S a, ref S b, ref S c, ref S d) { ... }
#2: aut
Yes, that does work and is easy to implement.
Andrei
And why isnt it in 2.061? ;)
You could use 'auto ref'. It isn't offical implemented, but I use
it already.
See also this thread:
http://forum.dlang.org/thread/tkzyjhshbqjqxwzpp...@forum.dlang.org?page=7
No response probably means "you get no official statement"? ;)
and on that note I hear the C++ community (at least one key
member) is proposing a:
auto add(auto a, auto b) {
return a + b;
}
pretty-template syntax! I wouldn't feel right if C++ had
something that elegant and D did not *wink* *wink* :-)
Could you explain why this is necessa
On Thursday, 24 January 2013 at 09:03:45 UTC, anonymous wrote:
On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright
wrote:
This has turned into a monster. We've taken 2 or 3 wrong turns
somewhere.
Perhaps we should revert to a simple set of rules.
[...]
4. No more @property.
You wen
On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
Hi,
I would really like to start using D in our small company as a
C++ replacement. With that in mind I do have few questions:
1) Is D2 really ready for production code?
Not really. A big pain in the ass is the missing rvalue ref that
On Friday, 25 January 2013 at 21:50:22 UTC, Timon Gehr wrote:
On 01/25/2013 10:39 PM, Namespace wrote:
On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
Hi,
I would really like to start using D in our small company as a
C++ replacement. With that in mind I do have few questions:
1
Yes, the ref issue can be a pain, but it's not even close to a
show stopper for production use. C++ has by far worse
limitations, such as an almost unusable template
implementation, and that's just the start of it.
I agree. However, there remains the fact that the lack of an
rvalue ref hurts.
On Friday, 25 January 2013 at 22:16:11 UTC, Szymon wrote:
In C++ rv-refs do not help with structs (PODs). Do you mean D
has no refs / pointers for struct passing?
I meant that we have nothing comparable with const&.
const& int C++ accept both, lvalues and rvalues. If it is an
lvalue it is take
And yes, I meant of course D structs and that D has nothing to
receive these as rvalue _and_ rvalue. Sorry for confusing you.
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
So structs in D are always passed by-value? That is
unfortunate...
On Friday, 25 January 2013 at 22:20:32 UTC, Namespace wrote:
On Friday, 25 January 2013 at 22:16:11 UTC, Szymon wrote:
In C++ rv-refs do not help with structs (PODs
On Friday, 25 January 2013 at 22:30:46 UTC, Adam D. Ruppe wrote:
LOL 3 of us said the same thing at the same time!
And everytime the example was more detailed. :)
On Friday, 25 January 2013 at 23:16:09 UTC, Andrei Alexandrescu
wrote:
On 1/25/13 4:39 PM, Namespace wrote:
On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
Hi,
I would really like to start using D in our small company as a
C++ replacement. With that in mind I do have few questions
structs are now lvalues => structs are now rvalues.
We better get this right and not hurry about this.
I will open a new, separate thread about this tomorrow. Seems to
me more appropriate. Then we can discuss about this important but
missing feature in detail.
What languages have that feature, and what makes it important?
To me it seems rath
On Saturday, 26 January 2013 at 02:51:41 UTC, Namespace wrote:
We better get this right and not hurry about this.
I will open a new, separate thread about this tomorrow. Seems
to me more appropriate. Then we can discuss about this
important but missing feature in detail.
http
Yes. We are actively looking into a complete solution. Along
the way we also very strongly want to define semantics of "ref"
in such a way that makes unsafe escapes impossible. These two
features are related.
Andrei
That's good to know. But can you estimate _when_ it will be
implemented or
On Saturday, 26 January 2013 at 17:02:40 UTC, deadalnix wrote:
On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei
Alexandrescu wrote:
On 1/26/13 6:03 AM, Namespace wrote:
In relation to this post:
http://forum.dlang.org/thread/ssiulznvtkmfkimma...@forum.dlang.org?page=5#post
On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
wrote:
On Saturday, January 26, 2013 17:51:23 Namespace wrote:
That's good to know. But can you estimate _when_ it will be
implemented or with which version? That would be very
informative.
Things generally just don't
If we add a feature as a temporary measure and then remove it
later, we're
likely to end up breaking code when it's removed.
No, as far as I can see this don't happend. auto ref works
currently very well for template functions and the pull I suggest
adds the same functionality for normal functi
But it may not even end up being the case that using auto ref
on non-templated
functions is the solution. It may end up being something else
entirely.
Ignoring @safety issues, it seems to me like it would be the
most
straightforward solution, but there are @safety issues with ref
in general
tha
I didn't know. I thought auto ref would be the only solutions for
non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and without
ref. Thank you.
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background knowledge I will write my code twice, with and
without ref. Than
All of your topics shouldn't be here. Post in D.learn instead.
On Monday, 28 January 2013 at 15:15:38 UTC, Dejan Lekic wrote:
On Friday, 25 January 2013 at 21:39:58 UTC, Namespace wrote:
On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
Hi,
I would really like to start using D in our small company as a
C++ replacement. With that in mind I do have
On Sunday, 27 January 2013 at 14:54:26 UTC, Namespace wrote:
On Sunday, 27 January 2013 at 10:35:34 UTC, Namespace wrote:
I didn't know. I thought auto ref would be the only solutions
for non-template functions.
But then I think we must wait for 2 or 3 versions. With this
background know
And before I forget, can I also suggest a syntax?
I would love 'ref&'. ;) It's pretty short and smart.
3. Nitpick: Don't use parenthesis for single arg templates:
No: "Deque!(int)"
yes: "Deque!int"
May I ask why? Both are correct after all. Or is it just the
preferred style?
My style is also Deque!(int), not Deque!int, the latter looks
ugly...
On Wednesday, 30 January 2013 at 11:10:17 UTC, bearophile wrote:
Currently you are allowed to write a lambda literal as in line
3, but you can't omit "ref" as in line 4:
void foo(int delegate(ref int[1]) spam) {}
void main() {
foo((ref x) => 0); // line3, OK
foo(x => 0); // line4, Erro
Please post next time in D.learn.
In D it is still like in other C like languages:
class A {
public:
this() { writeln("A CTor"); }
}
A a = new A(); create a new object of type A and print "A CTor"
Because D has no standard copy CTor for classes, you must declare
your own:
class A {
public
On Wednesday, 30 January 2013 at 17:26:13 UTC, Jonathan M Davis
wrote:
On Wednesday, January 30, 2013 12:51:22 Paulo Pinto wrote:
I prefer the Pascal family way where they are implicit, but
lets
have what the majority prefers.
We've had this discussion at length before. It should stay
implic
What change? My point was that it's _not_ changing. Function
parameters can be
marked with ref, but the call site doesn't use ref, and it
isn't going to
start using ref.
- Jonathan M Davis
My fault. I thought that the optional call site ref/out whatever
might be implemented in the future. Th
On Thursday, 31 January 2013 at 10:58:48 UTC, Peter Alexander
wrote:
On Thursday, 31 January 2013 at 08:42:48 UTC, Roumen Roupski
wrote:
finally
{
delete m1;
delete m2;
}
D has a GC. No need for manual deletion.
(In fact, I think this is
On Thursday, 31 January 2013 at 12:28:43 UTC, FG wrote:
On 2013-01-31 12:38, Namespace wrote:
If you want to do something, then take destroy.
AFAIK delete destroy _and_ release the memory immediately.
'destroy' doesn't.
And that's why delete is valuable (at lea
The next beta is on the way and that will be the fourth (or
fifth?) version, since the first discussions (I've found) about
rvalue refs.
So if you have any plans to deal with this, it would be nice if
you tell it us.
It would also be good to know, if your ideas goes towards auto
ref, means func
I would suggest that it should work this way, and that maybe
this should be part of the new process focus.
This isn't intended to be demanding -- it could be fairly
simple to provide SOME guide to timeframes. For example, with
redmine, you can attach issues to milestones/releases, and give
a
But what if we want to pass a struct with intent as value?
With this solution, we don't have much control.
In general, I like the idea, but we should mark such parameter
with '&' or whatever, so at least we can still take some
influence.
On Monday, 11 February 2013 at 10:53:40 UTC, deadalnix wrote:
On Monday, 11 February 2013 at 10:04:55 UTC, Namespace wrote:
But what if we want to pass a struct with intent as value?
With this solution, we don't have much control.
In general, I like the idea, but we should mark such para
A good rule of thumb to know when to pass by ref for perf is :
- The struct is big, or contains mixed entities (floats and
ints). 2*size_t seems like a good heuristic from my experience.
- The struct have a postblit.
The compiler doing it is superior to the user marking
everything :
- The
I'm not sure creating two versions of each function will fly
well with Walter. Actually, you say *two* are needed, but
that's for a function with one struct parameter; it's more
2^(number of structs parameters) versions you'd need in the
general case.
That's how 'auto ref' currently works. Bu
Compiler now inline even when inline isn't present, and don't
inline when inline is present [...]
That's what I said.
In other terms, inline is the perfect example of why defining
stuff like that explicitly make no sense.
That was no criticism.
I like to explicitly mark such things, but whate
I'm a bit confused now. It's your intention to create (worst
case) 2^n permutations of the same function for each potential
ref parameter (which would be the same behaviour as 'auto ref')
or that the compiler could pass big structs by ref without code
bloat?
How about this approach:
You almost need functions, which takes structs as an rvalue, for
things like:
struct A { }
void foo(A a) { }
foo(A());
So what's about something like this (Yes I mark it with '&'):
struct A { }
void foo(A& a) { }
The compiler decides at compile time
Read my approach. I suggest something like A& a. It's short and
known from C++.
Only in my approach, I suggest a link between the proposal of
deadalnix (compiler optimizations) and generally rvalue
references.
'const ref' will never work the way as we know it from C++.
Walter and Andrei and man
Don't get me wrong, I also hope that this unfortunate and lengthy
discussion ends. And I also like the idea that const ref works as
in C++.
But I'm sure you can convince neither Walter nor Andrei still the
core developer team.
And I don't quite understand what speaks against my suggestion.
If
On Tuesday, 12 February 2013 at 15:57:42 UTC, kinke wrote:
For all other cases, I think we sadly need to resort to
a revisited 'auto ref' approach.
I.e., something like this:
https://github.com/D-Programming-Language/dmd/pull/1019
http://forum.dlang.org/thread/nirfuenixutsbgyrc...@forum.dlang
2) Kenji's 'auto ref' proposal getting pulled in the near
future so that we can manually prevent argument copying for the
remaining unsafe lvalue cases.
Maybe in 2065 - if we're lucky. ;)
Read also in my thread that I had posted earlier: auto ref -
again.
There are also one of the rare respon
Maybe in 2065 - if we're lucky. ;)
I meant of course dmd version 2.065, not the year 2065. ;)
On Tuesday, 12 February 2013 at 23:49:04 UTC, Martin Nowak wrote:
On 02/13/2013 12:34 AM, Martin Nowak wrote:
You can easily create a function that turns values into
rvalues if it's
opportune.
Actually there is also a nice template based implementation of
this in phobos (std.algorithm.forwar
Yes your additions is included in what I meant by "stabilize".
We need to freeze the addition of new features for the "stable
release of the language" (we currently do not have a stable
release that is documented) and put it through the acid test of
real world use so it can be polished up based
On Tuesday, 26 February 2013 at 15:43:42 UTC, dennis luehring
wrote:
Am 26.02.2013 16:26, schrieb Craig Dillabaugh:
I am a novice D programmer and use C++ in my work. One thing I
find myself doing when I need to implement some non-trivial
algorithm is that I will originally code it in D and perf
I'm surprised to see many people doing this. But I'm wondering..
If you already got the code working in D, why not let it stay
there and write a C interface?
Company policy? Missing dynamic loading? Some build issues?
If the code could stay in D, it would seem like a good way to
slowly integra
Currently small structs are moved as rvalues and copied as
lvalues and that seems like the most performant way.
But for massy structs this doesn't make sense, if you must pass
them to functions as parameter, without declaring the parameter
as 'ref'.
Why? Because in general this is very unperform
Size is next polymorphism my main reason why I would use a class
instead of a struct.
A good heuristic size (which I have heard here) was: <= 16 bytes
-> struct, > 16 bytes -> class.
And what are your reasons for decision?
And I believe, actually, that passing a massive struct by value
if it's
I know about 'auto ref'. Nice try but ... ;)
Need fine control over lifetime?
scope and scoped give you the possibility to put a class instance
on the stack so you have also controll over the instance lifetime.
-> No reason for struct.
Interfaces, well, but I'm sure you can live without them
Nice try? I don't get this. It was supposed to be the
analogue to C++ rvalue references, Walter did not implement it
as Andrei expected (AIUI). He made it a (admittedly useful)
template feature.
I got the answer that 'auto ref' is not the solution which will
solve the const& issue and beca
Era Scarecrow:
Did I understand right that your answer is 'No, we don't need
something like const&'?
On Saturday, 2 March 2013 at 00:49:55 UTC, Era Scarecrow wrote:
If 'auto ref' gets accepted for non-template functions, it goes
away. With M as you show, returning ref doesn't work so that
example I was going to suggest doesn't work.
auto ref will in all probability never work for non-template
1/ Generic code. You may not know that the data are big after
starting conglomerating more and more stuff.
auto ref for templates still exists and won't get away.
2/ Data may be small, but with an expensive copy mecanism.
Example?
And I can go on and on.
Yes go on, I'd like to hear more.
Excuse me if I misunderstood you, this happens, especially if
English is not the native language.
But you aren't talking only with me, but I want to hear your full
opinion.
And if I ignore something, then I have nothing say, because I
have no arguments.
Say you can take it as tacit consent.
On Saturday, 2 March 2013 at 21:46:49 UTC, Era Scarecrow wrote:
On Saturday, 2 March 2013 at 08:29:25 UTC, Namespace wrote:
Era Scarecrow:
Did I understand right that your answer is 'No, we don't need
something like const&'?
const& is ugly and suggests it is using a
Benchmarks on dpaste aren't very useful because I think no
optimization switches are used, and because the CPU is not
under control, so other unknown tasks can steal some of its
time.
Bye,
bearophile
I used optimation switches:
Application arguments:
-O -release -noboundscheck
But you're ri
I think the type of the parameter that is passed is intrinsic
to how the function gets compiled. I think, for that to work,
the compiler would have to compile two versions of the
function, one taking by-value and the other taking by-ref.
If we have this we have still the problem that moving a
A better way to do with would be to change (or extend) the abi,
so that
structs over a certain size are always passed by reference with
this
parameter type.
And what if you want to pass it by value?
I am a opponent of such automatic and uncontrollable compiler
intervention. Better to manually
You don't mark it with '&'.
Oh, then I understood you wrong.
I thought you meant that the compiler for each struct parameters
(whether marked or not) just automatically perform such changes.
Then you only need one version of the function. We could
use auto ref for this.
'auto ref' will prob
If Jonathan made this claim in there, I must have missed it.
Regardless,
there is an open pull request that implements auto ref, which
has not been
accepted or rejected yet.
Like I said, read the thread. Or better, read all my threads on
this topic.
Then just believe me. I have discussed the theme of 'auto ref' a
lot of times.
And I would be still happy if 'auto ref' would also work for
non-template functions. But I just think my idea still goes a
step further. After all, it takes into account the problem of
moving large structs.
Too bad, I had hoped for a little more discussion / feedback on
this topic.
Is it a good idea or a bad one. It is complete nonsense or has it
been a right to exist, etc.
What's wrong with you guys?
Finally, I think this behavior is very dangerous. Pass by
reference and value have very different. With that construct,
you'll never know which one you get as the compiler decide ! If
the compiler and not the programmer decide what the program
does (not implementation wise, but semantically), w
First, it introduce a new syntax, which is always a concern. It
add language complexity, and it likely to not be used
everywhere it should.
Yes, you're right. But I also said that the syntax does not
matter.
My intention was to stimulate thinking about the real issue.
Even if "auto ref" will wo
As said in another post, I think auto ref suffer pretty much
the same problem, but it is less problematic as you can't see
the result on rvalues anyway, so the compiler cannot really
screw you. It has the inconvenience of taking by ref many thing
that would benefit from pass by value.
The onl
On Sunday, 10 March 2013 at 19:27:01 UTC, Namespace wrote:
But you could prohibit any manipulation of a '&' parameter. Eg.
you could make him 'scope' by default (if 'scope' will work
someday).
A better solution would be to require that a Parameter with '
I also think that we do not need 'inline' or 'register'.
Nowadays, compilers can really assess the situation much better
than we do.
I don't see any reason to not allow the compiler to do so and
create copy on a per needed basis, by optimizing pass-by value
into pass-by-reference when it can
You never gave any rationale reason on that.
Because I just like to have the control over what is passed by
ref and what by value.
Maybe I want that a bigger struct is passed by value.
As long as I must denote parameters accordingly, in order that
the compiler decide instead of me, this is no
On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
You never gave any rationale reason on that.
Because I just like to have the control over what is passed by
ref and what by value.
I'm sorry, but what you like is ex
On Tuesday, 12 March 2013 at 09:38:19 UTC, deadalnix wrote:
On Tuesday, 12 March 2013 at 09:24:11 UTC, Namespace wrote:
You never gave any rationale reason on that.
Because I just like to have the control over what is passed by
ref and what by value.
I'm sorry, but what you like is ex
Here is what I think. How the thing is actually passed don't
matter. What does matter is that the semantic is know : ie that
the program will behave in a known way.
I agree.
As a consequence, if the compiler choose to pass by ref instead
of passing by value as an optimization, it must do so on
To repeat myself :
The caller is free to call the ref version of the function
unless
(rules evaluate in order) :
- The argument is an rvalue (in such case, no postblit is
executed as well).
- The argument is shared.
- The argument's postblit in not pure (weakly).
The callee must create a lo
One option, that I could think of why one should mark such
parameters, would be that the compiler can then point out what is
missing so that it would be potentially possible.
Example:
void foo (A a) {
Because 'a' is not const and not scope, the compiler could not
change the behavior from pass
On Saturday, 23 March 2013 at 21:04:25 UTC, Patrick Tinkham wrote:
Sorry for the question. I am a n00b to D. I tried to compile
the following code from Alexandrescu's book:
import std.stdio;
class A {
int x = 42;
}
unittest {
auto a1 = new A;
assert (a1.x == 42);
auto a2 = a1;
a2.x =
Hey guys,
I would like to show you my tries and thoughts about rvalue
references and their syntax.
As discussed in my other thread in the learn group
(http://forum.dlang.org/thread/uswucstsooghescof...@forum.dlang.org?page=2#post-mailman.294.1364252397.4724.digitalmars-d-learn:40puremagic.com),
The major downside is that if you don't come from C++ it's hard
to understand why 'ref &' means what you propose. The major
upsides are, as you mention, it's very concise and perfectly
intuitive if you DO come from C++. In the spirit of trying to
come up with something for comparison, the best
Because & in C++ means "by ref".
D has "ref" for that.
So ref& doesn't make sense. One might think it as a double
reference(?)
You are undermining my authority. :P
I choose ref& because it is a hybrid of the C++ ref style and D's
ref style.
That's what I said in my first post.
And C++ has co
I have to agree on that. My first impression was that ref& is
equal to c++11 &&
Kind Regards
Benjamin Thaut
Ok, it seems that I think differently.
And what is the general opinion of '&A' instead of 'ref &A'?
It has all the benefits that I described in my first post, but it
may not be so confu
As far as I studied the code, something like @ref isn't possible,
because ref is already a keyword. Except as Pseudo-property. But
this is a combination of '@' and 'ref' so that both, '@ref' and
'@ ref' would be valid.
I still like the idea of '&A'.
No I highly appreciate it, that you are trying to solve the
problem. The current state of the language on this is annoying
and it needs to be fixed.
I personally would like &A the question is if this is the
"D-Way". Maybe we should add a new keyword like "vref" for
"value reference".
Kind R
It's esoteric, which is bad, but concise, which is good. I
think perhaps the annoying aspect of this feature is how
attractive it would be to just get the power of the feature
implicitly without needing a new attribute or keyword.
Maybe you're right. But I like the idea that, if you want strict
But currently I have a problem with the implemenation of 'A&'.
I do not know how to convey the fact that behind the type is a
'&'. IMO the correct D way is to create a new type like
TypePointer -> TypeRvRef. But my attempts failed so far to
create such type.
Because of that I decided to declare
I could finally fix the problem.
Now for rvalue references an extra type is created: TypeRvRef.
But this solution does not work with templates. I do not yet
know how to solve this, but maybe someone knows advice.
Code: https://github.com/Dgame/dmd/tree/rvalueRef2
Since I still have no idea how
On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
As far as I studied the code, something like @ref isn't
possible, because ref is already a keyword. Except as
Pseudo-property. But this is a combination of '@' and 'ref' so
that both, '@ref' and &#
1 - 100 of 405 matches
Mail list logo
