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
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):
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
On Monday, 2 March 2015 at 15:57:10 UTC, Tobias Pankrath wrote:
Please file a bug report.
Will do!
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
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
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
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
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
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
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?
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
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
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 :)
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
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.
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
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?
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
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
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
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()
{
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
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
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
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
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,
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
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.
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
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
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
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
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.
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
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
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.
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 {
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
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
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
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
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
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.
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++
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,
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
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
48 matches
Mail list logo