Re: @property needed or not needed?
Isn't it possible to have parentheses optional only for UFCS?
E.g.
Allow:
I 5.writeln
Dissallow:
void f()
{
writeln("hi");
}
f; // this currently works
I don't know if this is possible to implement.
Re: auto ref and non-templated functions
if a function's argument is const ref, what would be the problem of allowing it to to be passed const ref lvalues + rvalues?
Error about @disabled constructor when there is a custom one
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the default constructor because
space needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace =
3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
Yes, the default constructor is @disabled BUT I am not using that
one. I want to use the other one - the custom constructor. I
guess it signals an error because it has those defaults
parameters. But shouldn't the compiler choose that one?
Re: Error about @disabled constructor when there is a custom one
From Jonathan M Davis: "...At this point, I don't think that the situation with default constructors and structs is going to change. It's a result of requiring init properties for all types, and is thus a "forced fault" in the language..." Why does requiring init properties for all types results in this? What does that even mean?
Re: Error about @disabled constructor when there is a custom one
Why is it required to have the .init property? Where is it useful and why was this decision made?
Re: Error about @disabled constructor when there is a custom one
On Wednesday, 23 January 2013 at 12:07:48 UTC, monarch_dodra
wrote:
On Wednesday, 23 January 2013 at 11:03:45 UTC, Minas Mina wrote:
Why is it required to have the .init property? Where is it
useful and why was this decision made?
.init is very useful in the sense that it represents the raw
object, *statically*.
This is useful for declaring statics.
It also makes constructors straightforward, in a simple 2 pass
scheme (copy T.init, then run constructor).
More importantly, the T.init state is also the one you are
supposed to have post destruction (Or at least, calling a
destructor on T.init is supposed to be safe). This allows for
some *very* efficient and built-in move semantics:
To move a into b, simply destroy b, memcopy a into b, memcopy
T.init over a.
Notice how massively simpler this is compared to C++'s explicit
Rvalue references? I *dare* you to try doing that with C++.
"DEFAULT" constructor breaks this entire scheme, as it implies
that T.init is not an object's natural state. It jeopardizes a
static destructible state.
The problem is that this overlaps with having an "explicit
constructor that takes no arguments". This is particularly
problematic for objects that have pointers to payloads that
represent "shallow" objects. AA's is a prime example of this:
//
void insert5(int[int] i)
{
i[5] = 5;
}
int[int] a; //Un-initialized T.init state
int[int] b = [1 : 1]; //initialized
int[int] c = [1 : 1]; c.remove(1); //Empty but initialized
insert5(a);
insert5(b);
insert5(c);
assert(a is null); //Oh no!
assert(b == [1 : 1, 5 : 5]); //5 correctly appended
assert(c == [5 : 5]);//5 correctly copied
//
In this example, I had to jump through loops to initialize c.
Really good explanation. Thank you. So @disabled default
constructor was just a "side effect" of doing those that you
described.
Re: @property - take it behind the woodshed and shoot it?
f = g; where it means f(g) is really ugly. I wouldn't like to see
this.
Also:
void printSomeStuff()
{
//...
}
We are going to see code like this:
printSomeStuff; // i think that's ugly.
I suggested make parentheses optional only for UFC syntax.
Also isn't it possible to allow @property for functions that
belong in a class/struct only?
Re: Incorporating D
On Friday, 25 January 2013 at 22:00:02 UTC, Rob T wrote: Finally there are editors, and IDE's with decent D support. In fact I find that C++ IDE and editor support is no better, and fails often due to the near impossible nature of correctly parsing through C++ code. --rt Come on, Visual C++ is awesome on code completion! But I have to admit, mono-d does a good job (as I am using ubuntu).
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
My opinion is to allow calling a function without parentheses only in UFCS (properties must be called without). Is that so hard to implement?
Re: About ref used for performance reasons with struct
On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
Ok, We have 2 usages of ref : when you actually need to modify
informations, and for performance reasons. Let's talk about the
second one.
Passing by ref to improve performance is not ideal. First this
is quite hard to know when it is actually faster to pass by ref
and to pass by value, especially in generic code. Secondly it
is easy to forget to use ref at some location, and a lot of
small performance improvement are lost in the process. Finally,
this may be error prone.
I'm thinking about it for a while now and I'm now convinced
that we should allow the compiler to do that job for us. Let me
explain.
When a function accept a struct, the compiler is free to use
that function, or an altered one taking a reference as
parameter. Here are some rules the compiler can use to know
which one to call from callee side :
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 isn't modified for the vanilla function, but must
create a local copy of the argument in the following reasons in
the ref version :
- The argument is binded to a mutable ref.(even as hidden
argument as for member method).
- The argument is actually modified.
- address of anything coming from the struct is taken.
The compiler is free to apply such treatment only in a branch
of the callee, ie :
// Compiler choose to create an alternative ref version for
performance.
void foo(MyStruct s) {
if(condition) {
// Operation require a copy to not alter what the
caller see.
// A s is copied on stack and postblit is called.
s.field = 5;
} else {
// No operation requiring local copy is performed.
// No local copy is created.
}
}
The compiler is however disallowed to create multiple copies in
the callee. If several branches requires it, then the copy have
to be made in a common branch.
Note that the compiler don't HAVE to do this, but is allowed
to. Modifying the spec in such way allow the compiler to avoid
many copies of struct let us get rid of most ref parameters,
keeping them for what they really are for.
+1
It's really ugly to write "const ref Blah blah" all the time when
the compiler could it.
Re: Possibility of non stop-the-world GC in the future?
@nogc sounds nice, but how could someone use classes(OOP) with this?
Re: Possibility of non stop-the-world GC in the future?
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut wrote: Am 19.02.2013 17:45, schrieb Minas Mina: @nogc sounds nice, but how could someone use classes(OOP) with this? The same way you do in c++. Manual memory management. But I guess you would like to have OOP as well. Would that be possible with @nogc?
Re: Migrating dmd to D?
A big problem is that GDC and LDC in the distros are not up to date. GDC was 2.058 I think. This has forced me to use dmd even for my final code (I don't want to get in the trouble of building them by source, this is ancient).
Re: safeD
On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
Thanks for the input - but where is SafeD defined? Is there
a compiler switch?
I haven't looked at D in a while, it was just too big for ARM
Cortex M, smaller PowerPC and similar targets - a google search
got me to the SafeD topic.
No, you don't need to compiler switch. What you need is to mark
functions as @safe. E.g:
@safe void safe_foo()
{
}
If you don't mark them they are considerded @system.
Re: D benchmarks
You can use my raytracing in D project. https://github.com/minas1/D_Raytracing It's very incomplete at the current state by the way (no soft shadows, no texturing, no reflection, no antialiasing).
Re: D for the JVM
On Friday, 22 March 2013 at 17:32:19 UTC, Kagamin wrote: It's also somewhat wrong to pair D with C++. C++ can't bring anything new to JVM because as a language it's not more powerful than Java, ... What? That's clearly wrong. C++ is far more powerful than Java. One example is templates - java has generics, not templates.
Re: bearophile can say "i told you so" (re uint->int implicit conv)
Consider: uint u = ...; int x = u; Wouldn't a warning be enough?
Re: My thoughts & tries with rvalue references
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote: And to pull the reverse: Why should '@val ref' be more intuitive than ref&? Or why should be '@ref' more intuitive? What I mean by that: Both the Property as well as the hybrid path have their weaknesses and are not necessarily immediately obvious. But we should choose one of them and focus on this so that somebody can make a pull request for it. 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(?)
Re: My thoughts & tries with rvalue references
Personally yes, I prefer @ref more. But you are right that it's not nice to be an annotation.
Re: Disable GC entirely
I agree that language support for disabling the GC should exist. D, as I understand, is targeting C++ programmers (primarily). Those people are concerned about performance. If D as a systems programming language, can't deliver that, they aren't going to use it just because it has better templates (to name something).
Re: Disable GC entirely
On Monday, 8 April 2013 at 13:01:18 UTC, Regan Heath wrote: I've always hated the fact that C++ has 2 memory models new/delete and malloc/free and I've never liked new/delete because it doesn't allow anything like realloc - why can't I reallocate an array of char or wchar_t?? Try using malloc on something that contains a type with a constructor inside and you'll see. The constructor will not be called :) malloc and friends are bad heritage due to C compatibility. I stay away from them.
Re: Disable GC entirely
Sorry, if it wasn't clear. I was talking about C++.
Even if you are not mixing the two, you can still get f*** up.
struct S
{
S()
{
cout << "S()\n";
}
};
int main()
{
S *s = new S(); // constructor is called
S *s2 = (S*)malloc(sizeof(S)); // constructor is NOT called
}
So you see an innocent struct type and you decide to use malloc
instead of new... If it has a constructor/destructor/... those
will not be called. It's just asking for trouble.
Re: DIP 36: Rvalue References
I hope this proposal gets implemented soon :)
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu wrote: On 4/10/13 7:30 AM, Manu wrote: The _problem_ is that functions are virtual by default. It's a trivial problem to solve, however it's a major breaking change, so it will never happen. I agree. We may as well save our breath on this one. Hence my passing comment that spawned this whole thread, I see it as the single biggest critical mistake in D, and I'm certain it will never be changed. I've made my peace, however disappointing it is to me. I disagree with the importance assessment, but am soothed by your being at peace. Andrei Why is virtual by default a problem? You could have non-virtual by default and would live happily until a day where you forget to declare the base class destructor virtual. Then you spent a lot of time trying to find why you are leaking memory. In C++ you have to be aware all the time not to forget something and screw everything. D is more forgiving, at a small cost of performance. So I don't buy the non-virtual by default argument. If your profiler tells you that a particular virtual function is the bottleneck, go on and make it final. That's why profilers exist.
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu wrote: On 4/10/13 7:30 AM, Manu wrote: The _problem_ is that functions are virtual by default. It's a trivial problem to solve, however it's a major breaking change, so it will never happen. I agree. We may as well save our breath on this one. Hence my passing comment that spawned this whole thread, I see it as the single biggest critical mistake in D, and I'm certain it will never be changed. I've made my peace, however disappointing it is to me. I disagree with the importance assessment, but am soothed by your being at peace. Andrei Why is virtual by default a problem? You could have non-virtual by default and would live happily until a day where you forget to declare the base class destructor virtual. Then you spent a lot of time trying to find why you are leaking memory. In C++ you have to be aware all the time not to forget something and screw everything. D is more forgiving, at a small cost of performance. So I don't buy the non-virtual by default argument. If your profiler tells you that a particular virtual function is the bottleneck, go on and make it final. That's why profilers exist.
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu wrote: On 4/10/13 7:30 AM, Manu wrote: The _problem_ is that functions are virtual by default. It's a trivial problem to solve, however it's a major breaking change, so it will never happen. I agree. We may as well save our breath on this one. Hence my passing comment that spawned this whole thread, I see it as the single biggest critical mistake in D, and I'm certain it will never be changed. I've made my peace, however disappointing it is to me. I disagree with the importance assessment, but am soothed by your being at peace. Andrei Why is virtual by default a problem? You could have non-virtual by default and would live happily until a day where you forget to declare the base class destructor virtual. Then you spent a lot of time trying to find why you are leaking memory. In C++ you have to be aware all the time not to forget something and screw everything. D is more forgiving, at a small cost of performance. So I don't buy the non-virtual by default argument. If your profiler tells you that a particular virtual function is the bottleneck, go on and make it final. That's why profilers exist.
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu wrote: On 4/10/13 7:30 AM, Manu wrote: The _problem_ is that functions are virtual by default. It's a trivial problem to solve, however it's a major breaking change, so it will never happen. I agree. We may as well save our breath on this one. Hence my passing comment that spawned this whole thread, I see it as the single biggest critical mistake in D, and I'm certain it will never be changed. I've made my peace, however disappointing it is to me. I disagree with the importance assessment, but am soothed by your being at peace. Andrei Why is virtual by default a problem? You could have non-virtual by default and would live happily until a day where you forget to declare the base class destructor virtual. Then you spent a lot of time trying to find why you are leaking memory. In C++ you have to be aware all the time not to forget something and screw everything. D is more forgiving, at a small cost of performance. So I don't buy the non-virtual by default argument. If your profiler tells you that a particular virtual function is the bottleneck, go on and make it final. That's why profilers exist.
Re: Attribute inference for auto functions?
Yes, please do attribute inference!
Re: DIP 36: Rvalue References
On Wednesday, 17 April 2013 at 17:50:07 UTC, Namespace wrote: Thanks to Kenji there is now a corresponding pull request: https://github.com/D-Programming-Language/dmd/pull/1903 Let us hope that it will be quickly merged. I still hope that Andrei or Walter say something to this topic. Maybe we have a chance with this pull request. ;) Finally, I'm tired of copy-pasting the same code just to change to "ref". :)
Re: DIP 36: Rvalue References
On Wednesday, 17 April 2013 at 19:29:51 UTC, Namespace wrote:
Finally, I'm tired of copy-pasting the same code just to
change to "ref". :)
What do you mean?
This:
/// dot product of two Vector3 vectors
auto dot(T) (Vector3!T u, Vector3!T v) @safe pure nothrow
{
return u.x * v.x + u.y * v.y + u.z * v.z;
}
/// dot product of two Vector3 vectors
auto dot(T) (ref Vector3!T u, ref Vector3!T v) @safe pure nothrow
{
return u.x * v.x + u.y * v.y + u.z * v.z;
}
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote: On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote: I don't think adding more to the language is the sane thing to do right now. Why not? Could you explain this? This issue is discussed since more than a year and it is a very annoying issue. And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this. Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now. I thought D was driven by its community.
Re: Impressed
The only thing Java is good for is portability. And its standard library is very good too. However the language as it is, really sucks in my opinion. I mean, there's no way to change the value of a primitive type passed to a method? Come on.
Re: Ubuntu 12.04 and DMD 2.060
On Tuesday, 7 August 2012 at 00:12:55 UTC, Alex Rønne Petersen
wrote:
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu
12.04? On all 12.04 systems I have access to, all D programs
consistently segmentation fault in gc_init().
I have dmd64 on ubuntu 12.04 64 bit, and it works fine.
The code:
import std.stdio;
void main()
{
writeln("Hello, world!");
}
Compiled with dmd test.d -m64
works fine, it prints "Hello, world!".
Did you forget to uninstall dmd 2.059?
std.algorithm countUniq pull request
I have written a function that returns the number of unique elements in an input range (along with some unittests), and put it in std.algorithm. I have also made a pull request for it. Is it considered useful to be an addition to phobos? Can someone review it? Thanks
Re: Which D features to emphasize for academic review article
1) I think compile-time function execution is a very big plus for
people doing calculations.
For example:
ulong fibonacci(ulong n) { }
static x = fibonacci(50); // calculated at compile time! runtime
cost = 0 !!!
2) It has support for a BigInt structure in its standard library
(which is really fast!)
bug with auto or what?
I'm writing an insert() function for a binary tree in D:
Note: Node is a value type (struct)
Node!(T)* insert(T) (Node!(T)* root, T val)
{
if( root is null )
{
root = new Node!T();
root.value = val;
root.left = root.right = null;
}
else
{
if( val < root.value )
root.left = insert(root.left, val);
else
root.right = insert(root.right, val);
}
return root;
}
This works (compiles).
auto insert(T) (Node!(T)* root, T val)
{
if( root is null )
{
root = new Node!T();
root.value = val;
root.left = root.right = null;
}
else
{
if( val < root.value )
root.left = insert(root.left, val); // line x
else
root.right = insert(root.right, val); // line y
}
return root;
}
This doesn't compile.
test.d(x): Error: forward reference to inferred return type of
function call insert((*root).left,val)
test.d(y): Error: forward reference to inferred return type of
function call insert((*root).right,val)
Is it a bug with auto or something else?
Re: 1 matches bool, 2 matches long
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote: On 4/25/2013 10:49 PM, Ali Çehreli wrote: It certainly behaves that way but it isn't an integer type and that's why it is unintuitive. But it is an integer type. It is an integral type _internally_. A bool type should have the values true/false. When someone sees foo(45) he expects it to call an overload that receives an _integral_ value. Which overload is going to be called is a detail (short or long in this example). It is confusing to call an overload that takes bool. Boolean are true/false, not 0, 1 or anything else.
Re: 1 matches bool, 2 matches long
On Saturday, 27 April 2013 at 11:41:30 UTC, kenji hara wrote: First, I can guess that why Walter disagree *fixing* this problem. http://dlang.org/overview.html Major Design Goals of D 9. Where D code looks the same as C code, have it either behave the same or issue an error. C doesn't have a bool type, so how can D behave the same?
Re: 1 matches bool, 2 matches long
VRP is only useful when doing this: short s = 1000; // 1000 is int, but it's safe to put it into a short Integers are not booleans. I agree with the others that bool being treated as an int is an implementation detail derived from C. Or are you just bored for doing: if( x == 0 ) instead of if( x ) ?
Re: 1 matches bool, 2 matches long
On Sunday, 28 April 2013 at 22:40:33 UTC, Andrei Alexandrescu
wrote:
On 4/28/13 5:41 PM, kenji hara wrote:
Yes, as Andrei mentioned, it is sometimes useful. But, at
least during
overload resolution, it must not occur.
Kenji Hara
Well the problem has other ramifications beyond bool. Consider:
import std.stdio;
int fun(short v1) { return 1; }
int fun(long v1) { return 2; }
void main(string[] args)
{
writeln(fun(10_000));
writeln(fun(100_000));
}
This prints "1 2". So the behavior of bool in this case is
consistent with the behavior of other integral types.
Andrei
It's not entirely the same. You provided two overloads of
integral types. bool is not integral.
And yes, I personally don't like this either, but I could live
with it. Buy fun(1) calling the bool overload? It's ridiculous.
"Code that looks correct should be correct". fun(1) calling bool
overload sure looks and is correct.
Re: primitive value overflow
I agree that checks for overflow should exist in debug builds (and not exist in release builds).
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sunday, 19 May 2013 at 18:30:09 UTC, deadalnix wrote:
void buzz(Foo f) {
f.foo(); // Rely in faith. It is invalid and way easier to
write than the valid code, which is THE recipe for it to spread.
}
Shouldn't this throw a NullPointerSomething?
Re: The stately := operator feature proposal
I don't think this is useful. At least when I see "auto" in the code I immediately understand what's going on, whereas with this proposal I have to double check my code to see if it's ":=" or "=".
Re: Points of Failure
On Tuesday, 28 July 2015 at 19:30:45 UTC, Jonathan M Davis wrote: And his scoring system is going to put most projects into fail territory _very_ quickly. An interesting read though. - Jonathan M Davis Because most project fail?
Re: D for Game Development
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? GC's up. I was thinking of using D for my game server (which is in C++ at the moment)... is the gc going to be such an issue? I know of @nogc but I also do know that some stuff needs gc, e.g strings and exceptions. From the things I read on this forum, it seems work is being done to make exceptions not use the gc. How is that moving along;
Re: D for Game Development
On Thursday, 30 July 2015 at 14:18:21 UTC, Brandon Ragland wrote: On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? GC's up. Minecraft, written in java which has a GC does perfectly fine. A GC is not a reason a game cannot be developed. Look at how many browser-based games there are, which use a GC somewhere from the interpreted Flash or JS. Not really. http://www.minecraftforum.net/forums/support/server-support/server-administration/1916245-garbage-collection-issues-help-with-java Look it up in google.
Re: Synchronized classes have no public members
On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis
wrote:
Ultimately, I think that we're better off with TDPL's
definition of synchronized classes than the synchronized
functions that we have now, so I do think that the change
should be made. However, I also think that synchronized
classes as TDPL describes are limited enough to be of
questionable usefulness. Stripping off the outer layer of
shared is unlikely to be sufficient in all but basic cases
(and synchronized classes can't do any better than that, I
don't think), meaning that you're likely going to have to cast
away shared to do much with shared anyway, in which case,
having a synchronized class loses at least some of its value.
It can still encapsulate shared (which is good), but it
doesn't necessarily make it much easier or safer to use.
- Jonathan M Davis
I have to agree here. I think synchronized classes are of very
little use, especially because they don't "cast away" shared in
a useful way. It still has to be done manually. I think we
should remove them. Synchronized methods should also be removed
in my eyes. Making each and every object bigger by one pointer
just for the sake of a few synchronized methods doesn't seem to
be a good trade off to me. The entire synchronized methods give
the user the feeling that he simply slaps synchronized on his
class / method and then its thread safe and he doesn't have to
care about threads anymore. In the real world this is far from
true however. So synchronized methods and classes just give a
false sense of thread safety and should rather be removed.
I agree that synchronized classes / functions that not that
useful.
But synchronized statements, to me, make the intention of locking
explicit.
Maybe the internal monitor could be removed (with synchronized
classes / functions as well), and allow synchronized() {} to be
called on Lock objects, that essentially locks them at the
beginning and unlocks them at the end.
Re: Non-freeing GC memory management
On Wednesday, 18 November 2015 at 05:49:00 UTC, tcak wrote: On Tuesday, 17 November 2015 at 19:32:05 UTC, Adam D. Ruppe wrote: On Tuesday, 17 November 2015 at 19:27:15 UTC, tcak wrote: As far as I know, GC has a separate thread that stops all other threads periodically to clear the unused memory fields. That is a common misconception... What disadvantages would we have if GC was to be freeing memory only when allocation is requested, and not checking periodically? This is what it actually does now. That means object destructors are to be called only when a new allocation happens? But not all allocations end up with this. If this is so, this behaviour of GC encourages to call destroy (or was it clear?) on objects manually to manage the memory more efficiently. That's correct. But you don't have to do it manually though, as you can always wrap your object inside a Unique!T. http://dlang.org/phobos/std_typecons.html#.Unique
Re: I hate new DUB config format
SDLang is fine. If someone wants to use D, it won't be SDLang that will stop him. Keep calm and use SDLang.
Re: Collections question
On Friday, 27 November 2015 at 20:14:21 UTC, Andrei Alexandrescu wrote: There's this oddity of built-in hash tables: a reference to a non-empty hash table can be copied and then both references refer to the same hash table object. However, if the hash table is null, copying the reference won't track the same object later on. [...] 2, The opCall() one.
Re: Pseudo namespaces
On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu wrote: Nothing. But one thing I was keeping an eye for would be to allow lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei Please don't. Choose one to be the outer and one to be the inner. Otherwise people will sometimes use one, sometimes the other and code will look inconsistent. Just choose one.
Re: Complexity nomenclature
On Friday, 4 December 2015 at 03:46:39 UTC, Walter Bright wrote: On 12/3/2015 5:27 PM, Andrei Alexandrescu wrote: Now this primitive may have three complexities: * linear in the length of r (e.g. c is a singly-linked list) * linear in the number of elements after r in the collection (e.g. c is an array) * constant (c is a doubly-linked list) These complexities must be reflected in the name of the primitives. Or perhaps it's okay to conflate a couple of them. I know names are something we're awfully good at discussing :o). Destroy! Are you sure there are only 3 complexities? What if it's a self-balancing tree? I'm also not sure it is a good idea to put the complexity in the name of the primitive. Do any other algorithm libraries do that? I agree -- putting the complexity (eh, running time) to the primitive's name seems like a bad idea. I believe that stability is a more important "feature" of a sorting algorithm than its running time, because you can make implications about it and use them for your own algorithms (I use it for implementing delta compression) and affects the output. Running time is still a good guarantee to have, but if `sort` runs O(n^2) or O(nlogn) is not going to affect how your output will look like!
Re: Complexity nomenclature
On Friday, 4 December 2015 at 22:48:03 UTC, Andrei Alexandrescu wrote: On 12/04/2015 03:43 PM, Walter Bright wrote: On 12/4/2015 10:49 AM, Dmitry Olshansky wrote: Was vaguely terrified reading this whole thread until hitting this gem. Seems like a creative use for UDA. Yeah, I think it puts UDA on the map! Instead of string arguments, though, I suggest enums. "Even better". http://dpaste.dzfl.pl/50340e189f92 That code is actually remarkably complete, with algebra and remarkable constants. Pretty crazy, yo. Thanks all for the great ideas. D is a remarkable language. Andrei Looks good :)
Re: C++17
On Wednesday, 27 January 2016 at 14:22:18 UTC, Shachar Shemesh wrote: On 26/01/16 11:33, deadalnix wrote: On Tuesday, 26 January 2016 at 09:16:47 UTC, Ola Fosheim Grøstad wrote: [...] Now if one want to use that, D is very capable of doing it already. Just won't make it the default (like it is not the default in C++ either). I bring it up every time the subject comes up, in the hopes that at some point it will sink in. No, D is not capable of doing it already. Without 100% reliable destructors, RAII is simply not implementable. D's destructors are not guaranteed to run on 100% of fully initialized structs, which means that a RAII container has no way to make sure its resource is actually freed. It is up to the implementer. This eradicates almost all of the utility RAII was meant to provide. Shachar Can you show a case where this happens?
Re: D's equivalent to C++'s std::move?
On Wednesday, 3 February 2016 at 18:04:38 UTC, Andrei Alexandrescu wrote: On 02/03/2016 10:05 AM, Sönke Ludwig wrote: For std.move, isn't the only place where an exception can be thrown in the destructor (which shouldn't throw)? It uses memcpy to move the memory around to circumvent any extended construction logic. Destructors in D are allowed to throw (thanks to exception chaining), but now I realize we need to amend that - the destructor of T.init should not be allowed to throw. -- Andrei If this becomes the case, please make destructors nothrow so that people won't screw up (like they can very easily do in C++).
Re: Pitching D to academia
On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote: Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how about pitching it to a gang of professors and graduate students? I will be presenting D to such an audience at METU in Ankara. What are the points that you would stress? I am thinking that they would be interested more in whether D is better as a teaching tool. Do you agree? Ali What about: D can be used as a high level, high productivity scripting language, just like Python, with two exceptions: 1) You get static type checking 2) When can compile the program instead of interpreting when you need the performance. No need to re-write it.
Re: [r/cpp] Why I am not happy with C++17
On Tuesday, 8 March 2016 at 17:31:58 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 8 March 2016 at 15:54:46 UTC, Dmitry Olshansky wrote: This more or less means that we (as in D enthusiasts) have some more time to carve up some "market" share. Till C++20 I guess. Yes, but they got in parallelism ISO/IEC 29124:2010 and file system support. I honestly don't care about those. Boost has them. Modules are far more important for me.
Re: [r/cpp] Why I am not happy with C++17
On Tuesday, 8 March 2016 at 22:53:01 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 8 March 2016 at 18:24:54 UTC, Minas Mina wrote: I honestly don't care about those. Boost has them. Modules are far more important for me. Just found out that Modules weren't supposed to be scheduled for C++17 anyway, but was already meant to be a separate TS. Seems like the C++ standard process will be more continuous than before. Is the modules specification finalized though? As far as I know there were two implementations, clang's and vc++'s.
Re: std.experimental.allocator.make should throw on out-of-memory
On Tuesday, 19 April 2016 at 22:28:27 UTC, Alex Parrill wrote: I'm proposing that std.experimental.allocator.make, as well as its friends, throw an exception when the allocator cannot satisfy a request instead of returning null. [...] I believe it was designed this way so that it can be used in @nogc code, although I might be wrong.
Re: The Case Against Autodecode
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote: On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make length 1? -- Andrei No, this is not the point of normalization. What is? -- Andrei This video will be helpfull :) https://www.youtube.com/watch?v=n0GK-9f4dl8 It talks about Unicode in C++, but also explains how unicode works.
Re: The Case Against Autodecode
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote: On 05/27/2016 03:39 PM, Dmitry Olshansky wrote: On 27-May-2016 21:11, Andrei Alexandrescu wrote: On 5/27/16 10:15 AM, Chris wrote: It has happened to me that characters like "é" return length == 2 Would normalization make length 1? -- Andrei No, this is not the point of normalization. What is? -- Andrei Here is an example about normalization. In Unicode, the grapheme Ä is composed of two code points: A (the ascii A) and the ¨ character. However, one of the goals of unicode was to be backwards to compatible with earlier encodings that extended ASCII (codepages). In some codepages, Ä was an actual codepoint. So in some cases you would have the unicode one which is two codepoints and the one from some codepages which would be one. Those should be the same though, i.e compare the same. In order to do that, there is normalization. What is does is to _expand_ the single codepoint Ä into A + ¨
Re: [OT] fastest fibbonacci
On Sunday, 23 October 2016 at 13:04:30 UTC, Stefam Koch wrote:
Hi Guys,
while brushing up on my C and algorithm skills, accidently
created a version of fibbonaci which I deem to be faster then
the other ones floating around.
It's also more concise
the code is :
int computeFib(int n)
{
int t = 1;
int result = 0;
while(n--)
{
result = t - result;
t = t + result;
}
return result;
}
You can even calculate Fibonacci in O(1).
