On 4/16/2014 11:55 PM, Manu via Digitalmars-d wrote:
It occurs to me that a central issue regarding the memory management debate, and
a major limiting factor with respect to options, is the fact that, currently,
it's impossible to tell a raw pointer apart from a gc pointer.
No it isn't, in fact
On Friday, 18 April 2014 at 16:45:30 UTC, Walter Bright wrote:
A lot of comments in the "DIP60: @nogc attribute" thread about
doing ARC in D are answered in this earlier thread:
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
Thank you.
I added this to the wiki so it can be ea
"asman" wrote in message news:ktcpixnpmessxamqe...@forum.dlang.org...
Thanks very much. In this case I can assume there's no std::
stuff and it isn't allowed, correct?
Yes. If you started using namespaces, stl, etc it would break DDMD so it's
essentially banned now.
On Friday, 18 April 2014 at 23:54:52 UTC, Walter Bright wrote:
You shouldn't be using global data anyway.
Why not? LUTs and indexes that are global saves you a register.
Also possible in C# with structs, interop annotations and
unsafe blocks.
And now you aren't using the language, but a (very) poor subset
of a language that doesn't even support templates.
C++ exposes SSE/AVX intrinsics, C# does not.
That is not correct.
1 - Nowhere in the ANSI/ISO C++
On Saturday, 19 April 2014 at 01:50:17 UTC, asman wrote:
On Wednesday, 16 April 2014 at 13:57:33 UTC, Daniel Murphy
wrote:
"asman" wrote in message
news:maojdlxhbwuhxqrmv...@forum.dlang.org...
is there? if so, where is it? Also, I see dmd is written in
C++ but still uses C style to do stuff
On Wednesday, 16 April 2014 at 13:57:33 UTC, Daniel Murphy wrote:
"asman" wrote in message
news:maojdlxhbwuhxqrmv...@forum.dlang.org...
is there? if so, where is it? Also, I see dmd is written in
C++ but still uses C style to do stuff eg, printf() instead of
cout. Is this why C++ libraries c
On 4/18/2014 5:30 AM, Steven Schveighoffer wrote:
Absolutely not, the compiler knows whether the count needs to be incremented, I
don't need to know.
But there are manual escapes from it, meaning you need to know to use them:
unsigned char *vdata = data.data;
// process vdata
I am skept
Am Thu, 17 Apr 2014 06:19:56 +
schrieb "Ola Fosheim Grøstad"
:
> On Wednesday, 16 April 2014 at 23:14:27 UTC, Walter Bright wrote:
> > On 4/16/2014 3:45 PM, "Ola Fosheim Grøstad" I've written
> > several myself that do not use malloc.
>
> If it is shared or can call brk() it should be annota
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
-- Aleksandar
I do agree that the design of the current site is rather dated. I
rather like your new proposed design as well. One thing that
could be nicer is the search bar being a button to click
On Fri, 18 Apr 2014 16:48:43 -0700, Walter Bright
wrote:
On 4/18/2014 3:02 PM, Michel Fortin wrote:
Objective-C enables ARC by default for all pointers to Objective-C
objects.
Since virtually all Objective-C APIs deal with Objective-C objects (or
integral
values), if you limit yourself to
On 4/18/2014 3:10 PM, John Colvin wrote:
On Friday, 18 April 2014 at 20:24:51 UTC, Walter Bright wrote:
On 4/18/2014 10:54 AM, John Colvin wrote:
My understanding is that a more sophisticated GC will also not coexist quite so
peacefully with pointers of all types. Is it not the conservativeness
On 4/18/2014 4:58 AM, "Ola Fosheim Grøstad"
" wrote:
TLS sucks, as you get extra indirections if it isn't implemented using a MMU
(typically not because the extra page tables would cost too much?).
You shouldn't be using global data anyway. Most TLS references will be to the
heap or stack, whi
On 4/18/14, 9:04, Aleksandar Ruzicic wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not participate
much in discussions here, although I read forums almost daily), and I
keep telling people about D and how awesome it is.
[snip]
So, what do you guys think?
-- Aleksan
On 4/18/2014 3:02 PM, Michel Fortin wrote:
Objective-C enables ARC by default for all pointers to Objective-C objects.
Since virtually all Objective-C APIs deal with Objective-C objects (or integral
values), if you limit yourself to Objective-C APIs you're pretty much
memory-safe.
"pretty much
On 4/18/2014 1:58 PM, Steven Schveighoffer wrote:
This isn't correct. Only structs cannot have internal references. Objects don't
move or copy so easily.
Objects can't have internal references either, for the same reason.
Not only that, but internal pointers would not prevent a moving GC.
On Friday, 18 April 2014 at 20:24:51 UTC, Walter Bright wrote:
On 4/18/2014 10:54 AM, John Colvin wrote:
My understanding is that a more sophisticated GC will also not
coexist quite so
peacefully with pointers of all types. Is it not the
conservativeness* of the GC
that enables this coexistenc
On 4/18/2014 6:07 PM, Nick Sabalausky wrote:
As long as it's:
[...]
Meant to say: Nothing against the current design, but as long as yours
is (those things), then I'd be very happy to see your design used.
On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:
I have also tried to design something myself (although I'm not a
designer) and this is what I came up with:
http://krcko.net/dlang.org/dlang-home-draft1.png
I'm not entirely satisfied with it but I believe that it looks better
(or at least more
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the
left-justification
On 2014-04-18 20:40:06 +, Walter Bright said:
O-C doesn't use ARC for all pointers, nor is it memory safe.
@safe would be very easy to implement in Objective-C now that ARC is there.
This has got me thinking. Ever heard "C is the new assembly"? I think
this describes very well the relat
On Fri, 18 Apr 2014 16:40:06 -0400, Walter Bright
wrote:
This isn't quite correct. I implemented a GC for Java back in the 90's.
D has semantics that are conducive to GC that C doesn't have, and this
was done based on my experience with GC's. To wit, objects can't have
internal reference
I really like rust-lang.org, I was thinking of using it as a
base for design but decided against it because I don't want
dlang.org to be accused of ripping of rust-lang.org.
:-) I like rust-lang for being concise and outspoken about what
they are all about, but not very verbose on the front pa
On 4/18/2014 2:46 AM, Manu via Digitalmars-d wrote:
Consensus is that there's no performant GC available to D either.
Switching from one non-performant system to another won't help matters.
Can you show that Obj-C suffers serious performance penalty from it's ARC
system? Have there been comp
Walter Bright:
dmd could do a better job of escape analysis, and do this
automatically.
Timon has kindly fixed the wrong part I wrote in the DIP60. But
if we introduce some basic escape analysis required by all
conformant D compilers, then the @nogc attribute can be applied
to some function
On 4/18/2014 12:44 PM, Jacob Carlborg wrote:
It's already possible to stack allocate classes. Either using the now deprecated
(removed?) "scope" or a library solution.
dmd could do a better job of escape analysis, and do this automatically.
On Friday, 18 April 2014 at 20:12:44 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic
wrote:
I wanted something that looks "professional", which is
something that can be associated with both serious community
and a corporation.
In the past decade th
On 4/18/2014 10:53 AM, Andrei Alexandrescu wrote:
On 4/18/14, 10:12 AM, Walter Bright wrote:
On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
Well there's been work on that. I mentioned this recent paper in this
group:
http://goo.gl/tavC1M, which claims RC backed by a cycle collector can
reach
On 4/18/2014 10:54 AM, John Colvin wrote:
My understanding is that a more sophisticated GC will also not coexist quite so
peacefully with pointers of all types. Is it not the conservativeness* of the GC
that enables this coexistence?
Yes. Which is one reason why D doesn't emit write gates for i
On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic
wrote:
I wanted something that looks "professional", which is
something that can be associated with both serious community
and a corporation.
In the past decade there has been so many startups with
programming frameworks that go bus
On Friday, 18 April 2014 at 18:53:47 UTC, Kagamin wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png
Isn't it only Microsoft PR department, who call metro style
modern? I'm surprised there're people who took it by heart.
On Friday, 18 April 2014 at 18:56:38 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png
I'm not entirely satisfied with it but I believe that it looks
better (or at least more modern) than the cu
On 2014-04-17 15:08, Orvid King via Digitalmars-d wrote:
Lastly, I'll add support for stack allocated
classes, however that will likely have to be disabled until DMD gets
full escape analysis. As a final note, this will be the 3rd GC I've
written, although it will be the most complex by far. The
On 2014-04-16 19:52, Adam D. Ruppe wrote:
What I want is a __trait that scans for all call expressions in a
particular function and returns all those functions.
Then, we can check them for UDAs using the regular way and start to
implement library defined things like @safe, @nogc, etc. (safe and
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png
I'm not entirely satisfied with it but I believe that it looks
better (or at least more modern) than the current design.
So, what do you guys think?
Nice initiative, but th
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png
Isn't it only Microsoft PR department, who call metro style
modern? I'm surprised there're people who took it by heart.
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
But, all this time D's official website somehow archaic look
kept troubling me. It reminds me of early 2000's design and I
really cannot associate this design with "modern" or "elegant",
what D really is.
Agreed.
So, what
On Friday, 18 April 2014 at 17:12:11 UTC, Walter Bright wrote:
3. I picked a GC for D because a GC coexists peacefully with
pointers of all types. This is not remotely true with ref
counting. It's not an issue with Java, which has no pointers,
but this coexistence problem would be a huge one fo
On 4/18/14, 10:12 AM, Walter Bright wrote:
On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
Well there's been work on that. I mentioned this recent paper in this
group:
http://goo.gl/tavC1M, which claims RC backed by a cycle collector can
reach
parity with tracing. Worth a close read.
A couple
On Wednesday, 16 April 2014 at 22:11:23 UTC, froglegs wrote:
I am really looking forward to .NET Native becoming widespread.
Then this type of comparisons (C# vs C++) will be quite
different.
I don't think it will make a major difference. Taking a GC
based language and giving it a native
On Friday, 18 April 2014 at 17:20:55 UTC, Iain Buclaw via
Digitalmars-d wrote:
Really? To me it looks like the OP is mimicking Github
dccumentation pages.
eg: http://uwsgi-docs.readthedocs.org/en/latest/
I really like the look of Read the Docs and it's something I
would definitely base de
On Friday, 18 April 2014 at 16:55:03 UTC, David Gileadi wrote:
If you have access to real designers (as you mentioned in
another message) that would be fantastic. I think the mockup
you created is already a good direction but folks with
experience in UX, typography, responsive design etc. could
On Friday, 18 April 2014 at 16:53:38 UTC, Brad Anderson wrote:
Even if it weren't better looking, just different, I'd say it
should be done. I'm of the opinion that every site, no matter
how good it looks, should go through redesigns periodically in
order to feel fresh and non-stagnant to repea
On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the
left-justification s
On 18 April 2014 15:22, Steven Schveighoffer via Digitalmars-d
wrote:
> On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
> wrote:
>
>> Hello,
>>
>> I've been D enthusiast for couple of years now (but I do not participate
>> much in discussions here, although I read forums almost daily), and
On 4/17/2014 10:53 PM, Walter Bright wrote:
I recall our email discussion about implementing ARC in D
Rainer found it:
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
On Friday, 18 April 2014 at 16:51:44 UTC, Brad Anderson wrote:
Here's one (they are kind of hard to Google now that the
preview is up on the site and "ddox" appears on every page):
http://forum.dlang.org/thread/lfjcfm$2frn$1...@digitalmars.com
Thanks! I haven't worked with ddox yet but I'm loo
On 4/18/2014 8:34 AM, Andrei Alexandrescu wrote:
Well there's been work on that. I mentioned this recent paper in this group:
http://goo.gl/tavC1M, which claims RC backed by a cycle collector can reach
parity with tracing. Worth a close read.
A couple crucial points:
1. It achieves near parity
On Friday, 18 April 2014 at 16:25:10 UTC, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:
As the guy who was mostly responsible for the current look and
feel of the website I can provide some insight into the effort
required. The website is built using
On 4/18/14, 9:25 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:
[snip]
Also note that there's a movement to make at least part of the website
(the Phobos docs) use a different documentation generator, so the new
look would need to be ported to tha
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
I have also tried to design something myself (although I'm not
a designer) and this is what I came up with:
http://krcko.net/dlang.org/dlang-home-draft1.png
I'm not entirely satisfied with it but I believe that it looks
be
On 4/17/2014 6:43 AM, Manu via Digitalmars-d wrote:
Well it's still not clear to me what all the challenges are... that's my point.
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
A lot of comments in the "DIP60: @nogc attribute" thread about doing ARC in D
are answered in this earlier thread:
http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the
left-justification seen in the current design. It improves
readability and gives oppor
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism
needs to be
JS-only (and I think any efforts to make the pages largely
JS-driven
would meet resistance).
We can (and proba
On Friday, 18 April 2014 at 15:55:57 UTC, Frustrated wrote:
I like it too. A little cleaner/sharper. A little more
balanced. (centered, colors, etc)
Not a huge improvement in some ways, which is good and bad. The
question is, would the change be worth it? If it's easy to do,
yes, if it caus
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism
needs to be
JS-only (and I think any efforts to make the pages largely
JS-driven
would meet resistance).
We can (and proba
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:
As the guy who was mostly responsible for the current look and
feel of the website I can provide some insight into the effort
required. The website is built using DDoc[1], and anyone who
wants to change the look and feel will need
On Fri, 18 Apr 2014 16:17:10 +, Brad Anderson wrote:
>
> You can actually prevent scanning/collection already without much
> difficulty:
>
> GC.disable();
> scope(exit) GC.enable();
>
> I feel like @nogc is most useful in avoiding surprises by declaring your
> assumptions. Problems like how
On Friday, 18 April 2014 at 14:45:37 UTC, Byron wrote:
On Thu, 17 Apr 2014 11:55:14 +, w0rp wrote:
I'm not convinced that any automatic memory management scheme
will buy
much with real time applications. Generally with real-time
processes,
you need to pre-allocate. I think GC could be feas
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the
left-justification seen in the current design. It improves
readability and gives opportunities for better information
density.
I know centr
On Friday, 18 April 2014 at 14:15:00 UTC, Steven Schveighoffer
wrote:
And an inc/dec may not necessarily need a lock if the array
element is not shared, even if you inc/dec the ref count.
D offers opportunities to go beyond traditional ref count
eliding.
In most situations where you need spe
To be honest, it looks no "better" than the current website. Basically
it's more windows-8-ish. But I don't think it's a significant improvement.
I agree that it's not a significant improvement. As I've said I'm not a
designer,
this was just a try to get something more appealing than the curren
On Friday, 18 April 2014 at 10:06:35 UTC, Manu via Digitalmars-d
wrote:
D pointers are thread-local by default, you need to mark things
'shared'
explicitly if they are to be passed between threads. This is
one of the
great advantages D has over C/C++/Obj-C.
There's nothing special about point
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not
participate much in discussions here, although I read forums
almost daily), and I keep telling people about D and how
awesome it is.
But, all this time D's
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism needs to be
JS-only (and I think any efforts to make the pages largely JS-driven
would meet resistance).
We can (and probably should) integrate server-side scripting as well.
http://dlang.org/b
On 2014-04-18 09:04, Aleksandar Ruzicic wrote:
So, what do you guys think?
i like it.
A complete, "tested" and working proof of concept!
Pipe the output to a file and load it in an editor that allows you to
mess with the size of tabs and no matter what width they have things
will still line up (as long as the font is fixed width).
I'm pretty sure this is sub optimal even thoug
"Aleksandar Ruzicic" schrieb im Newsbeitrag
news:mmoxalewsvwcgeaas...@forum.dlang.org...
But, all this time D's official website somehow archaic look kept
troubling me.
Me too.
I have also tried to design something myself (although I'm not a designer)
and this is what I came up with:
htt
On 4/17/14, 10:09 AM, Walter Bright wrote:
On 4/17/2014 2:32 AM, Paulo Pinto wrote:
Similar approach was taken by Microsoft with their C++/CX and COM
integration.
So any pure GC basher now uses Apple's example, with a high
probability of not
knowing the technical issues why it came to be like t
On 4/18/14, 7:22 AM, Steven Schveighoffer wrote:
On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not
participate much in discussions here, although I read forums almost
daily), and I keep telling people about D and
On Mon, 24 Mar 2014 09:43:50 -0400, Steven Schveighoffer
wrote:
BTW, for anyone who is interested, I created a mail filter with the
following rules, and it has worked since then to remove all the commits
from the mailing list feed:
Deliver to "Trash" if
Sender contains "nore...@gi
On Thu, 17 Apr 2014 11:55:14 +, w0rp wrote:
> I'm not convinced that any automatic memory management scheme will buy
> much with real time applications. Generally with real-time processes,
> you need to pre-allocate. I think GC could be feasible for a real-time
> application if the GC is preci
On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not participate
much in discussions here, although I read forums almost daily), and I
keep telling people about D and how awesome it is.
Great!
But, all this t
On Fri, 18 Apr 2014 10:00:21 -0400, Ola Fosheim Grøstad
wrote:
On Friday, 18 April 2014 at 12:55:59 UTC, Steven Schveighoffer wrote:
The important thing to recognize is that it's the *caller* that
increments/decrements. This means you can elide calls to an object
where you already have a
Hello,
I've been D enthusiast for couple of years now (but I do not
participate much in discussions here, although I read forums
almost daily), and I keep telling people about D and how awesome
it is.
But, all this time D's official website somehow archaic look kept
troubling me. It reminds
On Friday, 18 April 2014 at 12:55:59 UTC, Steven Schveighoffer
wrote:
The important thing to recognize is that it's the *caller* that
increments/decrements. This means you can elide calls to an
object where you already have a guarantee of its reference
count being high enough.
That won't help
On Fri, 18 Apr 2014 01:53:00 -0400, Walter Bright
wrote:
On 4/17/2014 6:58 PM, Michel Fortin wrote:
Auto-nulling weak references are perfectly memory-safe. In Objective-C
you use
the __weak pointer modifier for that. If you don't want it to be
auto-nulling,
use __unsafe_unretained instea
On Thu, 17 Apr 2014 18:52:10 -0400, Walter Bright
wrote:
On 4/17/2014 3:18 PM, Steven Schveighoffer wrote:
During the entire processing, you never increment/decrement a reference
count,
because the caller will have passed data to you with an incremented
count.
Just because ARC protects
On Friday, 18 April 2014 at 10:06:35 UTC, Manu via Digitalmars-d
wrote:
D pointers are thread-local by default, you need to mark things
'shared'
explicitly if they are to be passed between threads. This is
one of the
great advantages D has over C/C++/Obj-C.
TLS sucks, as you get extra indirec
On 04/18/2014 10:50 AM, bearophile wrote:
Honestly, I think expecting that code to be allowed to use @nogc is a
huge mistake and disagree with editing the DIP to include this solely
because you decided it should.
That Wiki page is editable, so if it's wrong it takes one minute to fix
the text
On 18 April 2014 20:10, Tove via Digitalmars-d
wrote:
> On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d wrote:
>
>> On 18 April 2014 04:10, Kagamin via Digitalmars-d <
>> digitalmars-d@puremagic.com> wrote:
>>
>> On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via Digitalmars-d
On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d
wrote:
On 18 April 2014 04:10, Kagamin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via
Digitalmars-d wrote:
void f(void* ptr)
{
// was ptr allocated with malloc, or
On 18 April 2014 16:16, via Digitalmars-d wrote:
> On Friday, 18 April 2014 at 00:11:28 UTC, H. S. Teoh via Digitalmars-d
> wrote:
>
>> I thought that whole point of *A*RC is for the compiler to know when ref
>> count updates can be skipped? Or are you saying this is algorithmically
>> undecidable
On 17 April 2014 18:35, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 4/16/2014 8:13 PM, Manu via Digitalmars-d wrote:
>
>> On 17 April 2014 03:37, Walter Bright via Digitalmars-d
>> mailto:digitalmars-d@puremagic.com>> wrote:
>> ARC has very serious problems with
On Friday, 18 April 2014 at 06:50:48 UTC, Brad Anderson wrote:
On Friday, 18 April 2014 at 06:35:33 UTC, Walter Bright wrote:
On 4/17/2014 9:23 PM, Brad Anderson wrote:
Would @nogc apply to code being evaluated at compile-time? I
don't think it should.
Yes, it would be. Compile time functions
PS
I discovered that core.bitop.bts() won't accept a pointer to immutable
even when inside a static this. Not sure if that counts as a bug or not ><
Kapps:
Flags such as -O are specifically not supposed to change
program behaviour. This being the case would completely discard
that and allow code to be compiled only with a single compiler.
OK.
Honestly, I think expecting that code to be allowed to use
@nogc is a huge mistake and disagre
I tested this against the others...
(with "-inline -release -O" of course)
===
uint[8] tab4; // bitop function only work on uints
static this()
{
for (size_t u = 0; u < 0x100; ++u)
{
if (isIdentifierChar0(cast(ubyte)u))
{
bts(tab4.ptr, u);
}
}
}
b
On Friday, 18 April 2014 at 01:07:40 UTC, bearophile wrote:
Kapps:
That code is not @nogc safe, as you're creating a dynamic
array within it. The fact that LDC2 at full optimizations
doesn't actually allocate is simply an optimization and does
not affect the design of the code.
I've added t
On 17/04/2014 8:20 PM, matovitch wrote:
You are doing it all wrong. The easiest way to compute
the col position is the following :
col_pos = 0;
if (non_tab_character_encounter)
col_pos++;
else
col_pos += tab_length - col_pos % tab_length;
That's it.
Tabs can have variable widths
On 17/04/2014 8:41 PM, monarch_dodra wrote:
On Thursday, 17 April 2014 at 18:07:24 UTC, ixid wrote:
I feel like there must be a way of making a fast bit look up but my
version is only moderate in speed. You can get all the bits you need
on two 64 bit registers or one SSE register. I haven't trie
On 4/17/2014 11:50 PM, Brad Anderson wrote:
But surely something like:
struct S
{
this(int d) { data = d; }
S opBinary(string op)(S rhs) @nogc
{
return S(mixin("data "~op~" rhs.data"));
}
private int data;
}
Would still work, right? There is no GC activity
On Friday, 18 April 2014 at 06:16:29 UTC, Ola Fosheim Grøstad
wrote:
But how can you let the compiler know that you have protected
the array so only one thread will take processing-ownership
during the life span of the function call?
Btw, Rust apparently uses ARC for immutable data only.
94 matches
Mail list logo
