Re: A Few thoughts on C, C++, and D
On 2017-05-29 18:08, Russel Winder via Digitalmars-d wrote: My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet. I know you have reported a few bugs for DStep. Are those all or anything else that has not been reported yet? -- /Jacob Carlborg
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote: That definition currently there is more precise than the definition on that page has been historically... Apparently, it is not. Do you have a reference to Walter's change regarding `in` becoming just `const`? Because a change like that should get reflected in the spec, otherwise we might just continue to ignore said spec and expect our grievances to be "gracefully" resolved later. What I mean is I'd rather see/make the change reflected there...
Re: Another "D is cool" post
On Tuesday, 30 May 2017 at 05:14:21 UTC, H. S. Teoh wrote: OK, this is the 3rd or 4th time somebody asked about this. What exactly is involved in making a post on the D blog? Hopefully it would not require too much more effort, because I usually wouldn't have much time to spend on top of the time I already spent writing the original post. If it's just a matter of copy-n-pasting the text somewhere, then perhaps somebody could do that for me? For a guest post, you write it up and submit it to me (plain text, Markdown, HTML, gist, whatever, aldac...@gmail.com). I go through a few editing passes and submit my suggestions to you for approval. Then I take care of the rest. After that, you'll get email notifications when someone comments on the post, and it's a good idea to watch the reddit thread, but that's it.
Re: A Few thoughts on C, C++, and D
On Tuesday, 30 May 2017 at 01:46:02 UTC, bachmeier wrote: I'm not necessarily disagreeing with RW's post. My reading is that the goal would be to get D into the enterprise, but maybe I misinterpreted. If D as a successor to Vala leads to more projects like Tilix, that's great. I never quite understood the enterprise-focus either. What I like to see for a language is a difficult use scenario being maintainable. I sometimes browse large code bases just to see if a language leads to readable code. writing better documentation for Dub, and so on. Incremental improvements lead to incremental adoption of D. Yes, I think retention is the most important factor in the case of D. Identify and understand why polyglot programmers either stay with D or leave. Then give those areas the highest priority, especially exit-triggering issues. Focusing on getting many libraries won't work, because you need to maintain them. I never use unmaintained libraries... Having many unmaintained libraries is in a way worse than having a few long-running ones that improve at a steady pace. I'll also note that Vala didn't catch on, so being the successor to Vala by itself may not help D adoption. Being perceived as the best for something helps. Vala was the best for something narrow. I think Rust is being perceived as the best for runtime-less programming with high level features (right or wrong) and Go is perceived as having a runtime for web services. So I personally perceive Rust and Go in different sectors of the spectrum. I have more problems placing Nim, Haxe, D etc.
Re: Another "D is cool" post
On Tue, May 30, 2017 at 01:44:58AM +, Mike Parker via Digitalmars-d wrote: > On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: > > On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: > > > [snip an excellent post] > > I think a longish post like this would make an excellent shortish > > post for the D blog. > > Yes, please. OK, this is the 3rd or 4th time somebody asked about this. What exactly is involved in making a post on the D blog? Hopefully it would not require too much more effort, because I usually wouldn't have much time to spend on top of the time I already spent writing the original post. If it's just a matter of copy-n-pasting the text somewhere, then perhaps somebody could do that for me? T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: Built-in RAII in D
On 05/29/2017 06:25 AM, aberba wrote: On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote: With regards to your popularity argument: IMHO the only people we should concern ourselves with are those that evaluate which are the right tools for their current task as objectively as feasible given their respective circumstances, not those that are swayed by whatever is the current hype on social site XYZ. But that's just me. True. Its the current pollution in the software dev community. Baffles me. I'm glad the OP brought this forward. +1(billion)
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 21:13:53 Stanislav Blinov via Digitalmars-d wrote: > On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote: > > On Monday, May 29, 2017 20:00:12 Stanislav Blinov via > > > > Digitalmars-d wrote: > >> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: > >> > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via > >> > > >> > Digitalmars-d wrote: > >> >> `in` is `const scope` > >> > > >> > Walter recently changed is that in is now just const, > >> > because scope was not properly implemented previously, and > >> > folks were using in all over the place, so the odds of code > >> > breaking when scope was properly implemented were high. > >> > > >> > - Jonathan M Davis > >> > >> Huh, I missed that... peculiar change. :\ So now it would > >> break for people who did use `in` properly? > > > > Since scope was never properly defined for anything other than > > delegates, it's questionable that _anyone_ who used it used it > > properly. > > Errm... It was always *defined* > (https://dlang.org/spec/function.html#parameters). The fact that > it wasn't implemented for anything but delegates is another issue > entirely. > Changing spec to please those who didn't care to follow it in the > first place just seems weird to me. That definition currently there is more precise than the definition on that page has been historically, but even as it stands, it's not particularly precise. Assuming a particular interpretation when the spec is not precise, and the compiler does not implement anything of the sort, is just begging for trouble when the compiler actually does implement something - which is precisely why Walter decided that it was too dangerous to let in imply scope when he actually started implementing scope to do something. It's quite possible that what some folks assumed scope would do won't run afoul of Walter's changes, but in many cases, it will, and since what he's doing with scope involves stuff like making it so that you have to mark local variables with scope (and not in the way that we've had scoped classes which are supposed to have been deprecated), what he's doing definitely doesn't match what scope was originally, even if it follows the basic idea. But scope has never been well-specified. - Jonathan M Davis
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 22:20:34 UTC, Ola Fosheim Grøstad wrote: I don't think Russel Winder was talking about enterprise code, but for a language to take hold you need at least one significant publicly visible application written in it. E.g. Go has Docker, Rust has a Firefox engine, and so on... It is taken as a sign of maturity. I'm not necessarily disagreeing with RW's post. My reading is that the goal would be to get D into the enterprise, but maybe I misinterpreted. If D as a successor to Vala leads to more projects like Tilix, that's great. However, an easier way to accomplish the same thing would be wrapping more C libraries, writing better documentation for Dub, and so on. Incremental improvements lead to incremental adoption of D. I'll also note that Vala didn't catch on, so being the successor to Vala by itself may not help D adoption.
Re: Another "D is cool" post
On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. Yes, please.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 21:43:30 UTC, bachmeier wrote: Incremental is key. It's what enabled me to use D for my work. Apologies to anyone that feels only enterprise code bases with at least 10 million lines of code are worth talking about, but good luck convincing anyone to rewrite a code base that critical and that big. I don't think Russel Winder was talking about enterprise code, but for a language to take hold you need at least one significant publicly visible application written in it. E.g. Go has Docker, Rust has a Firefox engine, and so on... It is taken as a sign of maturity.
Re: Value closures (no GC allocation)
On Monday, 29 May 2017 at 21:26:11 UTC, MakersF wrote: 1) Capture by value. This is the ability to have a lambda which behaves as expected in the example Vittorio showed That's a known bug in the implementation; it is supposed to work that way now. (Though the bug has been open for so long I treat it as intended and tell people how to work with it, it isn't actually what the design says.) 1) The lambda is not compatible with a delegate anymore 2) There need to be a special notation for reference capture That's true, but that's the whole point of the new thing. The auto-generated struct btw can be converted to a delegate with `&obj.opCall` or copied into a manually allocated buffer with `memcpy(buffer, &obj, obj.sizeof)`, just like the manually written struct to do the same. (and might have convenience methods, e.g. toDelegate and copyInto, to do these things too). - if capture is provided, then the lambda is rewritten as a struct, which the explicit variables in the capture list being captured by value, and the remaining being captured by reference (so there would still be implicit capture, which is considered convenient in many programming languages). Eh, if you do any explicit, I think it should be ALL explicit. There's value in the simple proposals to syntax rewrite into a struct... but going beyond that I think is a negative and should not be in this proposal.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 20:58:54 UTC, Brad Roberts wrote: Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem. Incremental is key. It's what enabled me to use D for my work. Apologies to anyone that feels only enterprise code bases with at least 10 million lines of code are worth talking about, but good luck convincing anyone to rewrite a code base that critical and that big. At the end of the day I'm the one writing D code for a living and the enterprise developers are stuck writing C++ and Java.
Re: Value closures (no GC allocation)
On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote:
Snip
I think the discussion is going in two orthogonal directions,
which are:
1) Capture by value. This is the ability to have a lambda which
behaves as expected in the example Vittorio showed
void delegate()[] arr;
foreach(i; 0..5)
{
arr ~= () => writeln(i);
}
foreach(f; arr)
{
f();
}
This is going to print "4 4 4 4"
2) Allocation of the lambda context. Whether this is performed by
the GC, in the stack, or with another mechanism.
The reason these two points are orthogonal is that, as Adam
showed, the ability to achieve one of the point is independent
from the other (the capture by reference context allocation can
be changed with the scope keyword, and from my understanding it's
an implementation detail, it does not guarantee the use of the
GC. And the value of capture by value could be allocated on the
heap with the GC).
I see two weaknesses in this proposal:
1) The lambda is not compatible with a delegate anymore
2) There need to be a special notation for reference capture
Adam said
I'm against that, no need adding it and it complicates the
whole thing. For example, "ref int _i;" as a struct member;
there's no such thing in D. (the compiler could do it but
still). And you'd have to explain the lifetime. Just no point
doing this, the current behavior is completely fine for this.
The other problem I see, which is easily noticeable when defining
the new grammar, is that we are proposing a grammar which is a
superset of the current one, but we are proposing it as an
addition.
One of the assumption of D is that the GC is not a problem in the
vast majority of the situations, and you want things to just work.
I think there is big value in the capture context not having to
be explicit (even if usually I much prefer explicity over
implicity).
Considered this, I'd propose an extension of the lambda syntax
instead of an addition of a ValueFunctionLitteral.
Given the syntax
[...] (...) ... {...}
which is composed of what I will call "capture", "parameters",
"attributes", "body" (with capture and attributes optional)
the semantic would be:
- if no capture is provided the behavior is equivalent to today
(automatic capturing by reference in a context allocated however
the compiler prefers). This provides full backward compatibility.
Example
(int i) { writeln(i + j);}
j is captured by reference in a context allocated (possibly) on
the GC. This is compatible with a delegate void(int).
- if capture is provided, then the lambda is rewritten as a
struct, which the explicit variables in the capture list being
captured by value, and the remaining being captured by reference
(so there would still be implicit capture, which is considered
convenient in many programming languages).
This is potentially unsafe since a reference could be copied when
copying the struct, and the struct might outlive the referred
object.
Example
[x] (int i) { writeln(i + j + x);}
x is captured by value in a local struct.
j is captured by reference in a local struct.
This is not a delegate anymore (different ABI).
- if "delegate" is used, then the capture context is allocated
however the compile prefers
[x] delegate (int i) { writeln(i + j + x);}
x is captured by value in a (possibly) GC context.
j is captured by reference in a (possibly) GC context.
This is a delegate (compatible ABI).
This thus is an extension of the lambda syntax to allow capturing
by value, but maintaining all the current properties and
providing a way to remain compatible with the delegate functions.
You can also use the @nogc attribute to verify that the GC is not
used (and in case also "delegate" is used "scope" will need to be
used so that the compiler does not require the GC).
What are your opinions?
Please state if there are some misconceptions on the current
situation.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote: On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote: On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via > > Digitalmars-d wrote: >> `in` is `const scope` > > Walter recently changed is that in is now just const, > because scope was not properly implemented previously, and > folks were using in all over the place, so the odds of code > breaking when scope was properly implemented were high. > > - Jonathan M Davis Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly? Since scope was never properly defined for anything other than delegates, it's questionable that _anyone_ who used it used it properly. Errm... It was always *defined* (https://dlang.org/spec/function.html#parameters). The fact that it wasn't implemented for anything but delegates is another issue entirely. Changing spec to please those who didn't care to follow it in the first place just seems weird to me. But regardless, nothing will break because of scope-related stuff unless you use the -dip1000 switch, which would then require scope in a number of places that it wasn't before (including on local variables in a number of cases IIRC), making it so that even if in had stayed const scope, pretty much regardless of how you used it, code would break (which is going to make life fun when when we finally transition from dip 1000 to being optional to being the normal behavior). With that, I see no problem. Yes, enabling dip1000 behavior would cause some breakage, that's the point of having it as a switch in the first place.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a real pain in the a### and using C++ is only a little bit better. Having a number of exemplar applications showing how good D is for this sort of application would be a big win. I have been steeling myself to rewrite Me TV in D for two years, but there is always another problem that means leaving it in C++ is easier. I'm glad to see the message resonated with you, thanks for watching :) My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet, and wrapping manually is a pain, and there is no GIR files for these. Thus D is a non starter whereas C++ can just use the C header files. This inability to get past the inertia is a huge barrier. Seriously, I end up with C++ because the manual wrapping hill is too steep. I can understand this since if GtkD never existed I probably would have gone with Python or Vala, it would have been way too much work to bite off. Unfortunately at the end of the day someone has to step up and do the work and I suspect that gstreamer is a pretty niche area of interest. And… if the application is written in C++ or C there might be others willing to join in. As soon as the application is written in D, there appears to be no audience of people willing to get stuck in to help evolve the application. So here is the real barrier: writing GtkD/GStreamerD applications is less attractive because everyone in the universe expects such applications to be written in C or C++. For Tilix the number of D contributions has been quite small, though I'm not convinced that it's because of D any more then it's because developers have little experience or interest in GTK and desktop applications. I think most of the C, C++ or Python based GTK open source projects also suffer from lack of contributors, it's always an issue in the open source world unless your project happens to be "hot" for some reason. Each person trying to reach over the barrier tends to be an island to themselves as no-one else seems to give a about the problem that person is interested in. The isolation of the people trying to get D some traction is arguably the biggest barrier to traction for D. It's the "no-one does it because no-one does it" problem. Again though isn't this common for most open source projects? I will say that I've always found the D community to be very welcoming and I've never considered myself isolated or an island. It's more just a case that I have an itch to write desktop applications and this gives me an opportunity to scratch it. Other folks may have different itches and not be interested in working on my project, GTK apps or other things and that's OK. If everyone in the D community got interested in and just supplied moral support and advice for everyone else, even though the application was uninteresting, there might be the possibility of serious traction. Which then becomes a self-fulfilling prophesy. Not to be harsh, moral support isn't worth a hill of beans, give me people willing to work and get shit done. To me this is the biggest thing, it feels like there is a lack of applications written in D. However, maybe it's just me and I'm not looking in the right places. As a humorous and somewhat related item, there was a recent thread about Tilix in the reddit/ubuntu page with this witty comment: "Oh my god, a real D application" https://www.reddit.com/r/Ubuntu/comments/6ddf0t/tilix_is_a_stunning_tiling_terminal_emulator/
Re: A Few thoughts on C, C++, and D
On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote: On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: IMO, the most important thing is getting the job done. * getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously. At least as important as getting the job done, is doing jobs. As much fun as it is to debate and discuss what could or needs to be done to attract one group of developers or another, actually using and releasing systems built with D are going to contribute to accumulating to the total mass of code. Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: IMO, the most important thing is getting the job done. * getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a real pain in the a### and using C++ is only a little bit better. Having a number of exemplar applications showing how good D is for this sort of application would be a big win. I have been steeling myself to rewrite Me TV in D for two years, but there is always another problem that means leaving it in C++ is easier. Would writing a mixed C++/C app be viable in your case (provide core logic in D and interface with external stuff using C++, combine via C++ interop)? GObject code requires RAII and C does not provide it. And the C++ wrappers do a poor job because of all the dynamic runtime behaviour the C++ wrapper model badly. D should be able to cover this ground easily. Well, yeah, C has no builtin concept of objects (you can hack it in, of course) and without object lifetimes, no RAII. My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet, and wrapping manually is a pain, and there is no GIR files for these. Thus D is a non starter whereas C++ can just use the C header files. This inability to get past the inertia is a huge barrier. Seriously, I end up with C++ because the manual wrapping hill is too steep. Doing this manually sucks, yeah, but I wouldn't say it's too steep in general. As an experiment I ported an old application from python to both C++14 (with all the new shiny things), as well as D. In C++14 it took me about a week to get everything right. In D two days. And that included writing bindings for C API things. And… if the application is written in C++ or C there might be others willing to join in. As soon as the application is written in D, there appears to be no audience of people willing to get stuck in to help evolve the application. So here is the real barrier: writing GtkD/GStreamerD applications is less attractive because everyone in the universe expects such applications to be written in C or C++. Yeah, that is a problem with D not having a large community. But personally, I much prefer an understandable, easily maintainable code base in D over whatever Lovecraftian nightmare you end up with C or C++. Even at the cost of low external input. Each person trying to reach over the barrier tends to be an island to themselves as no-one else seems to give a about the problem that person is interested in. The isolation of the people trying to get D some traction is arguably the biggest barrier to traction for D. It's the "no-one does it because no-one does it" problem. If everyone in the D community got interested in and just supplied moral support and advice for everyone else, even though the application was uninteresting, there might be the possibility of serious traction. Which then becomes a self-fulfilling prophesy. And both of these paragraphs are why I fairly regularly check digitalmars.d.learn to see if someone needs help I think I can provide.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote: > On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: > > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via > > > > Digitalmars-d wrote: > >> `in` is `const scope` > > > > Walter recently changed is that in is now just const, because > > scope was not properly implemented previously, and folks were > > using in all over the place, so the odds of code breaking when > > scope was properly implemented were high. > > > > - Jonathan M Davis > > Huh, I missed that... peculiar change. :\ So now it would break > for people who did use `in` properly? Since scope was never properly defined for anything other than delegates, it's questionable that _anyone_ who used it used it properly. But regardless, nothing will break because of scope-related stuff unless you use the -dip1000 switch, which would then require scope in a number of places that it wasn't before (including on local variables in a number of cases IIRC), making it so that even if in had stayed const scope, pretty much regardless of how you used it, code would break (which is going to make life fun when when we finally transition from dip 1000 to being optional to being the normal behavior). - Jonathan M Davis
Re: Another "D is cool" post
On Monday, 29 May 2017 at 19:54:22 UTC, Guillaume Boucher wrote: Seems like the perfect job for a scripting language like Python. I'm not sure why you decided to compare everything to C. Even C programmers will agree with you that in D you can do things in a shorter way -- just slower/bloated/more magic/with less control/not portable/. Just to be sure, you realize D is not a scripting language, don't you? This is a rather confused argument. First you say a scripting language would be perfect for this case (without any explanation of how it would be better than D) and then you list a bunch of objections that would be a valid response to someone doing this in a scripting language but not D.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote: `in` is `const scope` Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high. - Jonathan M Davis Huh, I missed that... peculiar change. :\ So now it would break for people who did use `in` properly? In any case, to be clear, I certainly meant `const scope`.
Re: Another "D is cool" post
On Monday, 29 May 2017 at 19:07:03 UTC, H. S. Teoh wrote: So, recently in one of my pet projects I have a bit of code that takes a string, fills in a code template, invokes the D compiler to create a shared object, then loads the object with dlopen() and calls dlsym() to get the entry point into the compiled code as a function pointer. Seems like the perfect job for a scripting language like Python. I'm not sure why you decided to compare everything to C. Even C programmers will agree with you that in D you can do things in a shorter way -- just slower/bloated/more magic/with less control/not portable/. In all the examples you bring, there's nothing special about D. You can do anything in C++/Go/Rust/Swift/Python/language> with comparable complexity. The tricky part, though, is that .mangleof only works on an identifier defined in the *current* program; the compiler can't do it for a symbol in a string that's to be passed at runtime to another invocation of the compiler. And AFAIK, there's currently no way to ask the compiler "what would be the mangling of mymodule.symbol?" if 'mymodule' and 'symbol' only exist in the shared object, not in the main program. Not a problem in any other language (C++ has a well-defined ABI, dynamic languages don't need that). I enjoy D, but some of those fanboy posts are just totally worthless.
Re: Another "D is cool" post
On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. In any case, great writeup!
Re: Another "D is cool" post
On Monday, 29 May 2017 at 19:07:03 UTC, H. S. Teoh wrote: So, recently in one of my pet projects I have a bit of code that takes a string, fills in a code template, invokes the D compiler to create a shared object, then loads the object with dlopen() and calls dlsym() to get the entry point into the compiled code as a function pointer. [...] Besides the syntax (clean code), productivity is one main reason I choose D as my primary language.
Another "D is cool" post
So, recently in one of my pet projects I have a bit of code that takes a
string, fills in a code template, invokes the D compiler to create a
shared object, then loads the object with dlopen() and calls dlsym() to
get the entry point into the compiled code as a function pointer.
I've written the equivalent code in C before -- and while it worked, it
required a lot of care to ensure things don't blow up, or if they do,
that errors are correctly handled and properly cleaned up. This time
round, though, I found several aspects of D very nice for writing this
sort of code:
1) String-processing: the input string needs some processing before
being put into the code template, so here I get to use nice built-in
facilities like std.array.split. Whereas in the C version, I'd have to
use things like strchr or strstr, carefully make copies of the results
or, if the input string was writable, insert null terminators (which
makes for a poorer API from a design POV), then take care to free
buffers afterwards. Normal course of the day for writing C code, it's
true, but rather fidgety, error-prone, and, after having written string
manipulation C code for the n'th time, it gets tiring really fast. The
resulting code in D is much simpler (only 4-5 lines; the C equivalent
would probably take about twice that, what with null checking, copying
buffers, etc.), more readable, and more maintainable.
2) Instantiating the code template and invoking the compiler: in D, it
just takes a single call to std.file.write() to write the code template
to a temporary file. Very handy. In C, but I'd have to worry about
dealing with FILE*, handling errors, not forgetting to fclose(), etc..
Again, normal course of the day for writing C code, but just more
fidgety and error-prone. Invoking the compiler in C involves trickery:
I'd have to explicitly fork-and-exec, which means lots of manual
housekeeping to make sure fork succeeds, keep track of whether I'm in
the parent or child, setting up the arguments to exec*(), manually
handle return codes, etc.. In D, thanks to the awesome API of
std.process (kudos to Lars Kyllingstad, et al, for the excellent revamp
of the original klunky std.process), all I need to do is:
auto result = execute([
compiler,
option1,
option2,
srcFile,
"-of" ~ soFile
]);
if (result.status != 0) { /* handle compiler errors */ }
No need to manually fiddle with fork(), dup(), close(), execv(), and all
the paraphrenalia associated with them.
3) Even better yet, std.process.execute captures compiler output
automatically. In C, if I want to do that, I'd have to deal with
manually redirecting stdout/stderr, set up a pipe for copying the output
to a buffer, manage the buffer, etc.. Again, nothing out of the ordinary
for a C coder but it's just a lot of fussy housekeeping that reduces
productivity. In D, std.process handles it all nicely for me -- plus it
works on Windows too, should I ever desire to compile the code on
Windows. In C, I'd have to rewrite the entire code to use Windows API
calls instead of Posix calls -- a major undertaking. (Of course,
replacing dlopen & co with Windows calls is a different story -- perhaps
Phobos should have a new module for handling this!)
4) As it turns out, I *did* need to capture the compiler's output
eventually. Here's where some of D's features made things highly
productive: the compiled code template declares a public symbol that the
main program needs to know, so that it know what symbol to look up with
dlsym() when loading the resulting shared object. I could easily
hardcode the mangling of this symbol, since I control what goes in the
code template. However, it's ugly, and not future-proof: if D's
mangling scheme were to change in the future, the code would break.
Plus, it's just ugly to have to manually write out a mangled symbol when
the compiler can already do it for you.
The tricky part, though, is that .mangleof only works on an identifier
defined in the *current* program; the compiler can't do it for a symbol
in a string that's to be passed at runtime to another invocation of the
compiler. And AFAIK, there's currently no way to ask the compiler "what
would be the mangling of mymodule.symbol?" if 'mymodule' and 'symbol'
only exist in the shared object, not in the main program.
So the solution is to insert a `pragma(msg, symbol.mangleof)` in the
code template, and have the main program parse the output of the
compiler when it compiles the shared object, so that it learns the
mangled identifier directly. If this were C++ code, I'd be stuck up the
creek without a paddle: hardcoding the mangled symbol would be
unavoidable. But thanks to pragma(msg) and .mangleof in D, this was a
cinch. Not to mention that std.process.execute already captures output
for me automatically, so all I need to do is to search for the symbol in
the captured output.
(Granted, in C there'd be no
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote: > `in` is `const scope` Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was properly implemented were high. - Jonathan M Davis
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:
I probably didn't say it very well.
With C++, if you have const T&, it will accept both lvalues and
rvalues. A number of folks (particularly those writing games)
want an equivalent to that in D where they can then pass both
lvalues and rvalues without incurring a copy. Historically,
Andrei has been against it because of issues with rvalue
references, but based on some of the more recent discussions,
it sounds like it _might_ be possible to come up with a
solution that he'd be okay with (particularly with some of the
improvements that come with DIPs 25 and 1000). Ethan Watson has
expressed interest in writing a DIP on the matter, so I expect
that we'll see one at some point here.
- Jonathan M Davis
This indeed does sound like a good extension for DIP1000, i.e:
struct Vector3 { float x, y, z; }
void foo(in ref Vector3 v) { /*...*/ }
foo(Vector3(1,2,3));
Invalid now, even with -dip1000, but, since `in` is `const scope`
it feels like it should be made allowed: `scope` guarantees the
reference won't escape, the argument obviously will live through
the call to foo(), so it could be made to "just work", even for
mutables, i.e. `scope ref`. Of course, without `scope` it should
remain an error.
In regards to move semantics and && also mentioned here, there is
only one case where current D looks inferior to C++: D's "double
move":
struct X
{
Y y;
this(Y y) { move(y, this.y); }
}
auto x = X(Y());
// ctor above benefits from the compiler, so here's
// a more explicit case:
Y y;
X x2 = move(y);
With rvalue references and explicit move semantics of C++, this
could be made into one bitblast. With current D, it requires two.
However, this does seem like a compiler optimization issue, and
is mentioned by Andrei:
https://github.com/dlang/phobos/pull/4971#issuecomment-268038627
So all in all, it looks to be possible to achieve the desired
results purely by enhancing the language, with no syntax changes
and without adding any "rvalue reference" types.
Re: A Few thoughts on C, C++, and D
On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a real pain in the a### and using C++ is only a little bit better. Having a number of exemplar applications showing how good D is for this sort of application would be a big win. I have been steeling myself to rewrite Me TV in D for two years, but there is always another problem that means leaving it in C++ is easier. GObject code requires RAII and C does not provide it. And the C++ wrappers do a poor job because of all the dynamic runtime behaviour the C++ wrapper model badly. D should be able to cover this ground easily. My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet, and wrapping manually is a pain, and there is no GIR files for these. Thus D is a non starter whereas C++ can just use the C header files. This inability to get past the inertia is a huge barrier. Seriously, I end up with C++ because the manual wrapping hill is too steep. And… if the application is written in C++ or C there might be others willing to join in. As soon as the application is written in D, there appears to be no audience of people willing to get stuck in to help evolve the application. So here is the real barrier: writing GtkD/GStreamerD applications is less attractive because everyone in the universe expects such applications to be written in C or C++. Each person trying to reach over the barrier tends to be an island to themselves as no-one else seems to give a about the problem that person is interested in. The isolation of the people trying to get D some traction is arguably the biggest barrier to traction for D. It's the "no-one does it because no-one does it" problem. If everyone in the D community got interested in and just supplied moral support and advice for everyone else, even though the application was uninteresting, there might be the possibility of serious traction. Which then becomes a self-fulfilling prophesy. In the mean time the Rust community are trying all of this sort of marketing to try and prove to themselves they are actually relevant and not a small clique. OK so they have some financial support, but maybe that can be got round in the D community. IMO, the most important thing is getting the job done. I don't want to write my own pdf generator, my own web socket lib, json lib,... I just want to get my job done... Some languages are not fast, nor offer control nor safe, ... they get jobs done for (most) people. Plus their docs are good for figuring things out for (most) people. Majority of developers are probably web developers or library-consumers using other more technical devs work. Chasing after companies doesn't help. Its better to capitalise on D's productivity and make it easy to get things done (as a community). It's individuals that come together to form companies that end up being aquired by bigger corps or distrubt the industry.
Re: [OT] I found a bug in Excel 2016
On Fri, May 26, 2017 at 06:16:29PM -0400, Steven Schveighoffer via Digitalmars-d wrote: > On 5/26/17 10:38 AM, Steven Schveighoffer wrote: > > Here is my story: > > > > http://www.schveiguy.com/blog/2017/05/how-to-report-a-bug-to-microsoft/ > > > > And it worked: https://news.ycombinator.com/item?id=14426978 > > :) [...] Wow. T -- Try to keep an open mind, but not so open your brain falls out. -- theboz
A Few thoughts on C, C++, and D
A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a real pain in the a### and using C++ is only a little bit better. Having a number of exemplar applications showing how good D is for this sort of application would be a big win. I have been steeling myself to rewrite Me TV in D for two years, but there is always another problem that means leaving it in C++ is easier. GObject code requires RAII and C does not provide it. And the C++ wrappers do a poor job because of all the dynamic runtime behaviour the C++ wrapper model badly. D should be able to cover this ground easily. My biggest problem of the moment is libdvbv5 and librtlsdr. DStep seemingly cannot help as yet, and wrapping manually is a pain, and there is no GIR files for these. Thus D is a non starter whereas C++ can just use the C header files. This inability to get past the inertia is a huge barrier. Seriously, I end up with C++ because the manual wrapping hill is too steep. And… if the application is written in C++ or C there might be others willing to join in. As soon as the application is written in D, there appears to be no audience of people willing to get stuck in to help evolve the application. So here is the real barrier: writing GtkD/GStreamerD applications is less attractive because everyone in the universe expects such applications to be written in C or C++. Each person trying to reach over the barrier tends to be an island to themselves as no-one else seems to give a about the problem that person is interested in. The isolation of the people trying to get D some traction is arguably the biggest barrier to traction for D. It's the "no-one does it because no-one does it" problem. If everyone in the D community got interested in and just supplied moral support and advice for everyone else, even though the application was uninteresting, there might be the possibility of serious traction. Which then becomes a self-fulfilling prophesy. In the mean time the Rust community are trying all of this sort of marketing to try and prove to themselves they are actually relevant and not a small clique. OK so they have some financial support, but maybe that can be got round in the D community. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 15:31:26 UTC, WebFreak001 wrote: well for the extension functions I wrote that if the ref parameter is the first argument and it's called with ufcs syntax, it could implicitly add the ref probably. I don't think there are any big issues with that, it does look like a member function and the programmer could easily read it as "this modifies it" Surely better than just requiring ref everywhere. But still, a.swap(b) just feels intuitive. Hard to say what I like here, because the ref parameter is usually the first anyway. Besides swap() you rarely use more than one ref parameter.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote: I think it's mostly about good taste on what you define functions to take as ref input. I have a feeling the present way is not a big problem in practice because it is intuitive somehow. Besides, member functions mutate their class/struct anyway, and we don't want to lose our ability to call extension funcions with same syntax as member ones. well for the extension functions I wrote that if the ref parameter is the first argument and it's called with ufcs syntax, it could implicitly add the ref probably. I don't think there are any big issues with that, it does look like a member function and the programmer could easily read it as "this modifies it"
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 07:46:07 UTC, Stanislav Blinov wrote:
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
[snip]
Explicitly? It is:
import std.stdio;
struct S
{
int v;
}
void foo(ref S s)
{
writeln("took S by ref: ", s.v);
}
void foo(S s)
{
writeln("took rvalue S...");
foo(s); // calls ref overload
}
void main()
{
S s;
foo(s); // calls ref overload
foo(S.init); // calls rvalue overload
}
And for templates we have auto ref.
Of course, I should have noticed one can already do it that way.
No need for change, then (imo).
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 08:40:27 UTC, ketmar wrote:
yet i must say that using pointers in a code where they should
be references makes me... nervous. it just doesn't feel right.
but meh, i'll trade that (and safety, 'cause `&` is unsafe) for
"call site ref indicator".
So one win with dip1000 is it allows it:
---
@safe void foo(scope int* a) {}
@safe void bar() {
int a;
foo(&a);
}
---
$ dmd ppp -c
ppp.d(4): Error: cannot take address of local a in @safe function
bar
But with dip 1000:
$ dmd ppp -dip1000 -c
# success!
Of course, dip1000 breaks the living crap out of just about
everything else (though all the errors are in phobos) but it
is semi-sane in this case.
Re: Built-in RAII in D
On Monday, 29 May 2017 at 11:58:56 UTC, evilrat wrote: Can't sell to those who don't buy. I can't say for all, but I have noticed that those who generally use C++ will tell that speed matters "everywhere" (oh right, they do use C++ "for a reason") Well, I am in that C++ group... So yes, you cannot sell a GC language to them on it's own terms for _new_ projects. But if you can show that an existing legacy C++ framework benefits in terms of maintenance and further development then it could be a selling point to managers for such projects. Not all C++ code bases need max performance throughout, many are running on much better machines today than they were originally limited to. So if you can show a better maintenance scenario, with a gradual move to D, then it could be a way in. IIRC Inkscape is using a Boehm collector. Integrating Inkscape with D could be one such "legacy" project that would be worth noticing.
Re: Built-in RAII in D
On Monday, 29 May 2017 at 11:06:20 UTC, Ola Fosheim Grøstad wrote: One fun tutorial would be to integrate with a tedious C++ framework and let the GC take care of allocations in C++ code where speed doesn't matter. Then write a C++ integration tutorial around it. That could be a selling point. Can't sell to those who don't buy. I can't say for all, but I have noticed that those who generally use C++ will tell that speed matters "everywhere" (oh right, they do use C++ "for a reason") And there is another kind of people. Even if something happens to be faster than their 'favorite language/framework of choice' they start complaining on how unfair the competiton. And don't forget anti-GC hype wave, it tries to convince how bad, slow, memory hungry, clunky and ugly (literaly all the galactic evil in one face!) your GC is and so it should be banished! Not that I'm trying to convince not to do tutorials, but I'm skeptical on that matter. But I myself interested in seeing more such materials too.
Re: Built-in RAII in D
On Monday, 29 May 2017 at 01:36:31 UTC, Mike Parker wrote: More broadly, I think what we need to be doing is teaching people that D's GC is not their grandfather's GC and that, unless they are doing something highly specialized, they probably don't need alternatives. The GC is fine by itself for a number of apps and, where it isn't, mixing in a bit of @nogc is probably better than cutting it out altogether. One fun tutorial would be to integrate with a tedious C++ framework and let the GC take care of allocations in C++ code where speed doesn't matter. Then write a C++ integration tutorial around it. That could be a selling point.
Re: Built-in RAII in D
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote: With regards to your popularity argument: IMHO the only people we should concern ourselves with are those that evaluate which are the right tools for their current task as objectively as feasible given their respective circumstances, not those that are swayed by whatever is the current hype on social site XYZ. But that's just me. True. Its the current pollution in the software dev community. Baffles me. I'm glad the OP brought this forward.
Re: [Semi-OT] DoS with hashing
On Monday, 29 May 2017 at 09:08:45 UTC, Random-dev wrote: Interesting article: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/ I remember seeing some discussion on this previously on the forums. https://issues.dlang.org/show_bug.cgi?id=7179 Any update on this issue? I was curious about that Marvin32 hash mentioned at the end, looks like MS open-sourced it with .Net a couple years later,though patented: https://www.reddit.com/r/programming/comments/4jpve5/marvin32_net_hash_function_simple_safe_and/
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 09:17:31 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote: > > With C++, if you have const T&, it will accept both lvalues and > > rvalues. A number of folks (particularly those writing games) > > want an equivalent to that in D where they can then pass both > > lvalues and rvalues without incurring a copy. > > Mmm. But it sounds more like a compiler hint on const value types > could work? Except when the making of a copy creates > side-effects... so you would have to guard against that. > > The whole thing with temporaries in C++ in part lead to && move > semantics. So this is a slippery slope, perhaps. I don't know what's going to be proposed, so I can't really say much about it. I just know what the problem is that they want to solve. However, I can say that whatever they do, having const as a requirement would not fly, because D's const is so restrictive. I think that in a previous discussion, it was suggested that we do something like have an attribute like @rvalue that would go on a ref parameter which would then make it so that the ref parameter would accept rvalues. So, we may get something like that, or it could be that something completely different will be proposed. My main concern is that we not simply make it so that ref accepts rvalues, because then it makes it harder to know when ref is used because a value is going to be returned via the ref parameter and when it's used simply to avoid copying. But I don't know what it will take to alleviate Andrei's concerns about rvalue references, and I expect that that's ultimately the hurdle that any DIP would have to get over. However, DIPs 25 and 1000 should solve the related @safety concerns which were always what Walter was worried about. - Jonathan M Davis
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote: With C++, if you have const T&, it will accept both lvalues and rvalues. A number of folks (particularly those writing games) want an equivalent to that in D where they can then pass both lvalues and rvalues without incurring a copy. Mmm. But it sounds more like a compiler hint on const value types could work? Except when the making of a copy creates side-effects... so you would have to guard against that. The whole thing with temporaries in C++ in part lead to && move semantics. So this is a slippery slope, perhaps. solution that he'd be okay with (particularly with some of the improvements that come with DIPs 25 and 1000). Ethan Watson has expressed interest in writing a DIP on the matter, so I expect that we'll see one at some point here. I think D is going the wrong way with all this special casing. Memory management is hard enough as it is. At some point Rust's type system will look easier... Much better if you can get away with using a compiler hint and give the compiler a flag that turns that hint into an absolute for the game-programmers. It could also be an annotation on a type, that isn't part of the type. (This type should aways be passed as const-ref)
[Semi-OT] DoS with hashing
Interesting article: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/ I remember seeing some discussion on this previously on the forums. https://issues.dlang.org/show_bug.cgi?id=7179 Any update on this issue?
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
Nick Sabalausky (Abscissa) wrote:
In response to any claim that this isn't a real problem in practice, I
submit the possibility that, if it indeed isn't a real problem, maybe
that's *because* of people (like Stefan and ketmar) simply avoiding the
feature entirely so that it *doesn't* become a problem.
exactly! you can include Adam here too, btw. we all prefer to use pointer
args exactly to avoid *the* *problem*. so it is not a problem for us
anymore... but we aren't solved it, we simply cheated. basically, my only
`ref` usage is `in auto ref` (which is not a "real" ref anyway, as argument
cannot be changed).
side note: also, with pointers i can do `void foo (int a, bool* res=null)
{...}`. not a big deal: one can always create set of overloads to get the
same effect with ref, but -- less typing! ;-)
yet i must say that using pointers in a code where they should be
references makes me... nervous. it just doesn't feel right. but meh, i'll
trade that (and safety, 'cause `&` is unsafe) for "call site ref indicator".
that's why i don't bother writing @safe code, btw: in one or another way i
will be forced to hack aroung @safe restrictions, so no reason to start
that dance at all. (or just mark the whole thing as @trusted and hope for
the best)
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 08:22:23 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote: > > I expect that we're going to see a DIP related to rvalue > > references at some point here, because some of the folks > > (particularly the game folks) think that it's critical to be > > able to have a function that doesn't care whether it's taking a > > value by value or by ref - just that it takes it efficiently, > > and they don't want to be forced to use auto ref to do it > > (since that requires templates). > > So it would use ref or value depending on the target platform? I > guess that could make sense since some platforms allow vector > registers as parameters, but it sounds more like an > implementation detail? > > Or did you mean something else? I probably didn't say it very well. With C++, if you have const T&, it will accept both lvalues and rvalues. A number of folks (particularly those writing games) want an equivalent to that in D where they can then pass both lvalues and rvalues without incurring a copy. Historically, Andrei has been against it because of issues with rvalue references, but based on some of the more recent discussions, it sounds like it _might_ be possible to come up with a solution that he'd be okay with (particularly with some of the improvements that come with DIPs 25 and 1000). Ethan Watson has expressed interest in writing a DIP on the matter, so I expect that we'll see one at some point here. - Jonathan M Davis
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
Nicholas Wilson wrote:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
It seems nice in theory but how will it interact with generic code?
Perhaps it should be optional and purely documentative.
exactly like "&" does.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
Ola Fosheim Grostad wrote: This is information that a good IDE could be designed to provide. when people start talking about how IDE can help to solve particular language problem, it is a clear sign of bad language design.
Re: Safe code as an I/O requirement
On Sunday, 28 May 2017 at 16:58:53 UTC, aberba wrote: https://lwn.net/Articles/708196/ From the look of things and feedbacks from several security analysts and system developers, [exposed] I/O needs to be memory safe. GStreamer multimedia library developed in C has safety issues [see article]. What would its safety be if it was written in D (along with its plugins)? GStreamer has already adopted Rust and is slowly migrating away from C into Rust. Search for their presentation at RustConf Kiev 2017. Also GNOME guys have been having meetings with Rust design team as there is the possibility to replace Vala with Rust. See GUADEC Mexico city 2017.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote: I expect that we're going to see a DIP related to rvalue references at some point here, because some of the folks (particularly the game folks) think that it's critical to be able to have a function that doesn't care whether it's taking a value by value or by ref - just that it takes it efficiently, and they don't want to be forced to use auto ref to do it (since that requires templates). So it would use ref or value depending on the target platform? I guess that could make sense since some platforms allow vector registers as parameters, but it sounds more like an implementation detail? Or did you mean something else?
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
Meta wrote: On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote: Meta wrote: If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the function takes its parameters by ref or out... You're should've RTFM. now imagine that you're reading some code: foo(a); vs: foo(ref a); which code style is easier to read without constant jumping into documentation? Is this ever actually a problem in practice? yes. aliced has this syntax for a long time. for a reason. and i must say that i'm adding alot of random features to aliced, but very little of 'em survives. Anyway, having to add ref or out at the call site will greatly hamper metaprogramming. not more then "&" does. except with `auto ref` -- which is misdesigned feature anyway (forcing programmer to do the work compiler can do without any external help is not a good design; besides, compiler can do that work *better*).
Re: Any video editing folks n da house?
On Wednesday, 24 May 2017 at 09:27:59 UTC, Andrei Alexandrescu wrote: I'm thinking publicly available videos so the footage is already out there. One question I'd want to ask is: What is the legal status of the resulting video? This is purely because of software licensing. My nonlinear editing of choice is Davinci Resolve, but I've only ever done it for hobby projects that make no money. In the case of providing a video authored with the software to the D Foundation, I'm not entirely sure the "free" license covers such usage. (I also doubt I'd have the time to devote to cutting a video at this stage, but it's the first question I thought of when viewing this thread.)
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, May 29, 2017 07:39:40 Dukc via Digitalmars-d wrote: > But what would be worth a consideration, is that perhaps one > should be allowed to pass rvalues as reference with something > like this? According to TDPL, ref arguments do not take rvalues > to prevent bugs where you accidently copy something before > passing it, and that's a good rationale. But shouldn't it still > be allowed explicitly? I expect that we're going to see a DIP related to rvalue references at some point here, because some of the folks (particularly the game folks) think that it's critical to be able to have a function that doesn't care whether it's taking a value by value or by ref - just that it takes it efficiently, and they don't want to be forced to use auto ref to do it (since that requires templates). - Jonathan M Davis
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
But what would be worth a consideration, is that perhaps one
should be allowed to pass rvalues as reference with something
like this? According to TDPL, ref arguments do not take rvalues
to prevent bugs where you accidently copy something before
passing it, and that's a good rationale. But shouldn't it still
be allowed explicitly?
Explicitly? It is:
import std.stdio;
struct S
{
int v;
}
void foo(ref S s)
{
writeln("took S by ref: ", s.v);
}
void foo(S s)
{
writeln("took rvalue S...");
foo(s); // calls ref overload
}
void main()
{
S s;
foo(s); // calls ref overload
foo(S.init); // calls rvalue overload
}
And for templates we have auto ref.
Re: Should out/ref parameters require the caller to specify out/ref like in C#?
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote: Should the language spec say that those functions should get called with `foo(ref input);` so that surprises like this where the user doesn't check the docs/implementation can't happen (like in C#)? I think it's mostly about good taste on what you define functions to take as ref input. I have a feeling the present way is not a big problem in practice because it is intuitive somehow. Besides, member functions mutate their class/struct anyway, and we don't want to lose our ability to call extension funcions with same syntax as member ones. Same thing as with struct/class separation: in principle it sounds pointless that whether used by value or by ref has to be defined with the type, but it somehow just works intuitively in practice. (My personal experience. Don't know if others feel the same way) But what would be worth a consideration, is that perhaps one should be allowed to pass rvalues as reference with something like this? According to TDPL, ref arguments do not take rvalues to prevent bugs where you accidently copy something before passing it, and that's a good rationale. But shouldn't it still be allowed explicitly?
Re: Ali's slides from his C++Now talk
On 05/28/2017 11:35 PM, mate wrote: >> :C >> :C++ >> :D > What was the reaction of the C++ crowd seeing this? I was out of time and was being shoved off stage but I managed to go quickly to the last slide. I remember hearing laughs from the audience. :) It's easy to make jokes like that among friends. I already knew about half a dozen of the attendees personally; I made close friends with about another dozen or so during the conference; I've talked to, mingled, etc. with perhaps 3-4 dozen others... So, it's easy presenting to friends. :) Ali
