Re: [your code here] 99 bottles of beer
import std.format;
template Bootle(alias Beer = 0)
{
static if(Beer < 99)
enum Bootle = Bootle!(Beer + 1);
else
enum Bootle = Beer;
pragma(msg,
format!"%d bottles of beer on the wall, %d bottles of beer.
Take one down, pass it around, %d bottles of beer on the wall."
(Beer ,Beer, Beer-1)
);
}
enum BootleBeer = Bootle!1;
void main(){}
:P
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: [...] Looking forward to this :)
Re: Messing with betterC and string type.
On Friday, 7 September 2018 at 16:20:29 UTC, H. S. Teoh wrote: Yeah, I don't remember that either! Was this a recent addition? Or is it an accidental feature (aka bug)? :-P If it is a bug, please keep it ;)
Re: Messing with betterC and string type.
On Friday, 7 September 2018 at 08:26:11 UTC, Kagamin wrote:
On Thursday, 6 September 2018 at 17:09:34 UTC, SrMordred wrote:
void foo(string s) {}
foo("this");
won't compile, since it won't make a String out of that
immutable(char)[] literal without an explicit initialization
of some sort.
//cannot pass argument "this" of type string to parameter
String s
iep, this seems a real problem. ;/
You can sort of have custom literals like in C++
String s(object.string t){ return String(t); }
foo("this".s);
Yes, but you don't really need this function.
struct String
{
this(object.string s){}
}
foo("this".String);
alias s = String; //if you want.
foo("this".s);
Re: Messing with betterC and string type.
On Thursday, 6 September 2018 at 16:50:01 UTC, Adam D. Ruppe
wrote:
this(object.string x) {}
Yep, this works.
which will work - immutable(char)[] is what object.string
actually is (and the compiler will often use that -
immutable(char)[], the proper name - and string, the
user-friendly name, totally interchangably).
Yes, the true problem arrives on the operations like concat "~"
that call some internal function to do that with strings. I can
hijack the string identifier, but i can´t replace the concat
operator right?
(Well, i already tried the module object; trick, but didn´t go
much far with that path.)
void foo(string s) {}
foo("this");
won't compile, since it won't make a String out of that
immutable(char)[] literal without an explicit initialization of
some sort.
//cannot pass argument "this" of type string to parameter String s
iep, this seems a real problem. ;/
Messing with betterC and string type.
I'm most of the time exploring the betterC lands
and was thinking about custom strings, and how to convert D into
D-betterC
hmm I wonder...
struct String{}
alias string = String;
string x = "test";
//cannot implicitly convert expression "test" of type string to
String
ok then...
struct String{
this(string x){}
}
//constructor app.String.this(String x) is not callable using
argument types (string)
Ok now things got weird.
...
this(String x){}
//same error.
Ok the string is a String but not a string... what monster I
created?
How to tame this chimera? templates off course
this(T)(T t){}
//compiles!!
Now some true utility:
string x = "test";
x = x ~ x;
//incompatible types for (x) ~ (x): both operands are of type
String
as expected:
...
String opBinary(string op, T)(T other)
{
return String();
}
//incompatible types for (x) ~ (x): both operands are of type
String
hmmm, whats happening?
x.opBinary!"~"(x);
//template app.String.opBinary cannot deduce function from
argument types !("~")(String), candidates are:
//source\app.d(9,12):app.String.opBinary(String op, T)(T
other)
Oh, it must be the string is not string chaos that I started.
String opBinary(alias op, T)(T other)
{
return String();
}
//compiles!!
Ok, so then *maybe* I can transform D normal code using 'string'
to D-BetterC only with aliasing my custom struct.(off course,
besides all other problems that may emerge)
My question is, i´m breaking something else, or this could be a
valid approach?
Re: This is why I don't use D.
On Wednesday, 5 September 2018 at 01:58:50 UTC, Jonathan M Davis wrote: On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d wrote: [...] This is part of why it's sometimes been discussed that we need a way to indicate which dub packages are currently maintained and work. A package updated last in February of 2016 may very well still work today with the latest compiler, or it may fail to compile as happens here. It depends on what the code is doing, what has changed in D since the last update, and how up-to-date the code really was when it was last updated (e.g. if it was ignoring deprecation warnings rather than fixing them, which I think was the case here). [...] Wouldn´t be interesting to specify the compiler version on dub.json? (I think ruby uses this idea)
Re: Struct destructors not available in -betterC?
On Tuesday, 10 July 2018 at 19:14:26 UTC, Gary Willoughby wrote: Looking at the page on -betterC it says that struct destructors are not available. See point 11: https://dlang.org/spec/betterc.html#consequences This doesn't seem to be true as I'm using them with no problem. Yep, the docs are not up to the last dmd updates.
Re: std.traits : Select - could it be better?
On Thursday, 5 July 2018 at 20:29:02 UTC, Steven Schveighoffer
wrote:
On 7/5/18 4:27 PM, Steven Schveighoffer wrote:
template BetterSelect(bool cond, alias temp1, alias temp2,
Args...)
{
import std.meta : Instantiate;
static if(cond)
alias BetterSelect = Instantiate!(temp1, Args);
else
alias BetterSelect = Instantiate!(temp2, Args);
}
ugh, got too cute for my own good :) No need for Instantiate
here:
alias BetterSelect = temp1!Args;
alias BetterSelect = temp2!Args;
-Steve
I find another solution :)
template Try(alias T, Args...)
{
static if( is( T!Args ) )
alias Try = T!Args;
}
alias U = Select!( isPointer!T, Try!( PointerTarget, T ), T );
std.traits : Select - could it be better?
alias U = Select!( isPointer!T, PointerTarget!T, T ); This don´t compile if T are not a pointer; so you have to do this: static if( isPointer!T ) alias U = PointerTarget!T; else alias U = T; Shouldnt the 'correct' way of Select to work is ignoring the choice that was not taken? I love the idea of Select, but because of this I almost never use it.
Re: A Case for Oxidation: A potential missed opportunity for D
and non-template-only Phobos.
unless they are using betterC (undefined reference to
'_d_arraycopy')?
Are you sure about this?
//flags: -betterC -noboundscheck
extern(C):
void main()
{
import core.stdc.stdlib;
int[] x = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];
int[] y = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];
import std.algorithm : map;
x.map!( x => x * 2 );
x[] = y[];
}
//compiles and works ok.
Re: betterC error?
Or use C malloc. We really should provide better tools to create arrays using C malloc (for those who want them). Like a betterC toolkit. -Steve Indeed, i´m creating my own "toolkit" for betterC stuff like alloc!Type(length); (much safer than malloc!) and other utilities :)
Re: betterC error?
On Tuesday, 12 June 2018 at 12:29:17 UTC, rikki cattermole wrote: (...) this line: byte[] data = [0, 1]; is an dynamic array allocated with GC. But if you declare as a static array like byte[2] data = [0, 1]; than its not GC allocated.
Re: DConf 2018 Videos
We're working to get each talk into separate videos, but it may take a while. Thank you very much! (for some odd reason the day 2 and 3 didn´t appear to me on youtube when I searched)
DConf 2018 Videos
There is some place where I can find this year conference videos with or without slides? Thanks!
Re: Tuple DIP
On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote: As promised [1], I have started setting up a DIP to improve +1, please.
Re: What do people here use as an IDE?
I keep jumping between VSCode and SublimeText3 atm using ST3. (but they are not IDEs ;P)
Re: D on quora ...
From https://wiki.dlang.org/Vision/2017H2: 2. @nogc: Use of D without a garbage collector, most likely by using reference counting and related methods Unique/Weak references) for reclamation of resources. This task is made challenging by the safety requirement. Eventually it will come (I hope) :) I'm on the game programming in D train also. And its a bless comparing to C++, but I have the same concerns about the impredictable GC pause time.
Re: D on quora ...
I think the GC discussion think will never go away because of the amount of c++ coders that come here. If you want to flee from C++ you have two realistic options: Rust and D. When you are looking at D and comparing metaprogramming, traits, ranges, UFCS, etc, its amazing: 'SO MUCH better than C++, i'ĺl leave right now!' BUT then there is GC. And its not only about performance. You are programming at 5 10, 15 years with manual memory management, you lived the your entire live under the law of "you will not pay for what you don't use". Then you have to accept that you have a GC doing things under the hood. Even if you understand whats going on (and thanks the GC series for that :)), its a difficult paradigm shift. I never had problems with GC, and im fine programming with it, but there is a c++ ghost in my ear every time speaking about manual management ;P But im so used to D now that everytime I look back at c++ it give me chills. and BetterC and noGC libs are coming, so I think there is a ever brighter future ahead :)
Re: D on quora ...
On Friday, 6 October 2017 at 18:42:02 UTC, H. S. Teoh wrote: On Fri, Oct 06, 2017 at 06:09:58PM +, Ali via Digitalmars-d wrote: On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote: > On Fri, Oct 06, 2017 at 05:14:51PM +, Rion via > Digitalmars-d wrote: > > https://www.quora.com/What-is-your-review-of-D-programming-language > > > > It seems that D still has the GC being mentioned up to > > today. > > > > Maybe its better to move the standard library slower to a > > non gc version in the future... > > Why is GC a problem? > > > T The reputation is D's GC is slow, and Manual Memory Management is fast The first point is valid (when are we going to get a better GC? :-/), but the second is questionable. But there's not much you can say to GC-phobic C/C++ aficiandos to convince them otherwise. (I used to be one of them.) T For me the important point is not directly about performance, but about determinism. I know when the GC is called, and i can set when to collect, but I have no idea what they will do, how much memory they will free nor the time they will spent doing it. And this lack of control is the true problem.
Re: Proposal: Object/?? Destruction
On Wednesday, 4 October 2017 at 10:03:56 UTC, aberba wrote:
Upon reading this, It triggered an idea.
On Saturday, 30 September 2017 at 16:10:44 UTC, Jonathan
Marler wrote:
[...]
DIP reminds me of object destruction.
/* extracts success & message from returned type. Could be
tuple or structure, etc. May even eliminate use of tuples for
multiple return
*/
auto {success, message} = callVoldermortFunction();
This is concept is used in Kotlin. JavaScript es6 takes it
even further (function parameters and arguments support object
destruction)
+1
Re: Just playing with compiler explorer to see assembly line count.
On Tuesday, 3 October 2017 at 17:15:04 UTC, Daniel Kozak wrote: is not bad https://godbolt.org/g/bSfubs Thats cool, I never used copy xD. (but you returned the .copy range, not the 'r' array ;p) //now with ldc 1.4 and -O3 -release -boundscheck=off foreach -> 99 lines .filter.copy -> 368 lines .filter.array -> 1229 lines (1002 lines with -O1)
Re: Just playing with compiler explorer to see assembly line count.
On Tuesday, 3 October 2017 at 13:53:38 UTC, rikki cattermole
wrote:
Be warned, x86 cpu's today are not like they were 10 years ago.
A good portion of a symbol could be full of nop's and it could
end up being faster than the one without them.
Next, compare against ldc, not gdc primarily. Its better
maintained and ugh more inline with dmd (its a bit of a mess,
lets not go there). Of course nothing wrong with doing both.
std.container.* is basically dead. We need to replace it. We
are currently waiting on std.experimental.allocators before
going much more further (also a lot of other no-gc stuff).
Compare (on https://d.godbolt.org/ with "ldc -O3" and "gdc
-O3"):
---
auto test1(int[] arr, int cmp)
{
int[] r;
foreach(v ; arr)
if(v == cmp)r~=v;
return r;
}
import std.container.array;
auto test2(ref Array!int arr, int cmp)
{
Array!int r;
foreach(v ; arr)
if(v == cmp)r.insert(v);
return r;
}
---
With ldc the results are similar.
5k+
And I know, im not into performance comparison yet. But you know,
less code, more cache friendly (and sometimes better performance).
But my big surprise was with .filter.
Just playing with compiler explorer to see assembly line count.
//D compiled with gdc 5.2 -O3
auto test(int[] arr, int cmp)
{
int[] r;
foreach(v ; arr)
if(v == cmp)r~=v;
return r;
}
// 51 lines of assembly
auto test(int[] arr, int cmp)
{
return arr.filter!((v)=>v==cmp).array;
}
//1450 lines... what?
Ok let me look also at c++:
//gcc 7.2 -O3
vector test(vector& arr, int cmp) {
vector r;
for(auto v : arr)
if(v == cmp)r.push_back(v);
return r;
}
//152 lines. more than D :)
vector test(vector& arr, int cmp) {
vector r;
std::copy_if (arr.begin(), arr.end(), std::back_inserter(r),
[cmp](int i){return i==cmp;} );
return r;
}
//150 lines. That what i expected earlier with D.
Hmm. let me be 'fair' and use std.container.array just for
curiosity:
auto test(ref Array!int arr, int cmp)
{
Array!int r;
foreach(v ; arr)
if(v == cmp)r.insert(v);
return r;
}
//5542 lines... what??
Someone interested to discuss about this?
Or point me some grotesque mistake.
Re: C++17 Init statement for if/switch
On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
[...]
There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization
But in general, I agreed with you.
Initialization in D is pretty uniform now though. What corners
am I missing?
It's usually:
name = (args);
Structured bindings... I think C++ did it badly, actually. They
had the {...} syntax fr object construction that worked
everywhere and using the same for deconstruction would've
allowed for quite natural tuples, which manifest almost as
language-level constructs by then (with the help of 'auto' in
template parameters).
Nothing too serious, just miss somethings like:
void add_vec( vec2 a, vec2 b );
add_vec( {10,20}, {20,30} );
Re: C++17 Init statement for if/switch
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote: On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote: Without alot of usage, it will just be an esoteric construct that looks confusing to the average developer. That is correct. After a while it gets tiring to see a neverending stream of complexity added to the language while things that would actually help (like IDE support) do not get any attention. As a general rule, if it's being added to C++, it's probably a bad idea. There are two thinks of c++ that I miss a little on D: - Structured binding - Uniform initialization But in general, I agreed with you.
Re: struct constructors and destructors.
On Wednesday, 19 July 2017 at 14:09:32 UTC, SrMordred wrote:
On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:
On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
Is there a reason that the following code
struct Foo
{
this (string name)
{ do_something(name); }
~this()
{ undo_something(); }
}
Foo foo = void;
void open()
{
foo = Foo("test"); // <- this line
}
tries to OpAssign foo to itself then calls foo's destructor?
What happens is this.
void open()
{
foo = () {
Foo _tmp = Foo.__ctor("test");
return _tmp;
} ();
}
Hm, isnt that wrong?
If I destroy resources on the dtor, wouldn't it invalidate the
resource on the copy?
Also, C++ behaves differently
No Sorry, it behaves almost the same.
just in D ctor and dtor are not called on declaration even if you
drop " = void".
Re: struct constructors and destructors.
On Wednesday, 19 July 2017 at 09:09:40 UTC, Stefan Koch wrote:
On Wednesday, 19 July 2017 at 07:48:28 UTC, Danni Coy wrote:
Is there a reason that the following code
struct Foo
{
this (string name)
{ do_something(name); }
~this()
{ undo_something(); }
}
Foo foo = void;
void open()
{
foo = Foo("test"); // <- this line
}
tries to OpAssign foo to itself then calls foo's destructor?
What happens is this.
void open()
{
foo = () {
Foo _tmp = Foo.__ctor("test");
return _tmp;
} ();
}
Hm, isnt that wrong?
If I destroy resources on the dtor, wouldn't it invalidate the
resource on the copy?
Also, C++ behaves differently
