Re: Cannot instantiate a std.container.Array of a class with a init() function member.
On Monday, 2 March 2015 at 15:57:10 UTC, Tobias Pankrath wrote: Please file a bug report. Will do!
Cannot instantiate a std.container.Array of a class with a init() function member.
Taken from http://forum.dlang.org/thread/gjrbmskictrbcyedu...@forum.dlang.org trying to instantiate an Array!MyClass fails with a rather obscure error message if the MyClass has a member function "void init()": http://dpaste.dzfl.pl/16d202b7124d Is this a std library bug, or should this be considered a mistake on the library user side to name a member function "init"?
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. - Jonathan M Davis At this point, it might be nicer to have only attributes that exists as C++ keywords not having the @ identifier before them. That is: public, protected, private, override, deprecated, static and const. But this probably doesn't make much sense now, does it?
Re: What's missing to make D2 feature complete?
On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote: On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. For me it's these 3 points. - tuple support (DIP32, maybe without pattern matching) - working import, protection and visibility rules (DIP22, 313, 314) - finishing non-GC memory management Unique! and RefCounted! in a usable state. +1 No RefCounted classes and non-reentrant GC makes it really awkward to write libraries that handle non-memory resources in a nice way. My experience with (old versions of) GFM has been horrible at times: you have to close() everything by yourself, if you forget about that sooner or later the GC will collect something, proc a call to close(), which in turns procs a call to the logger, which will end up with a InvalidMemoryOperationError. Not being able to allocate during ~this() can be extremely annoying for me.
Re: OT: Minecraft death by GC
On Tuesday, 21 October 2014 at 16:08:41 UTC, Israel wrote: On Tuesday, 21 October 2014 at 15:23:11 UTC, David Gileadi wrote: On 10/21/14, 2:47 AM, monarch_dodra wrote: Hurp, I wonder why GC issues only appear with application that use a GC. Hurp-a-durp. Also, the issue of memory leak and core dumps seem to only appear when you use a systems language. How crazy is that? Happily with a little work D allows you to have both! :) Im curious, will D be one of the first languages to have the ability to use a GC and not use one? More likely: to give you the ability to shoot yourself in the foot both with a GC and without it. ;)
Re: [OT] How Blue Byte made Might & Magic Heroes Online in Flash
On Sunday, 19 October 2014 at 21:16:14 UTC, Paulo Pinto wrote: Since the topic of games and GC is a big one, maybe it is interesting to read about how Blue Byte decided to make Might & Magic Heroes Online in Flash and their opinion from the point of view of a C++ AAA studio on the whole development experience. The only real GC-related thing coming out of this seems to be the usual one: Java GC is fast enough for a MMO backend, probably just because it's Java. The new extra lesson is that anything can work just fine for a Hardware-Accelerated frontend :P
Re: UFCS in C++
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote: Looks like Bjarne has proposed UFCS for C++ http://isocpp.org/files/papers/N4174.pdf No mention of D though... Seriously, not even a mention? Ok, I'm mad. Can I be mad?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote: Kenji just proposed a slightly controversial pull request so I want to reach out for more people to discuss it's tradeoffs. It's about deprecating function qualifiers on the left hand side of a function. I'm all for it Then at some future point we could apply the left hand side qualifiers to the return type, e.g. `const int foo();` == `const(int) foo();` I know it's not happening anytime soon, but I'm against this second idea. This will be an extra annoyance when "porting" old D code to a new version. Just removing the currently ambiguous attribute on the left should be plenty. No need to try to mimic C in this regard.
Re: const int vs. int const
On Saturday, 16 August 2014 at 21:42:59 UTC, Jonathan M Davis wrote: On Saturday, 16 August 2014 at 18:50:08 UTC, Jacob Carlborg wrote: On 2014-08-16 01:33, Mike wrote: Sounds like a worthwhile impromement to me. Sounds like a breaking change to me. Which will include the usual complains. Yes, but it's either that or have people running into this problem and complaining about it and the bugs that it causes for years to come. And it's _already_ bad practice to put const, immutable, inout, or shared on the left-hand side without parens, and pretty much everyone has run into the problem at one time or another when trying to return const from a function and would know to avoid putting those atributes on the left. So, the vast majority of code wouldn't be affected. And of course, we'd do it via deprecation, so it wouldn't immediately break code. For what it is worth, I can confirm this bit me and a coworker of mine. Deprecation of this makes sense. IIRC there's a bunch of C valid code that are rejected by dmd because the semantic is different. This seems to be one of those cases.
Re: C++ template name mangling
On Friday, 15 August 2014 at 19:53:28 UTC, Walter Bright wrote: Currently, D supports: 1. C++ function name mangling 2. C++ namespace name mangling 3. C++ class field and vtbl[] layout 4. C++ function calling conventions But what is missing is name mangling to match C++ templates. This makes it awkward and tedious to construct a D interface to a C++ template. Andrei has proposed that D support, for templates declared within an extern(C++) block, C++ name mangling. This should not be difficult, it should not break any existing D source code, and will enable limited interaction with C++ templates from D. One nice side benefit is that no other language offers such support, and given the increasing ubiquity of C++ template use, it would give us a nice leg up. Do different C++ compilers even mangle template names in the same way? I remember function and classes mangling being almost standard nowadays, does this apply to templates, too? Sure this would add to the "Cool things you can do in D"; do you have any estimate of the amount of work needed/target release?
Re: Voting: std.logger
On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote: 1) Yes / No for inclusion into std.experimental Yes, absolutely. 2) Yes / No for inclusion into Phobos in its current state Not yet. 3) If you have answered "No" for (2) : list of mandatory changes that are needed to make you vote "Yes" As far as I undestood, there's no way right now to do logging without using the GC. And that means it is currently impossible to log inside destructor calls. That is a blocker in my book. 4) Any additional comments for author. No matter the changes that might be applied to reduce suffix notation, I would love to retain the ability to do conditional unformatted logging.
Re: Open source Windows debugger
On Sunday, 27 July 2014 at 20:39:53 UTC, Vladimir Panteleev wrote: On Sunday, 27 July 2014 at 19:07:14 UTC, Walter Bright wrote: http://x64dbg.com/#start Anyone want to give this a whirl? It looks like an open-source clone of OllyDbg. Looking at the advertised features, it seems to be aimed at reverse engineering, as I see no mention of source-level debugging, or any supported debug information formats. I'd guess that it would not be great at debugging your own programs. Yep, I have to agree. Or well, probably it's good enough for Walter, but I would be utterly unable to debug even 50 lines of code with that :-P
Re: Review: std.logger
On Friday, 25 July 2014 at 07:11:06 UTC, Jacob Carlborg wrote: On 22/07/14 11:43, ponce wrote: NullLogger is there precisely because it's trivial and needed. If it's so trivial then the users can implement that themselves. A standard library isn't about implementing what's trivial, it's about implementing what's most useful to most people. http://dlang.org/phobos/std_math.html#.fmin "fmin" is trivial as well, is not used all the time, yet is in the standard library. Sometime trivial stuff is still good to have.
Bug or Feature? compile error: to!string(const Object)
I found out today that the following code won't compile:
import std.conv;
class MyClass {}
void doStuffKo(const MyClass instance)
{
string temp = to!(string)(instance);
}
Everything compiles fine if I remove the const from the function
signature.
I found out this issue named in earlier threads but I could not
find any bug about it on the issue tracker. Is this a bug, a
missing feature, or is this something that is almost impossible
to achieve and therefore not implemented on purpose?
Re: std.math performance (SSE vs. real)
On Sunday, 29 June 2014 at 00:22:02 UTC, Walter Bright wrote: On 6/28/2014 4:27 AM, francesco cattoglio wrote: We are talking about paying a price when you don't need it. More than that - the suggestion has come up here (and comes up repeatedly) to completely remove support for 80 bits. Heck, Microsoft has done so with VC++ and even once attempted to completely remove it from 64 bit Windows (I talked them out of it, you can thank me!). Then I must have missed the post. Removing 80 bit support would sound like madness to my ears. And about that Microsoft thing, thanks a lot :o)
Re: std.math performance (SSE vs. real)
On Saturday, 28 June 2014 at 10:42:19 UTC, Walter Bright wrote: On 6/28/2014 2:47 AM, francesco cattoglio wrote: I have experience doing numerical work? Upgrading the precision is the first thing people try. Brute force is always the first thing people try :o) It happens with both numerical integration and inverting matrices. Inverting matrices is commonplace for solving N equations with N unknowns. Errors accumulate very rapidly and easily overwhelm the significance of the answer. And that's exactly the reason you change approach instead of getting greater precision: the "adding precision" approach scales horribly, at least in my field of study, which is solving numerical PDEs. (BTW: no sane person inverts matrices) Getting the wrong answer quickly is not useful when you're calculating the stress levels in a part. We are talking about paying a price when you don't need it. With the correct approach, solving numerical problems with double precision floats yelds perfectly fine results. And it is, in fact, commonplace. Again, I've not read yet a research paper in which it was clearly stated that 64bit floats were not good enough for solving a whole class of PDE problem. I'm not saying that real is useless, quite the opposite: I love the idea of having an extra tool when the need arises. I think the focus should be about not paying a price for what you don't use
Re: std.math performance (SSE vs. real)
On Saturday, 28 June 2014 at 09:07:17 UTC, John Colvin wrote: On Saturday, 28 June 2014 at 06:16:51 UTC, Walter Bright wrote: On 6/27/2014 10:18 PM, Walter Bright wrote: On 6/27/2014 4:10 AM, John Colvin wrote: *The number of algorithms that are both numerically stable/correct and benefit significantly from > 64bit doubles is very small. To be blunt, baloney. I ran into these problems ALL THE TIME when doing professional numerical work. Sorry for being so abrupt. FP is important to me - it's not just about performance, it's also about accuracy. When you need accuracy, 999 times out of 1000 you change the numerical technique, you don't just blindly upgrade the precision. The only real reason one would use 80 bits is when there is an actual need of adding values which differ for more than 16 orders of magnitude. And I've never seen this happen in any numerical paper I've read. I still maintain that the need for the precision of 80bit reals is a niche demand. Its a very important niche, but it doesn't justify having its relatively extreme requirements be the default. Someone writing a matrix inversion has only themselves to blame if they don't know plenty of numerical analysis and look very carefully at the specifications of all operations they are using. Couldn't agree more. 80 bit IS a niche, which is really nice to have, but shouldn't be the standard if we lose on performance. Paying the cost of moving to/from the fpu, missing out on increasingly large SIMD units, these make everyone pay the price. Especially the numerical analysts themselves will pay that price. 64 bit HAS to be as fast as possible, if you want to be competitive when it comes to any kind of numerical work.
Re: DIP64: Attribute Cleanup
On Saturday, 21 June 2014 at 20:48:41 UTC, Brian Schott wrote: I think the proposal said that the type constructors would be exempt, You wouldn't have @const but you would have @final. I think you needed to underline this part better. This is indeed extremely important, and that is the reason for people complaining about your DIP being only "just moving inconsistencies around"
Re: DIP64: Attribute Cleanup
On Saturday, 21 June 2014 at 18:07:25 UTC, Temtaime wrote: And it's C++ that shows that almost all of D attributes are not necessary. How so? Anyway, I totally agree that attributes NEED cleanup, it really makes zero sense to have some without "@" annotation. Really, keep Scott's talk in mind! :P About code breakage: a sane deprecation path and an automated tool to make the code up-to-date will make sure there is zero discomfort for D users. The alias for the @attribute set seems a very nice syntax to me.
Re: Internal linkage - equivalent of C++ global static and anonymous namespaces
On Thursday, 12 June 2014 at 09:48:30 UTC, Kagamin wrote: Why private members can't have internal linkage? There has been some discussion about a few corner cases, see http://forum.dlang.org/thread/jlbsreudrapysiaet...@forum.dlang.org?page=2#post-irrbdrxordjawkryvrub:40forum.dlang.org and following posts.
Internal linkage - equivalent of C++ global static and anonymous namespaces
Yesterday I discovered that a global static variable in D is just a global variable, with no special rule about symbol visibility and such. I've scrolled quickly through old discussions on the NG and read the relevant DIP: http://wiki.dlang.org/DIP22 It seems to me that nobody thought about reusing the module keyword for declaring symbols with internal linkage. It would look like: file foo.d: module foo; // module declaration module uint cantSeeMe; // internal linkage attribute, hidden symbol private uint can_See_Me; // private, but symbol still visible AFAIK, module keyword right now is only used for module declaration, and is not valid anywhere else. Would it make sense to use it in this context, too?
Re: D Language Version 3
On Friday, 30 May 2014 at 06:14:15 UTC, Jonathan M Davis via Digitalmars-d wrote: Yeah, sorry about that. The web interface that I'm forced to use for e-mail when I'm at work just got changed, and it screwed with my settings - and clearly in a very nasty way. It should be fixed now though. - Jonathan M Davis Perhaps it is fixed, but on the web forum still there's nothing to be seen. What was it about? Something serious or some joke/semiserious stuff?
Re: More radical ideas about gc and reference counting
On Sunday, 11 May 2014 at 22:06:55 UTC, Francesco Cattoglio wrote: On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of "@", it's mostly "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all. Similarly in current C++ std::shared_ptr is barely there while std::unique_ptr is all over the place. I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use. sorry, my bad, I read it reversed :D
Re: More radical ideas about gc and reference counting
On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of "@", it's mostly "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they are not using it at all. Similarly in current C++ std::shared_ptr is barely there while std::unique_ptr is all over the place. I guess that after burning their fingers with auto_ptr, people still have to realize that unique_ptr might be good to use.
Re: More radical ideas about gc and reference counting
On Saturday, 10 May 2014 at 07:08:04 UTC, Andrei Alexandrescu
wrote:
On 5/9/14, 11:27 PM, Manu via Digitalmars-d wrote:
ARC overhead would have no meaningful impact on performance,
GC may
potentially freeze execution. I am certain I would never
notice ARC
overhead on a profiler, and if I did, there are very simple
methods to
shift it elsewhere in the few specific circumstances it
emerges.
This is very, very, very wrong. -- Andrei
I've seen this discussion ("it's almost performance-free", "it's
a performance killer") so many times, I can't even say who has
the burden of proof anymore.
Re: More radical ideas about gc and reference counting
On Friday, 9 May 2014 at 21:05:18 UTC, Wyatt wrote: But conversely, Manu, something has been bothering me: aren't you restricted from using most libraries anyway, even in C++? "Decent" or "acceptable" performance isn't anywhere near "maximum", so shouldn't any library code that allocates in any language be equally suspect? So from that standpoint, isn't any library you use in any language going to _also_ be tuned for performance in the hot path? Maybe I'm barking up the wrong tree, but I don't recall seeing this point addressed. More generally, I feel like we're collectively missing some important context: What are you _doing_ in your 16.6ms timeslice? I know _I'd_ appreciate a real example of what you're dealing with without any hyperbole. What actually _must_ be done in that timeframe? Why must collection run inside that window? What must be collected when it runs in that situation? (Serious questions.) I'll try to guess: if you want something running at 60 Frames per Second, 16.6ms is the time you have to do everything between frames. This means that in that timeframe you have to: -update your game state. -possibly process all network I/O. -prepare the rendering pipeline for the next frame. Updating the game state can imply make computations on lots of stuff: physics, animations, creation and deletion of entities and particles, AI logic... pick your poison. At every frame you will have an handful of objects being destroyed and a few resources that might go forgotten. One frame would probably only need very little objects collected. But given some times the amount of junk can grow out of control easily. Your code will end up stuttering at some point (because of random collections at random times), and this can be really bad.
Re: DIP60: @nogc attribute
On Tuesday, 15 April 2014 at 19:57:59 UTC, monarch_dodra wrote: I have an issue related to adding an extra attribute: Attributes of non-template functions. Currently, you have to mark most functions as already pure, nothrow and @safe. If we are adding another attribute. Code will start looking alike this: int someTrivialFunction(int i) @safe pure nothrow @nogc; don't forget final ;)
