On 6/26/2014 2:26 PM, Brian Schott wrote:
https://github.com/economicmodeling
Stuff that's been made available:
* D implementation of the DDoc macro processor
* Documentation generator that doesn't need the compiler
- No more requirement to use all the -I options to just get docs.
-
On 06/27/2014 09:16 AM, Walter Bright via Digitalmars-d-announce wrote:
On 6/26/2014 2:26 PM, Brian Schott wrote:
https://github.com/economicmodeling
Stuff that's been made available:
* D implementation of the DDoc macro processor
* Documentation generator that doesn't need the compiler
On 2014-06-26 23:26, Brian Schott wrote:
* Documentation generator that doesn't need the compiler
Do you have any example of documentation generated with this tool?
--
/Jacob Carlborg
On Thursday, 26 June 2014 at 21:26:55 UTC, Brian Schott wrote:
* Documentation generator that doesn't need the compiler
How does it relate to ddox?
http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/
https://twitter.com/D_Programming/status/482546357690187776
https://news.ycombinator.com/newest
https://www.facebook.com/dlang.org/posts/874091959271153
Andrei
http://youtu.be/TNvUIWFy02I
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d#L72
Does this work? You try to remove new range instead of old one.
Also you should remove old range only after you added new range,
so that GC won't catch you in the middle.
And then it will still be able to catch you between realloc and
addRange.
On 6/27/2014 12:53 PM, Dicebot wrote:
http://youtu.be/TNvUIWFy02I
Ack, need to work on my posture :-(
On Friday, 27 June 2014 at 20:33:22 UTC, Kagamin wrote:
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d#L72
Does this work? You try to remove new range instead of old one.
Also you should remove old range only after you added new
range, so that GC
On Friday, 27 June 2014 at 12:31:09 UTC, Dicebot wrote:
On Thursday, 26 June 2014 at 21:26:55 UTC, Brian Schott wrote:
* Documentation generator that doesn't need the compiler
How does it relate to ddox?
DDOX uses the compiler's JSON output. This new documentation
generator only looks at
I have two questions that I've come upon lately:
1) How was it decided that there should be implicit conversion
between signed and unsigned integers in arithmetic operations,
and why prefer unsigned numbers?
E.g. Signed / Unsigned = Unsigned
Is this simply compatibility with C or is there
On Friday, 27 June 2014 at 23:30:39 UTC, safety0ff wrote:
2) With regard to reducing template instantiations:
I've been using a technique similar to the one mentioned in the
video: separating functions out of templates to reduce bloat.
My question is: does a template such as:
T foo(T)(T x)
if
On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander wrote:
On Friday, 27 June 2014 at 23:30:39 UTC, safety0ff wrote:
2) With regard to reducing template instantiations:
I've been using a technique similar to the one mentioned in
the video: separating functions out of templates to reduce
On Saturday, 28 June 2014 at 02:46:25 UTC, safety0ff wrote:
On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander
int a;
const int b;
immutable int c;
foo(a);
foo(b);
foo(c);
These all call foo!int
Awesome, thanks!
... I just tried this and I'm wrong. The qualifier isn't
stripped.
On Saturday, 28 June 2014 at 03:33:37 UTC, Peter Alexander wrote:
... I just tried this and I'm wrong. The qualifier isn't
stripped. Gah! Three different versions!
I could have sworn D did this for primitive types. This makes
me sad :-(
I guess you can make all kinds of code that depends
On 27 June 2014 02:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause a huge
performance problem in typical floating point graphics code. An instance of
this has recently been discussed here in the
On 27 June 2014 07:14, Iain Buclaw ibuc...@gdcproject.org wrote:
On 27 June 2014 02:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause a huge
performance problem in typical floating point graphics
On 2014-06-26 02:41, Walter Bright wrote:
I suggest that your issues with global variables can be mitigated by
adopting a distinct naming convention for your globals. Frankly, I think
a global variable named x is execrable style - such short names should
be reserved for locals.
No need to
On 2014-06-27 03:16, Nick Sabalausky wrote:
There's other times I've had to get by without debuggers too. Like, in
the earlier days of web dev, it was common to not have a debugger. Or
debugging JS problems that only manifested on Safari (I assume Safari
probably has JS diagnostics/debugging
On 2014-06-27 00:57, Sean Kelly wrote:
Yep. A lot of this is probably because as a server programmer
I've just gotten used to finding bugs this way as a matter of
necessity, but in many cases I actually prefer it to interactive
debugging. For example, build core.demangle with -debug=trace
and
Am 26.06.2014 02:41, schrieb Walter Bright:
On 6/25/2014 4:03 PM, bearophile wrote:
The simplest way to avoid that kind of bugs is give a shadowing global x error
(similar to the shadowing errors D gives with foreach and with statements). But
this breaks most existing D code.
D has scoped
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection to local scopes.
sweet does not mean - use a better name or .x to avoid manualy hard to
detect problems - its like disabled shadow detection in local scopes
what i don't
On 27 June 2014 11:16, Nick Sabalausky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 6/26/2014 7:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 10:57:28PM +, Sean Kelly via Digitalmars-d
wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky
On 26/06/2014 9:15 PM, Wyatt wrote:
I'll first admit I'm not fond of the font. I do agree with a sans serif
with fairly thick stroke, but I don't like the vertical stress and I
think a wider counter definitely looks better with these proportions.
What's the font in the current logo?
I don't
On Friday, 27 June 2014 at 06:48:44 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 27 June 2014 07:14, Iain Buclaw ibuc...@gdcproject.org
wrote:
On 27 June 2014 02:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math
On Thursday, 26 June 2014 at 21:20:04 UTC, Joakim wrote:
On Thursday, 26 June 2014 at 17:52:13 UTC, Nick Sabalausky
wrote:
On 6/26/2014 7:02 AM, Shammah Chancellor wrote:
I've increased the bounty on this bug. Fast CTFE is very
important.
On 26/06/2014 9:34 PM, H. S. Teoh via Digitalmars-d wrote:
Of all these, I find that I like the bottom right one the most.
I divided the options into left and right based on the emotion that I
felt the angle of the shadow on the moon suggested, the left side are
the ones that I felt were
On Friday, 27 June 2014 at 09:42:22 UTC, Don wrote:
Yes, of course I'm not interested in bounties. But note that
that issue is not really a bug, it's a project.
I put hundreds of hours of work into this, to get to the point
where we are now - fixing the compiler structure to the point
where
On Thursday, 26 June 2014 at 08:15:35 UTC, Alix Pexton wrote:
Perhaps just a subtle clean up then?
https://drive.google.com/file/d/0B3i8FWPuOpryTjFybHNYYVVtc1k/edit
A...
I personally like the current one:
- I like how mars looks like its a reflection in the logo's
background.
- I dislike
On Friday, 27 June 2014 at 09:37:54 UTC, hane wrote:
On Friday, 27 June 2014 at 06:48:44 UTC, Iain Buclaw via
Digitalmars-d wrote:
Can you test with this?
https://github.com/D-Programming-Language/phobos/pull/2274
Float and Double implementations of floor/ceil are trivial and
I can add
On 27 June 2014 11:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause a huge
performance problem in typical floating point graphics code. An instance of
this has recently been discussed here in the
On Friday, 27 June 2014 at 09:37:54 UTC, hane wrote:
Nice! I tested with the Perlin noise benchmark, and it got
faster(in my environment, 1.030s - 0.848s).
But floor still consumes almost half of the execution time.
Oh, and by the way, my optimized version (simply replace floor()
in
On Friday, 27 June 2014 at 10:51:05 UTC, Manu via Digitalmars-d
wrote:
On 27 June 2014 11:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause a
huge
performance problem in typical floating point graphics
On Friday, 27 June 2014 at 11:10:57 UTC, John Colvin wrote:
On Friday, 27 June 2014 at 10:51:05 UTC, Manu via Digitalmars-d
wrote:
On 27 June 2014 11:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause
On Fri, 2014-06-27 at 11:10 +, John Colvin via Digitalmars-d wrote:
[…]
I understand why the current situation exists. In 2000 x87 was
the standard and the 80bit precision came for free.
Real programmers have been using 128-bit floating point for decades. All
this namby-pamby 80-bit stuff
On 27 June 2014 11:47, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 27 June 2014 at 09:37:54 UTC, hane wrote:
On Friday, 27 June 2014 at 06:48:44 UTC, Iain Buclaw via Digitalmars-d
wrote:
Can you test with this?
On Friday, 27 June 2014 at 02:11:50 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can
even do
printf at all, let alone a debugger. I've had to debug with
Am 27.06.2014 14:20, schrieb Russel Winder via Digitalmars-d:
On Fri, 2014-06-27 at 11:10 +, John Colvin via Digitalmars-d wrote:
[âŠ]
I understand why the current situation exists. In 2000 x87 was
the standard and the 80bit precision came for free.
Real programmers have been using
On Friday, 27 June 2014 at 13:04:31 UTC, dennis luehring wrote:
Am 27.06.2014 14:20, schrieb Russel Winder via Digitalmars-d:
On Fri, 2014-06-27 at 11:10 +, John Colvin via
Digitalmars-d wrote:
[âŠ]
I understand why the current situation exists. In 2000 x87 was
the standard and the 80bit
On 06/27/2014 03:04 PM, dennis luehring wrote:
Am 27.06.2014 14:20, schrieb Russel Winder via Digitalmars-d:
On Fri, 2014-06-27 at 11:10 +, John Colvin via Digitalmars-d wrote:
[âŠ]
I understand why the current situation exists. In 2000 x87 was
the standard and the 80bit precision came
On 27 June 2014 14:24, Element 126 via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 06/27/2014 03:04 PM, dennis luehring wrote:
Am 27.06.2014 14:20, schrieb Russel Winder via Digitalmars-d:
On Fri, 2014-06-27 at 11:10 +, John Colvin via Digitalmars-d wrote:
[ ]
I understand
On 27 June 2014 07:48, Iain Buclaw ibuc...@gdcproject.org wrote:
On 27 June 2014 07:14, Iain Buclaw ibuc...@gdcproject.org wrote:
On 27 June 2014 02:31, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Hi all,
right now, the use of std.math over core.stdc.math can cause a
On Friday, 27 June 2014 at 13:50:29 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 27 June 2014 14:24, Element 126 via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 06/27/2014 03:04 PM, dennis luehring wrote:
Am 27.06.2014 14:20, schrieb Russel Winder via Digitalmars-d:
On Fri,
On 27 June 2014 10:42, Don via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I doubt bounties are effective as a motivation for this kind of thing.
+1
That's a pretty big bounty though. I bet it would be motivating for
the jobless. :P
On 6/27/14, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 27 June 2014 10:42, Don via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I doubt bounties are effective as a motivation for
On 2014-06-27 5:53 AM, safety0ff wrote:
Perhaps the bounty won't stimulate anybody who doesn't have other
motivations to improve the situation, but more information about the
scope of the issue would be helpful to both backers and potential
claimants.
From what I've seen writing an ASN.1
On 6/27/14, 8:54 AM, Andrej Mitrovic via Digitalmars-d wrote:
That's a pretty big bounty though. I bet it would be motivating for
the jobless. :P
On 6/27/14, Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 27 June 2014 10:42, Don via Digitalmars-d
On 2014-06-26 16:37, H. S. Teoh via Digitalmars-d wrote:
This is probably because without -D, the entire ddoc code doesn't even
run (which probably saves on compilation time), and comments are not
kept by the parser/lexer, so by the time the compiler evaluates
__traits(comment...), it doesn't
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection
to local scopes.
sweet does not mean - use a better name or .x to avoid manualy
hard to detect problems - its like
On Friday, 27 June 2014 at 14:50:14 UTC, Kai Nacke wrote:
The doubledouble type is available for PowerPC. In fact, I try
to use this for my PowerPC64 port of LDC. The partial support
here is a bit annoying but I did not find the time to implement
the missing functions myself.
It is native in
I searched the internet, somehow sending documents (txt) to the
printer, but not found, how can I do to send TXT files to the
printer using the D language?
http://msdn.microsoft.com/en-us/library/windows/desktop/dd162859%28v=vs.85%29.aspx
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
I agree, but that's what they're called in the compiler source
code, so
it's kinda hard to call them something else.
Most people never look in compiler source code so lets pretend it
does not exist ;)
I think, make real==double on x86-64, like on other
architectures, because double is the way to go.
On Fri, Jun 27, 2014 at 06:32:34PM +, Dicebot via Digitalmars-d wrote:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via Digitalmars-d wrote:
I agree, but that's what they're called in the compiler source code,
so it's kinda hard to call them something else.
Most people never look
On Friday, 27 June 2014 at 19:11:45 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jun 27, 2014 at 06:32:34PM +, Dicebot via
Digitalmars-d wrote:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
I agree, but that's what they're called in the compiler
source
On 6/26/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can even do
printf at all, let alone a debugger. I've had to debug with as little
as one
On Thursday, 26 June 2014 at 10:38:54 UTC, bearophile wrot
https://github.com/D-Programming-Language/dmd/pull/3615
Will allow very handy, more DRY and less bug-prone like this:
// static array type
int[$] a1 = [1,2];// int[2]
auto[$] a2 = [3,4,5]; // int[3]
const[$] a3 = [6,7,8]; //
On Fri, Jun 27, 2014 at 03:36:08PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 6/26/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or better any) variable at all?
It can be useful if you are using mixins where you don't know
what is going to be in the destination scope.
On 6/27/2014 1:38 PM, Tofu Ninja wrote:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to shadow a(or
better any) variable at all?
It can be useful if you are using mixins where you don't know what is going to
be in
On 06/27/2014 08:19 PM, Kagamin wrote:
On Friday, 27 June 2014 at 14:50:14 UTC, Kai Nacke wrote:
The doubledouble type is available for PowerPC. In fact, I try to use
this for my PowerPC64 port of LDC. The partial support here is a bit
annoying but I did not find the time to implement the
If I have a variable whose static type is an interface and I call
typeid on it, I get the interface back, not the dynamic type.
This seems like confusing behavior. Is this the intended result?
I recognize that one needs some amount of state to perform the
dynamic type lookup, and so it is on
On Friday, 27 June 2014 at 20:40:24 UTC, Walter Bright wrote:
On 6/27/2014 1:38 PM, Tofu Ninja wrote:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or
better any) variable at all?
It can be useful if
I like DIP54 and I think the work on fixing tuples is awesome,
but I have 1 nit-picky question: why is it called
TemplateArgumentList when it's not always used as template
arguments?
void func(string, string) { }
TypeTuple!(string, string) var;
var[0] = I'm nobody's ;
var[1] =
On Thursday, June 26, 2014 17:45:23 Meta via Digitalmars-d wrote:
On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
Meta:
There has been discussion before about doing away with string
lambdas. Maybe this is a good time to do that.
If they get deprecated I will have to
On Fri, Jun 27, 2014 at 03:24:36PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
On Thursday, June 26, 2014 17:45:23 Meta via Digitalmars-d wrote:
On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
Meta:
There has been discussion before about doing away with string
On Friday, 27 June 2014 at 22:31:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
I don't know if any further progress has been made since then,
though.
I've yet to see a pull request for it, so I'd assume that there
hasn't.
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
StaticList/ExpandingList/StaticTuple/ExpandingTuple?
I think StaticList is the clearest, really makes it obvious what
it is.
Am 27.06.2014 22:38, schrieb Tofu Ninja:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
what i don't understand - why on earth should someone want to
shadow a(or better any) variable at all?
It can be useful if you are using mixins where you don't know
what is going to be in
Am 27.06.2014 20:09, schrieb Kapps:
On Friday, 27 June 2014 at 08:24:16 UTC, dennis luehring wrote:
Am 27.06.2014 10:20, schrieb dennis luehring:
I
think we hit the sweet spot at restricting shadowing detection
to local scopes.
sweet does not mean - use a better name or .x to avoid manualy
On Saturday, 28 June 2014 at 03:01:12 UTC, Tofu Ninja wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
StaticList/ExpandingList/StaticTuple/ExpandingTuple?
I think StaticList is the clearest, really makes it obvious
what it is.
Static already mean everything, please no.
On Sat, Jun 28, 2014 at 06:37:08AM +0200, dennis luehring via Digitalmars-d
wrote:
Am 27.06.2014 20:09, schrieb Kapps:
[...]
struct Foo {
int a;
this(int a) {
this.a = a;
}
}
forgot that case - but i don't like how its currently handled, maybe
no
On Sat, Jun 28, 2014 at 05:00:09AM +, deadalnix via Digitalmars-d wrote:
On Saturday, 28 June 2014 at 03:01:12 UTC, Tofu Ninja wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
StaticList/ExpandingList/StaticTuple/ExpandingTuple?
I think StaticList is the clearest,
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.
On 6/27/2014 3:50 AM, Manu via Digitalmars-d wrote:
Totally agree.
Maintaining commitment to deprecated hardware which could be removed
from the silicone at any time is a bit of a problem looking forwards.
Regardless of the decision about whether overloads are created, at
very least, I'd suggest
On 6/27/2014 11:47 AM, Kagamin wrote:
I think, make real==double on x86-64, like on other architectures, because
double is the way to go.
No.
Consider also that on non-Windows platforms, such a decision would shut D out
from accessing C code written using long doubles.
BTW, there's a
On Thursday, 26 June 2014 at 20:57:44 UTC, Jacob Carlborg wrote:
On 2014-06-26 10:19, pgtkda wrote:
Are there any precompiled binaries for windows?
Unfortunately no, there are no pre-compiled binaries. But it's
very easy to build yourself, just follow the build instructions
[1].
[1]
On Friday, 27 June 2014 at 07:59:51 UTC, Jacob Carlborg wrote:
On 2014-06-27 09:51, pgtkda wrote:
Not so easy for me. Where do i have to type this?
$ git clone --recursive
git://github.com/d-widget-toolkit/dwt.git
In a terminal/cmd (btw, you don't type $, that just an
indication it should
On 2014-06-27 10:10, pgtkda wrote:
Okay, thanks for your detailed answer. What should i do next if i
extracted the Win32 zip file?
Follow the instructions here [1]. The steps I described above replaces
the second step in the linked build instructions.
[1]
What does this symbol mean in relation to D?
~
Compiler can't deduce type for template struct Pair when using it
with enum argument. There is an example
import std.stdio;
enum Category { first, second, third };
struct Pair(F, S)
{
F first;
S second;
this(F f, S s)
{
first = f;
On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote:
How I could make this
working without explicit specifying of types?
sorry, i should read better
On Friday, 27 June 2014 at 06:04:20 UTC, Uranuz wrote:
Compiler can't deduce type for template struct Pair when using
it with enum argument. There is an example
import std.stdio;
enum Category { first, second, third };
struct Pair(F, S)
{
F first;
S second;
On Friday, 27 June 2014 at 06:14:48 UTC, pgtkda wrote:
On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote:
How I could make this
working without explicit specifying of types?
sorry, i should read better
Ok. Maybe it was discussed already somewhere, but I am not god in
searching in
On 06/26/2014 10:58 PM, pgtkda wrote:
What does this symbol mean in relation to D?
~
It can be used in two ways:
1) When used as a unary operator, it means bitwise complement:
assert(~0xaa55aa55 == 0x55aa55aa);
2) When used as a binary operator, it means concatenation:
On Friday, 27 June 2014 at 06:21:11 UTC, Uranuz wrote:
On Friday, 27 June 2014 at 06:14:48 UTC, pgtkda wrote:
On Friday, 27 June 2014 at 06:12:57 UTC, pgtkda wrote:
How I could make this
working without explicit specifying of types?
sorry, i should read better
Ok. Maybe it was discussed
On Friday, 27 June 2014 at 06:33:07 UTC, Ali Çehreli wrote:
On 06/26/2014 10:58 PM, pgtkda wrote:
What does this symbol mean in relation to D?
~
It can be used in two ways:
1) When used as a unary operator, it means bitwise complement:
assert(~0xaa55aa55 == 0x55aa55aa);
2) When used
1) After allocating memory by GC.calloc() to place objects on it, what
else should one do? In what situations does one need to call addRoot()
or addRange()?
2) Does the answer to the previous question differ for struct objects
versus class objects?
3) Is there a difference between
I think, D is a typesafe language, therefore you can't use
variables with no type declaration.
One thing you can search for, are templates but even there you
have to define a type:
import std.stdio;
enum Category : string { first = first}
template Pair(T)
{
T t;
T cat;
}
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote:
1) After allocating memory by GC.calloc() to place objects on
it, what else should one do?
Use std.conv.emplace.
In what situations does one need to call addRoot() or
addRange()?
Add root creates an internal reference within the
Seems that I found answer myself. As far as I understand type
inference is working only for template functions but not struct
or class templates. This is why this not working and enum is not
responsible for that.
I don't know why I use D enough long but I did not remember this
fact.
I realize that my answer isn't completely clear in some cases, if
you still have questions, ask away.
There is proposal exists for this topic
http://wiki.dlang.org/DIP40
On 06/27/2014 12:53 AM, safety0ff wrote:
I realize that my answer isn't completely clear in some cases, if you
still have questions, ask away.
Done! That's why we are here anyway. :p
Ali
Thank you for your responses. I am partly enlightened. :p
On 06/27/2014 12:34 AM, safety0ff wrote:
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote:
1) After allocating memory by GC.calloc() to place objects on it, what
else should one do?
Use std.conv.emplace.
That much I know.
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote:
Thank you for your responses. I am partly enlightened. :p
I know you're a knowledgeable person in the D community, I may
have stated many things you already knew, but I tried to answer
the questions as-is.
On 06/27/2014 12:34
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote:
So, the GC's default behavior is to scan the memory,
necessitating clearing the contents? That seems to make
GC.malloc() behave the same as GC.calloc() by default, doesn't
it?
Yes.
compare:
On Friday, 27 June 2014 at 09:20:53 UTC, safety0ff wrote:
Yes.
compare:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L543
to:
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L419
Actually, I just realized that I was wrong in saying the
1 - 100 of 141 matches
Mail list logo
