On 01.06.2013 07:02, Brian Schott wrote:
[3] Of course it doesn't properly support HEREDOC strings, but then
again, nothing does.
Well, I wouldn't say that in general:
http://www.dsource.org/projects/visuald/wiki/Tour/Editor ;-)
On Fri, 2013-05-31 at 13:50 -0700, Ellery Newcomer wrote:
[…]
just tried it on ubuntu 12.10, and it does the same.
are you using -defaultlib=libphobos2.so
I suspect I may be doing different things from you as I never use an
option of that sort. Perhaps we should agree a code and command to
On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
On Thursday, 30 May 2013 at 12:55:29 UTC, Rainer Schuetze wrote:
On 17.05.2013 19:43, Rainer Schuetze wrote:
On 12.05.2013 20:48, Walter Bright wrote:
On 5/11/2013 3:39 AM, Rainer Schuetze wrote:
a new version of Visual D is long
http://www.youtube.com/watch?v=V98Z11V7kEY has inspired me to
revive DMocks project. So far I only made it work with latest dmd
and made some cleanups. I think that's enough for anyone to try
out the ideas from the vid, you have no excuse now not to do
it:P. I'm waiting for opinions, since
On Saturday, 1 June 2013 at 10:46:26 UTC, QAston wrote:
http://www.youtube.com/watch?v=V98Z11V7kEY has inspired me to
revive DMocks project. So far I only made it work with latest
dmd and made some cleanups. I think that's enough for anyone to
try out the ideas from the vid, you have no excuse
On 01.06.2013 12:45, Flamaros wrote:
On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
I followed indications, lst files are correctly generated for the code
coverage, but I don't have the coloration in the editor. Can be because
my application crash when exiting?
If your
On 6/1/13, Brian Schott briancsch...@gmail.com wrote:
Textadept 6.6 has been released. Changelog located here[1].
What exactly is the difference against e.g. Scite? I can see it uses
GTK for windowing, which I'm not a fan of, but that's just a nitpick.
Does it have any cool features that are not
On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote:
On 01.06.2013 12:45, Flamaros wrote:
On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
I followed indications, lst files are correctly generated for
the code
coverage, but I don't have the coloration in the editor.
On 01.06.2013 16:59, Flamaros wrote:
On Saturday, 1 June 2013 at 10:55:36 UTC, Rainer Schuetze wrote:
On 01.06.2013 12:45, Flamaros wrote:
On Thursday, 30 May 2013 at 22:39:28 UTC, Flamaros wrote:
I followed indications, lst files are correctly generated for the code
coverage, but I
On 06/01/2013 02:31 AM, Russel Winder wrote:
On Fri, 2013-05-31 at 13:50 -0700, Ellery Newcomer wrote:
[…]
just tried it on ubuntu 12.10, and it does the same.
are you using -defaultlib=libphobos2.so
I suspect I may be doing different things from you as I never use an
option of that sort.
On Saturday, 1 June 2013 at 13:13:00 UTC, Andrej Mitrovic wrote:
On 6/1/13, Brian Schott briancsch...@gmail.com wrote:
Textadept 6.6 has been released. Changelog located here[1].
What exactly is the difference against e.g. Scite? I can see it
uses
GTK for windowing, which I'm not a fan of,
On 5/31/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 5/30/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Hello,
We seem to have a regression affecting the zipped release:
http://d.puremagic.com/issues/show_bug.cgi?id=10215
Kenji has reduced this, and apparently it's
On 2013-05-31 14:33, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/1feem1/dconf_2013_day_2_talk_3_from_c_to_d_by_adam_wilson/
A couple of notes on what's missing in D from C#.
There are other libraries besides from Phobos that contains some of the
missing
On Saturday, June 01, 2013 22:15:01 Jacob Carlborg wrote:
* Timer/stop watch
There are quite a few things that Phobos is still missing, but this isn't one
of them. We have std.datetime.StopWatch (which will probably end up in
std.benchmark when that's finally complete).
- Jonathan M Davis
On Sat, 01 Jun 2013 13:15:01 -0700, Jacob Carlborg d...@me.com wrote:
On 2013-05-31 14:33, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/1feem1/dconf_2013_day_2_talk_3_from_c_to_d_by_adam_wilson/
A couple of notes on what's missing in D from C#.
There are other
I'd say this is a good thing. Please don't pollute the source tree with
junk placed next to the source files. This is very un-visual-studio. They
should be in the intermediate folder next to the obj files.
On 2 Jun 2013 01:15, Rainer Schuetze r.sagita...@gmx.de wrote:
On 01.06.2013 16:59,
This form is nice:
int[3] x = [1,2,3];
But it is horribly inefficient because it
1. allocates a dynamic array from the GC
2. writes 1,2,3 to the dynamic array
3. copies the 1,2,3 back to the static array
Or one can write:
int[3] x;
x[0] = 1;
x[1] = 2;
x[2] = 3;
That is a lot of typing, but
I'm adding D-style ranges to my new C# collections library. In
case anyone would like to comment, please see here:
http://loyc-etc.blogspot.ca/2013/06/d-style-ranges-in-c-net.html
On Saturday, June 01, 2013 08:16:47 finalpatch wrote:
This form is nice:
int[3] x = [1,2,3];
But it is horribly inefficient because it
1. allocates a dynamic array from the GC
2. writes 1,2,3 to the dynamic array
3. copies the 1,2,3 back to the static array
Are you sure that that
Oh cool, good to know this has been fixed. You are right, I just
verified with DMD 2.063 and the generated code was good! Sorry
about the noise.
On Saturday, 1 June 2013 at 06:28:45 UTC, Jonathan M Davis wrote:
Are you sure that that still allocates? I thought that that had
been fixed. If
it
Am 01.06.2013 05:08, schrieb Jonathan M Davis:
On Friday, May 31, 2013 23:59:45 Juan Manuel Cabo wrote:
Making everything final by default would IMO kind of break
automated mock classes generation for unit testing,
automatic proxy class generation for DB entities, and
other OOP niceities.
I actually don't feel final by default is a big deal at all. Of
all the factors that caused the poor performance that was
discussed in the original post, final is the least significant
one, only caused 5% to %7 of a speed penalty in a heavily
recursive and looping program. Because of this I
Manu:
- Scanning the whole heap is costly
Rust avoids this giving a different heap to each thread, and
common heap to share data managed with unique references.
- GC runs at unpredictable moments
Is this true? I think the D GC runs only when you allocate
something.
Bye,
bearophile
On Sunday, 26 May 2013 at 01:24:51 UTC, Manu wrote:
I might just add, that if you have Visual Studio installed
(which I
presume many Windows dev's do), then you don't need to do
ANYTHING.
DMD64 just works if VS is present.
I didn't do a single thing to get DMD-Win64 working. And it's
Alex Rønne Petersen:
I'm sure this has been brought up before, but I feel I need to
bring it up again (because I'm going to be writing a
threaded-code interpreter):
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
This is an incredibly important extension.
This was discussed more
David Piepgrass:
http://loyc-etc.blogspot.ca/2013/06/d-style-ranges-in-c-net.html
From the article:
Ranges are an improvement on the C++ concept of iterators. I
don't exactly know how ranges were invented in D, but perhaps
someone noticed that most of the C++ STL algorithms require
pairs
On Sat, 2013-06-01 at 05:34 +0200, Zach the Mystic wrote:
On Friday, 31 May 2013 at 21:35:46 UTC, Nick Sabalausky wrote:
Just to be clear (not sure if it came across or not), I was
[attempting to] make a joke about Ahh, you love being
corrected? Well
then I'll be nice and correct you
On Fri, 2013-05-31 at 14:08 -0700, Ellery Newcomer wrote:
[…]
But I wonder if RPM Fusion would balk at dmd's kooky distribution
restrictions?
Hummm… that may just make it impossible to get DMD into Debian, and
hence Mint and probably Ubuntu, except in the non-free section. RPM
Fusion is less
On 06/01/2013 04:02 AM, Manu wrote:
While I do think a sufficiently advanced GC might satisfy the realtime
environment, the more I think about it, the more I am thinking a GC is not
applicable to the embedded (or memory limited) environment.
So what options exist?
I'm thinking more and
On Saturday, 1 June 2013 at 08:12:00 UTC, bearophile wrote:
David Piepgrass:
In fact, most STL algorithms require exactly two iterators--a
range--and none require only a single iterator
I think there are some C++ data structures that store many
single iterators. If you instead store ranges
Nothing will get done until someone decides to put in the effort
to fix the problem. D's biggest drawback at this point is the GC
and one would think with all the smart people around here someone
would have solved this problem by now.
We need a solution that allows one to plug and play
On 2013-05-31 23:08, Rémy Mouëza wrote:
Concerning dstep,
I compiled it recently (Ubuntu 12.04 32 bits system) and it wasn't as
straightforward as it was described in the README file, nor was it that
complicated to have it work. I'll outline my experience below for those
interested.
first step
Alex Rønne Petersen:
final switch (insn.op)
{
case imm: lbl = handle_imm; break;
case add: lbl = handle_add; break;
case sub: lbl = handle_sub; break;
// ...
case ret: lbl = handle_ret;
On Friday, 31 May 2013 at 06:41:19 UTC, Manu wrote:
It would be nice
if array operations would unroll for short arrays. Particularly
so for
static arrays!
It definitely is something we need to implement. There is just no
excuse not to, and it hampers the practicality of a nice language
Am 01.06.2013 12:52, schrieb Tove:
does this generate better code?
float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]);
That doesn't even compile. You can try it out yourself using:
http://dpaste.dzfl.pl/
Kind Regards
Benjamin Thaut
On Friday, 31 May 2013 at 15:02:00 UTC, bearophile wrote:
Thanks to Kenji the latest dmd 2.063 solves part of this
problem:
http://d.puremagic.com/issues/show_bug.cgi?id=2356
Maybe this improvement is not yet in LDC/GDC.
Regarding static array initialization from literals, yes, that
change
On 2013-06-01 04:16, Adam D. Ruppe wrote:
Some little things we could do is add overloads to some functions that
return string to be able to take a buffer argument too.
string to(T:string)(int a) { char[] buf = new char[](16); return
assumeUnique(to(a, buffer));
char[] to(int a, char[] buffer)
On Saturday, 1 June 2013 at 10:18:27 UTC, Benjamin Thaut wrote:
I've taken a look at core.simd and I have to say is unuseable.
In a very small test program I already found 3 bugs
1) Using debug symbols together with core.simd will cause a ICE
In my eyes there is just one reason there is no better GC yet: It
requires compiler support.
And thats a huge problem. The number of people who would actually be
ablte to make the modifications on the compiler in this community is
very small and they tend to not have much time doing it. A
On Saturday, 1 June 2013 at 10:57:03 UTC, Benjamin Thaut wrote:
Am 01.06.2013 12:52, schrieb Tove:
does this generate better code?
float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]);
That doesn't even compile. You can try it out yourself using:
http://dpaste.dzfl.pl/
Kind Regards
Benjamin Thaut
On Saturday, 1 June 2013 at 05:45:38 UTC, SomeDude wrote:
In the Rust based provocation thread, I think Adam Ruppe's
work went largely overlooked.
Discussion has continued via e-mail and his efforts has not gone
unnoticed :)
It is important proof-of-concept that can be used to highlight
finalpatch:
I actually don't feel final by default is a big deal at all. Of
all the factors that caused the poor performance that was
discussed in the original post, final is the least significant
one, only caused 5% to %7 of a speed penalty in a heavily
recursive and looping program.
Am 01.06.2013 03:23, schrieb Andrej Mitrovic:
On 6/1/13, Manu turkey...@gmail.com wrote:
Building DMD with MSVC results in a compiler that runs MUCH MUCH faster.
In the interest of making DMD releases as fast as possible, this should be
standardised.
Just one thing: Before attempting to build
Am 31.05.2013 19:21, schrieb Rob T:
On Friday, 31 May 2013 at 16:52:53 UTC, Jonathan M Davis wrote:
On Friday, May 31, 2013 18:05:16 Rob T wrote:
I've seen this happen with 2.062, if you take out -noboundscheck
it may reduce the size significantly and compile a lot faster.
Makes no sense.
My
This @= is the .dup protocol
@= would copy, while the = is most usually a reference assign
when that is possible.
If you have a regular method of clone which is a protocol for
most all things who agree to use it, then = for assign by
reference is more fair
Am 31.05.2013 19:19, schrieb deadalnix:
On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote:
On Fri, 31 May 2013 16:58:11 +0100, Craig Dillabaugh
cdill...@cg.scs.carleton.ca wrote:
Under 40 kilobytes! If you do the bare minimum you can get down to
about 1 KB, but at that point, you're
Am 01.06.2013 14:18, schrieb David:
This is a good question, I want to implement core.simd in gl3n for a
while, I hope we can get a proper implementation and std.simd *wink at Manu*
Well std.simd will be using core.simd for the dmd version, so core.simd
has to be working first.
On 2013-06-01 02:02:53 +, Manu turkey...@gmail.com said:
* find a solution for deterministic embedded garbage collection
I think reference counting while still continuing to use the current GC
to release cycles is the way to go. It wouldn't be too hard to
implement.
This could make
I've taken a look at core.simd and I have to say is unuseable. In a very
small test program I already found 3 bugs
1) Using debug symbols together with core.simd will cause a ICE
http://d.puremagic.com/issues/show_bug.cgi?id=10224
2) The STOUPS instruction is not correctly implemented:
On Saturday, 1 June 2013 at 06:28:45 UTC, Jonathan M Davis wrote:
On Saturday, June 01, 2013 08:16:47 finalpatch wrote:
This form is nice:
int[3] x = [1,2,3];
But it is horribly inefficient because it
1. allocates a dynamic array from the GC
2. writes 1,2,3 to the dynamic array
3. copies the
On Saturday, 1 June 2013 at 11:50:23 UTC, bearophile wrote:
As example the very small but fast virtual machine written in
GNU C++ from the International Contest on Functional
Programming 2006:
http://codepad.org/iibBeWKw
It's faster than the same code without computed gotos.
Bye,
bearophile
Am 01.06.2013 12:18, schrieb Benjamin Thaut:
I've taken a look at core.simd and I have to say is unuseable. In a very
small test program I already found 3 bugs
1) Using debug symbols together with core.simd will cause a ICE
http://d.puremagic.com/issues/show_bug.cgi?id=10224
2) The STOUPS
On 6/1/13 2:17 AM, David Piepgrass wrote:
I'm adding D-style ranges to my new C# collections library. In case
anyone would like to comment, please see here:
http://loyc-etc.blogspot.ca/2013/06/d-style-ranges-in-c-net.html
As example the very small but fast virtual machine written in GNU
C++ from the International Contest on Functional Programming 2006:
http://codepad.org/iibBeWKw
It's faster than the same code without computed gotos.
Bye,
bearophile
Am 01.06.2013 04:13, schrieb Joseph Rushton Wakeling:
On Friday, 31 May 2013 at 23:32:36 UTC, Manu wrote:
Building DMD with MSVC results in a compiler that runs MUCH MUCH faster.
... Numbers?
Purely out of academic curiosity, as I'm a GNU/Linux user :-)
I haved measured it exactly but its
Am 01.06.2013 13:37, schrieb Tove:
On Saturday, 1 June 2013 at 10:57:03 UTC, Benjamin Thaut wrote:
Am 01.06.2013 12:52, schrieb Tove:
does this generate better code?
float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]);
That doesn't even compile. You can try it out yourself using:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
There is a bug in the visual studio 2010 and up compiler which causes
real support to break.
Ouch. I'll give it a go soon. Is this filed as a bug / pull ready somewhere?
On 6/1/13 2:54 AM, finalpatch wrote:
I actually don't feel final by default is a big deal at all. Of all the
factors that caused the poor performance that was discussed in the
original post, final is the least significant one, only caused 5% to %7
of a speed penalty in a heavily recursive and
On Saturday, 1 June 2013 at 06:17:30 UTC, David Piepgrass wrote:
I'm adding D-style ranges to my new C# collections library. In
case anyone would like to comment, please see here:
http://loyc-etc.blogspot.ca/2013/06/d-style-ranges-in-c-net.html
Lol I am just preparing a blog post on D ranges
Am 01.06.2013 15:35, schrieb Andrej Mitrovic:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
There is a bug in the visual studio 2010 and up compiler which causes
real support to break.
Ouch. I'll give it a go soon. Is this filed as a bug / pull ready somewhere?
This is a MSVC
Am 01.06.2013 01:30, schrieb Manu:
On 1 June 2013 09:15, bearophile bearophileh...@lycos.com
mailto:bearophileh...@lycos.com wrote:
Manu:
On 1 June 2013 01:12, bearophile bearophileh...@lycos.com
mailto:bearophileh...@lycos.com wrote:
Manu:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
And your unittests should run again.
I've tried this fix, it still doesn't work for me:
$ echo unittest { assert(0); } void main() { } test.d
$ rdmd --force -unittest --compiler=dmd_dmc test.d
core.exception.AssertError@test(1):
On 6/1/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
I've tried with a clean build and then a full release build.
Same problem with the debug build. :/
Am 01.06.2013 16:34, schrieb Andrej Mitrovic:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
And your unittests should run again.
I've tried this fix, it still doesn't work for me:
$ echo unittest { assert(0); } void main() { } test.d
$ rdmd --force -unittest --compiler=dmd_dmc
On Saturday, 1 June 2013 at 05:45:38 UTC, SomeDude wrote:
Basically it is a non allocating D subset.
Not necessarily nonallocating, but it doesn't use a gc. I just
updated the zip:
http://arsdnet.net/dcode/minimal.zip
If you make the program (only works on linux btw) and run it,
you'll
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
Most likely its throwing some hardware exception which
emediatly kills it.
It turns out it's something related to RDMD:
$ rdmd --force -unittest --compiler=dmd_msc test.d
$ dmd_msc -unittest test.d -oftest.exe test.exe
On 01.06.2013 16:20, Benjamin Thaut wrote:
Am 01.06.2013 15:35, schrieb Andrej Mitrovic:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
There is a bug in the visual studio 2010 and up compiler which causes
real support to break.
Ouch. I'll give it a go soon. Is this filed as a bug
On 01.06.2013 16:39, Benjamin Thaut wrote:
Am 01.06.2013 16:34, schrieb Andrej Mitrovic:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
And your unittests should run again.
I've tried this fix, it still doesn't work for me:
$ echo unittest { assert(0); } void main() { } test.d
On 6/1/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
So it looks like an RDMD-related bug.
Ah it's definitely an RDMD bug, look:
$ rdmd --chatty --force --compiler=dmd_msc test.d
It then spits out these and just exits:
-
stat C:\Users\ADMINI~1\AppData\Local\Temp\.rdmd
stat
Hi Andrei,
I have summarized the results with LDC on Mac OSX in a previous
posts:
orignal: 760ms
* change v = [x,x,x] to v[0]=x... in this(float) constructor -
540ms (220ms improvment)
* remove this(float[]) constructor and replace it with
this(float,float,float) - 410ms (130ms improvment)
On 6/1/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 6/1/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
So it looks like an RDMD-related bug.
Ah it's definitely an RDMD bug.
Filed as http://d.puremagic.com/issues/show_bug.cgi?id=10229
On 6/1/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Other than that it does seem to be faster. I haven't ran any benchmarks
yet.
Now that I've fixed my builds, it does seem to run considerably faster:
DMD with DMC:
Done in 8_331_946 usecs.
DMD with MSC:
Done in 3_948_409 usecs.
This
On Sat, Jun 01, 2013 at 10:21:59AM +0100, Russel Winder wrote:
On Fri, 2013-05-31 at 14:08 -0700, Ellery Newcomer wrote:
[…]
But I wonder if RPM Fusion would balk at dmd's kooky distribution
restrictions?
Hummm… that may just make it impossible to get DMD into Debian, and
hence Mint and
huh array literals don't work since they call an allocation
function, even if all the data in them is all static. That's
disappointing.
We can force it though with something like this:
template arrlit(T...) {
static __gshared immutable int[] literal = [T];
alias arrlit =
Am 01.06.2013 16:24, schrieb Benjamin Thaut:
Am 01.06.2013 01:30, schrieb Manu:
On 1 June 2013 09:15, bearophile bearophileh...@lycos.com
mailto:bearophileh...@lycos.com wrote:
Manu:
On 1 June 2013 01:12, bearophile bearophileh...@lycos.com
mailto:bearophileh...@lycos.com
BTW I think the compiler should redo array literals to work like
this:
rewrite it into: array!T(elements)
always try to CTFE it. Since it is a literal this should provide
as much indication as enum that you want this.
If it works, put it out as static info in the exe.
If not just leave
On Saturday, 1 June 2013 at 15:35:25 UTC, Adam D. Ruppe wrote:
BTW I think the compiler should redo array literals to work
like this:
lol then we'd probably complain about template bloat. the
typeinfo+void* plan druntime uses is actually kinda nice, it
avoids that and typeinfo is potentially
On 01.06.2013 15:35, Andrej Mitrovic wrote:
On 6/1/13, Benjamin Thaut c...@benjamin-thaut.de wrote:
There is a bug in the visual studio 2010 and up compiler which causes
real support to break.
Ouch. I'll give it a go soon. Is this filed as a bug / pull ready somewhere?
I've made a pull
Am 01.06.2013 17:42, schrieb Adam D. Ruppe:
On Saturday, 1 June 2013 at 15:35:25 UTC, Adam D. Ruppe wrote:
BTW I think the compiler should redo array literals to work like this:
lol then we'd probably complain about template bloat. the typeinfo+void*
plan druntime uses is actually kinda nice,
On 05/31/2013 04:23 PM, Steven Schveighoffer wrote:
On Fri, 31 May 2013 06:47:07 -0400, Timon Gehr timon.g...@gmx.ch wrote:
@attribute(target, T) void func(string T)() {}
would simply need to be treated like:
template func(string T){
@attribute(target, T) void func() {}
}
In fact,
On Saturday, June 01, 2013 09:43:49 bearophile wrote:
- GC runs at unpredictable moments
Is this true? I think the D GC runs only when you allocate
something.
Sure, but which of these calls to new is going to cause the GC to run?
auto a = new Foo;
...
auto b = new Bar;
...
auto c = new
On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote:
Hi,
I'm sure this has been brought up before, but I feel I need to bring it
up again (because I'm going to be writing a threaded-code interpreter):
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
This is an incredibly important
On 06/01/2013 11:43 AM, bearophile wrote:
Alex Rønne Petersen:
final switch (insn.op)
{
case imm: lbl = handle_imm; break;
case add: lbl = handle_add; break;
case sub: lbl = handle_sub; break;
// ...
On Saturday, 1 June 2013 at 16:13:18 UTC, Timon Gehr wrote:
I'd also like to see this.
Me too. Last time this came up I said no since there's some
inline asm hacks you can do but turns out those hacks suck in
capability and appearance compared to just having this feature.
David Piepgrass:
In fact, most STL algorithms require exactly two iterators--a
range--and none require only a single iterator
I think there are some C++ data structures that store many
single iterators. If you instead store ranges you double the
data amount.
Hashmaps would be the most
On Saturday, 1 June 2013 at 16:23:11 UTC, Adam D. Ruppe wrote:
On Saturday, 1 June 2013 at 16:13:18 UTC, Timon Gehr wrote:
I'd also like to see this.
Me too. Last time this came up I said no since there's some
inline asm hacks you can do but turns out those hacks suck in
capability and
This idea is pretty awful, because it works good for:
a @= b;
But it doesn't cover the cases where .dup is far more general:
T[] l = [ a.dup, b.dup, c ];
Modified by a stretch to macro cloning:
T[] l @= [ a, b, c ]; // all 3 of them clone. nuts for
every reason you could come up with.
I actually like the ability to clone all the elements of the
slice being made.
If there's merit to this idea, or if it's terrible, I'd trust
Walter and Andrei to know the real answer considering the
implications. Hence why I did not make a proposal for this
operator.
On Saturday, 1 June 2013 at 16:30:05 UTC, David Piepgrass wrote:
David Piepgrass:
In fact, most STL algorithms require exactly two iterators--a
range--and none require only a single iterator
I think there are some C++ data structures that store many
single iterators. If you instead store
On 5/30/2013 7:56 PM, Andrei Alexandrescu wrote:
On 5/30/13 9:26 PM, finalpatch wrote:
https://dl.dropboxusercontent.com/u/974356/raytracer.d
https://dl.dropboxusercontent.com/u/974356/raytracer.cpp
Manu's gonna love this one: make all methods final.
I have another suggestion. class Sphere
Am 01.06.2013 20:23, schrieb Mehrdad:
On Saturday, 1 June 2013 at 16:30:05 UTC, David Piepgrass wrote:
David Piepgrass:
In fact, most STL algorithms require exactly two iterators--a
range--and none require only a single iterator
I think there are some C++ data structures that store many
You shouldn't be using 32-bit indices on x64, that defeats the
whole
point of x64.
As of .NET 4.5, 64bit array indexes are supported as well.
http://msdn.microsoft.com/en-us/library/hh285054.aspx
Don't forget that we're talking about a *hashtable* here. If a
.NET hashtable used 64-bit
On Saturday, 1 June 2013 at 14:52:25 UTC, Rainer Schuetze wrote:
Benjamin Thaut
If I remember correctly you also had problems with a MSVC build
invoking the linker if there are spaces in the path to it. I
suspect this might also happen when rdmd tries to run the
program.
You are correct,
On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote:
Do you really think that is such a big issue?
Not really an issue, no. But newcomers keep creating threads
like this one time and again and who knows how many have been
turned away without finding out the whys and wherefores.
R
On Saturday, 1 June 2013 at 16:02:06 UTC, Paulo Pinto wrote:
I get the feeling it starts to feel like Ada then. :)
Adam starts with Ada !
On Friday, 31 May 2013 at 14:33:48 UTC, khurshid wrote:
I just download dmd 2.063, and compile simple hello world
program:
// hello.d
import std.stdio;
int main()
{
writeln(hello world);
return 0;
}
with -O -release -inline -noboundscheck flags.
And size of result output file
Hello, I know that everybody will hate that, as most of the
people coming to D are also coming from the C world, but, anyway
I suggest this data naming convention:
class cMyClass
struct sMyStruct
templatetMyTmp
parameter aParam ( + exception: someParams to
The way I understood it, @safe defines a list of things that are
or aren't legal inside the implementation of a function. It also
changes the scheme of bounds checking, in release code.
What bothers me though, is that from an interface point of view,
it doesn't really mean anything (or at
In the talk Shared Libraries in D by Martin Nowak loadLibrary
is presented with the signature:
void* loadLibrary(string path);
But in the docs we have:
static void* loadLibrary(in char[] name);
Any particular reason for using in char[] instead of string? (I
suppose the in makes the
I got a better thing implemented, what do you think of this?
// usage
@CustomInfo!(hey) // can be anything in there, but don't repeat
a type
@CustomInfo!(1)
class Test {}
auto info = typeid(Test).rtInfo();
immutable(string)* str = rtInfo.getCustomData!string;
writeln(str is null ? not there
1 - 100 of 225 matches
Mail list logo
