Error instantiating std.container.Array
I'm trying to instantiate a std.container.Array of a given class (named Material), by a simple Array!Material _myStuff; I get two compile errors stating the following: C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(85): Error: template std.algorithm.initializeAll cannot deduce function from argument types !()(Material[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1502): std.algorithm.initializeAll(Range)(Range range) if (isInputRange!Range hasLvalueElements!Range hasAssignableElements!Range) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1530): std.algorithm.initializeAll(Range)(Range range) if (is(Range == char[]) || is(Range == wchar[])) C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(825): Error: template std.algorithm.copy cannot deduce function from argument types !()(Range, Range), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(7808): std.algorithm.copy(Range1, Range2)(Range1 source, Range2 target) if (isInputRange!Range1 isOutputRange!(Range2, ElementType!Range1)) Any idea about what might be happening? I can't give a quick minimal example of the code since it is quite complex (and I failed at using dustmite trying to minimize it)
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 14:46:31 UTC, ketmar wrote: On Mon, 02 Mar 2015 14:40:50 +, Francesco Cattoglio wrote: did you tried to dustmite[1] it? [1] https://github.com/CyberShadow/DustMite/wiki I tried to dub dustmite, but it failed with a object.Exception@DustMite\dustmite.d(220): Initial test fails The dustmite version is the one that was bundled with dmd 2.066.1-rc2. I'll update dmd in the mean time, but I have a feeling that this is not related.
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 15:01:55 UTC, Tobias Pankrath wrote:
I'm really clueless... :P
Something is wrong with your Material class, but you'll need to
show us a reduced example.
After a really long time I finally found what was wrong.
http://dpaste.dzfl.pl/16d202b7124d
Wow, I honestly could have NEVER foreseen this.
This is all it takes for a class being unusable in a
std.container.Array
class MyClass
{
void init();
}
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: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 18:52:25 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 13 Jan 2015 18:36:15 + aldanor via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 13 January 2015 at 18:19:42 UTC, ketmar via Digitalmars-d-learn wrote: and then you can go with structures in the first place, i think. remember that you have that k00l `alias this` trick for them! Which doesn't always help in case of multiple inheritance :( e.g. the blasted hdf c++ class hierarchy example. multiple `alias this` may help here... to some extent. ;-) Are they even enabled in dmd already? 2.65 still reports the there can only be one alias this error.
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.
-inline switch changes code behaviour
Today I just realized that in DMD optimize flag does not imply inlining, therefore I promptly added the inline to my dub build settings and recompiler, expecting to see speedups in my code execution. To my surprise, I could not see anything at all: all that I get now is a blank screen. The rendering code uses an old-ish version of gfm-sdl, but I did not find any issue related to compiler swirches. Any idea about what might be happening/any suggestion on how to debug this?
Re: Dutyl - a Vim plugin for running D tools
On Tuesday, 19 August 2014 at 19:03:45 UTC, Idan Arye wrote: Anyways, version 1.0.1 is out with many bugfixes and speedups - including a fix for this problem. I can confirm it works under windows now! Very good job, and thank you for your efforts :)
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote:
GitHub repo: https://github.com/idanarye/vim-dutyl
vim.org page:
http://www.vim.org/scripts/script.php?script_id=5003
Very very nice... So... how does it work?
I added a Bundle idanarye/vim-dutyl to my $MTVIMRC.
I added the following three lines as well
let g:dutyl_stdImportPaths=['C:\D\dmd2\src\phobos']
call dutyl#register#tool('dcd-client','C:/D/DCD/dcd-client')
call dutyl#register#tool('dcd-server','C:/D/DCD/dcd-server')
When I try to do a completion with ctrl-X ctrl-O I get DCD server
to only output some errors:
Cannot cache modules in
C:\some\folder\for\dub\packages\derelict-blabla\ -I
E:\my\project\subfolder because it does not exist
(The folders are in the filesystem, I can confirm they DO exist)
Am I missing something, or should I open an issue at github?
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?
Get the default hash function.
Really simple question:
how do I get the compiler-generated hash function for a given
type?
For example:
Struct S
{
int i;
}
can be used in an associative array. That means the compiler
generates a toHash function. Is there any simple way to call it
directly?
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.
Type deduction on templated constructor.
So, I have this code (also on http://dpaste.dzfl.pl/3f767b17e83c)
This Vector(T) struct is taken from gfm.math.vector.
struct Vector(T) {
T x, y, z;
this(X : T, Y : T, Z : T)(X x_, Y y_, Z z_)
{
x = x_; y = y_; z = z_;
}
}
void main()
{
Vector!ubyte test = Vector!ubyte(1, 1, 1);
}
It fails to compile because template
f508.Vector!ubyte.Vector.__ctor cannot deduce function from
argument types !()(int, int, int).
Note that if one just defines a constructor as this(T x_, T y_, T
z_) everything works.
My question is: should this code compile? I understand that the
literal 1 is int therefore it can screw type deduction, but I
wonder if the compiler should be smart enough to deduce it
correctly.
Re: Type deduction on templated constructor.
On Thursday, 24 July 2014 at 09:38:14 UTC, bearophile wrote: francesco cattoglio: should this code compile? I understand that the literal 1 is int therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly. To keep both the compiler and programmers sane, D templates don't perform implicit type conversions. This sometimes is not handy, but on the whole saves from a large number of troubles. So you can write (D V.2.066): Vector!ubyte(ubyte(1), ubyte(1), ubyte(1)); Or you can create a little helper function that makes that code more DRY. Bye, bearophile I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.
Re: DGui is alive
On Wednesday, 23 July 2014 at 12:58:46 UTC, Gary Willoughby wrote: On Wednesday, 23 July 2014 at 11:40:01 UTC, FrankLike wrote: How about the DGui's status? https://bitbucket.org/dgui/dgui/issues déjà vu
Re: core.exception.InvalidMemoryOperationError
On Friday, 11 July 2014 at 11:43:44 UTC, Joakim wrote: On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio wrote: A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before? If you look at the source for the garbage collector, the only place that error is called is if the gc is trying to malloc or execute other memory operations while the collector is running. I ran across this myself because an assert was getting triggered in a destructor. Since an assert tries to malloc and the destructor is called by the GC, I got an InvalidMemoryOperationError which swallowed up the message from the original assert. By putting printfs in the code path in druntime, I was able to track it down to that destructor, otherwise I had no idea where the invalid memory error was getting triggered. You can probably do the same, but you can be sure it's a GC issue, and I would guess tied to allocating in a destructor (unless you happen to be calling InvalidMemoryOperationErrors somewhere in your own code or some library that you're using, which is unlikely). It's unfortunate that you wrote this only 4 hours ago, because I already spent the morning doing more-or-less the same thing, and finaly realized what was happening and WHO was allocating during a destructor. :o) It's even somewhat told in the docs of core.exception module. What I really don't understand is how the hell was it possible that something managed to either recurse or loop to generate an infinite WOE (Wall Of Exceptions).
core.exception.InvalidMemoryOperationError
A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before?
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 17:08:01 UTC, Olivier Pisano wrote:
No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.
In fact, try to write the following C code:
int main() {
#include stdio.h
[whatever else you want]
}
and look at those lovely error messages from the compiler :P
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 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: 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: 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: 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: how to correctly 'typedef' handle types
http://dlang.org/phobos/std_typecons.html#Typedef Take a look at it. Docs is scarce (pretty sure you will need to take a look around to find something) but it should just do what you need.
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: 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.
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?
Differences between const Type function() and const(Type) function()
Today I got the following compile error:
Cannot implicitly convert expression (blabla) of type
const(Type) to Type
and this is a reduced example ( also on
http://dpaste.dzfl.pl/f2f3bd921989):
module test;
import std.stdio;
class Foo {
int i = 42;
}
class MyClass {
private { Foo _Q; }
this() {_Q = new Foo;}
Foo getQ () { return _Q; }
const (Foo) getQ () const { return _Q; } // OK
// const Foo getQ () const { return _Q; } // fails
}
void main() {
const MyClass instance = new MyClass;
writeln(instance.getQ.i);
}
I don't really understand what's going on here. Why is const Foo
getQ() wrong?
And why is const(Foo) getQ so much different? (e.g: this is an
explicit cast, right? Is there anything that might go wrong?)
Re: Differences between const Type function() and const(Type) function()
On Friday, 30 May 2014 at 12:57:52 UTC, anonymous wrote: And why is const(Foo) getQ so much different? (e.g: this is an explicit cast, right? Is there anything that might go wrong?) It's not a cast. It's the unambiguous notation for a qualified type. Often you can omit the parentheses. With methods you cannot. With methods you need the parentheses to let the compiler know that you indeed mean the return type to be const, not the method itself. Ouch... I even wonder why I wrote about is this a cast?... Noob mistake! :P Anyway thank you everyone, I really thought the two way of writing were equivalent. (it's C++ fault, not mine! I tell you!)
Re: Programming a Game in D? :D
On Wednesday, 28 May 2014 at 17:46:23 UTC, David wrote: Ok, now I just wonder wich Engine. (I know everybody hates the discussion about the best engine.) CryEngine, UDK, Unity or a less known Engine? I'll be honest, perhaps I risk being misunderstood, but the questions you are asking denote a lack of even basic knowledge about the subject, so I really think you should do some good amount of research before even trying to write something on your own. Have you tried at least some free tools that allow you to script stuff and have simple stuff displayed on screen? I'm talking about stuff like Construct 2, GameMaker, RPGMaker, zGameEditor... even map editors like the ones from Blizzard (WarCraft 3 : TFT or StarCraft 2)?
Re: Programming a Game in D? :D
On Thursday, 22 May 2014 at 15:48:50 UTC, John Colvin wrote: On Thursday, 22 May 2014 at 15:39:36 UTC, David wrote: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D There are quite a few game related libs on code.dlang.org that you can take a look at. Also see some of the recent D.announce posts. Yep. Start by learning dub (code.dlang.org), which is a build automation tool that helps you alot by saving headaches caused by the heap of dependencies that a complex software like a game has. Don't start by diving into graphics just yet, spend your first days by doing stuff on the command line. There are a few engines that are being developed by others, but there's nothing like e.g. Unity right now. I think that every engine is in early development stage, too. Also, I think most of current libraries use OpenGL instead of DirectX, so you might want to learn that (at least the basics).
Re: Scalar + array operations
On Wednesday, 21 May 2014 at 13:52:47 UTC, John Colvin wrote: On Wednesday, 21 May 2014 at 11:45:57 UTC, Stefan Frijters wrote: I would have expected the last case to work as well, but I get testarr.d(20): Error: incompatible types for ((dfoo) * (ibar[])): 'double' and 'int[]' Is this by design? It was very surprising to me, especially since all other combinations do seem to work. Kind regards, Stefan Frijters Please file a bug, there's no reason for that not to work, it just needs to be implemented properly. To me, it just feels reasonable that it is not allowed. What should be the correct type of the result? int[]? I thought double to int conversion was not allowed unless you explicitly asked for it.
Re: Templating everything? One module per function/struct/class/etc, grouped by package?
On Monday, 12 May 2014 at 08:37:43 UTC, JR wrote: What am I missing? Error messages! If your code is not compiled, you can't know whether it is valid or not. I must say that since we have unittests, this is somewhat less relevant, but still... One nice thing would be stripping the executable of unneeded code. One trick I've seen done in a program which compiled some scripts to an intermediate language was zeroing the parts which are unused, then use some executable compressor.
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 ;)
