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 are not special, in
fact, there is no such thing in D.
But s
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 are not special, in fact, there is no
such thing in D.
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 in the compiler?
Multithreading cause major problems. A fu
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 instead to get a raw pointer. In general, seeing
__unsafe_unretained in
On Friday, 18 April 2014 at 00:31:20 UTC, FrankLIKE wrote:
Thank you,I think 'use uint' is better than 'use ulong' .
You know that 'point.x,point.y' is int ,on x64 ,no change,
'length' keeps the same to 'point.x,point.y' ,maybe a good
thing.
Frank.
You are only supposed to use `size_t` (and
On 4/17/2014 7:24 PM, H. S. Teoh via Digitalmars-d wrote:
So what are some optimizations that compilers *are* currently able to
do, and what currently isn't done?
Just look at all the problems with "escape analysis" being done with compilers.
On Thursday, 17 April 2014 at 22:10:00 UTC, Walter Bright wrote:
That pretty much kills it, even at 10%.
It probably is better than C++ shared_ptr though... D can
probably do better than objective-c with whole program
compilation, since the dynamic aspects of objective-c methods are
challen
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Would @nogc apply to code being evaluated at compile-time? I
don't think it should.
On Thursday, 17 April 2014 at 21:30:04 UTC, Nick Sabalausky wrote:
On 4/17/2014 8:51 AM, Steven Schveighoffer wrote:
Every time I open one of these messages I
get a huge pregnant 5-second pause, along with the Mac Beach
Ball
(hourglass) while this message is opened in my news reader.
Sounds
On Thu, Apr 17, 2014 at 05:34:34PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/17/2014 5:09 PM, 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 unde
On Thursday, 17 April 2014 at 10:10:34 UTC, Brad Roberts via
Digitalmars-d wrote:
According to the modification history for that bug, you
reopened it back on May 4, 2009. Walter merely changed the
version id recently from 1.041 to D1.
https://issues.dlang.org/show_activity.cgi?id=2757
Why
On 2014-04-17 17:29:02 +, Walter Bright said:
On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote:
People who care would go to the effort of manually marking weak references.
And that's not compatible with having a guarantee of memory safety.
Auto-nulling weak references are perfectly m
It's the same in C and it reflects what the hardware is doing
underneath with regard to memory addresses. That's the point of
size_t. If it didn't change size then we'd all just use ulong
or uint for all our array lengths etc.
In c#,add the new attribute 'longlength' on the new version,keep
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 the opposite of what you say in the DIP. So Walter can
fix it
On 4/17/2014 5:09 PM, 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 in the compiler?
I don't think anyone has produced a "sufficiently smart compile
On Thursday, 17 April 2014 at 16:46:15 UTC, John Colvin wrote:
On Thursday, 17 April 2014 at 16:36:29 UTC, FrankLike wrote:
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must
cast to int or cast to uint
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.
Walter has answered to another person:
The @nogc will tell you if it wil
On Thu, Apr 17, 2014 at 03:52:10PM -0700, Walter Bright via Digitalmars-d 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.
> >
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 new?
>>
>
> Then what?
>
Whatever. inc/dec ref, or not. core.me
On Thursday, 17 April 2014 at 09:46:23 UTC, bearophile wrote:
Walter Bright:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
If I have this program:
__gshared int x = 5;
int main() {
int[] a = [x, x + 10, x * x];
return a
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 the data, doesn't mean you need to constantly and
needlessly incre
On Thu, 17 Apr 2014 18:08:43 -0400, Walter Bright
wrote:
On 4/17/2014 1:53 PM, Steven Schveighoffer wrote:
OK, you beat it out of me. I admit, when I said "Video
processing/players with
network capability" I meant all FILE * I/O, and really nothing to do
with video
processing or networki
On 4/17/2014 1:53 PM, Steven Schveighoffer wrote:
OK, you beat it out of me. I admit, when I said "Video processing/players with
network capability" I meant all FILE * I/O, and really nothing to do with video
processing or networking.
I would expect that with a video processor, you aren't deal
On 4/17/2014 1:46 PM, "Ola Fosheim Grøstad"
" wrote:
Apple has put a lot of resources into ARC. How much slower than manual RC
varies, some claim as little as 10%, others 30%, 50%, 100%.
That pretty much kills it, even at 10%.
On 4/17/2014 1:03 PM, John Colvin wrote:
E.g. you can implement some complicated function foo that writes to a
user-provided output range and guarantee that all GC usage is in the control of
the caller and his output range.
As mentioned elsewhere here, it's easy enough to do a unit test for thi
On 4/17/2014 8:51 AM, Steven Schveighoffer wrote:
Every time I open one of these messages I
get a huge pregnant 5-second pause, along with the Mac Beach Ball
(hourglass) while this message is opened in my news reader.
Sounds like something's wrong with your news reader.
On Thu, 17 Apr 2014 17:29:47 -0400, Nick Sabalausky
wrote:
On 4/17/2014 8:51 AM, Steven Schveighoffer wrote:
Every time I open one of these messages I
get a huge pregnant 5-second pause, along with the Mac Beach Ball
(hourglass) while this message is opened in my news reader.
Sounds like
On 4/17/2014 12:36 PM, FrankLike wrote:
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must cast to
int or cast to uint. It will be waste of time ,I think.
If you want fixed-length, you use uint
On Thursday, 17 April 2014 at 20:46:57 UTC, Ola Fosheim Grøstad
wrote:
But compiled Objective-C code looks "horrible" to begin with…
so I am not sure how well that translates to D.
Just to make it clear: ARC can make more assumptions than manual
Objective-C calls to retain/release. So ARC bein
On Thu, 17 Apr 2014 16:47:04 -0400, Walter Bright
wrote:
On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
I'm not saying it's costless. I'm saying the cost is something I didn't
notice
performance-wise.
You won't with FILE*, as it is overwhelmed by file I/O times. Same with
UI objects
On Thursday, 17 April 2014 at 19:55:08 UTC, Walter Bright wrote:
I know that with ARC the compiler inserts the code for you.
That doesn't make it costless.
No, but Objective-C has some overhead to begin with, so it
matters less. Cocoa is a very powerful framework that will do
most of the weig
On 4/17/2014 1:30 PM, Steven Schveighoffer wrote:
I'm not saying it's costless. I'm saying the cost is something I didn't notice
performance-wise.
You won't with FILE*, as it is overwhelmed by file I/O times. Same with UI
objects.
On Thu, 17 Apr 2014 15:55:10 -0400, Walter Bright
wrote:
On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright
wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C
On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright
wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any GC-tr
1986 - Brad Cox and Tom Love create Objective-C, announcing "this
language has all the memory safety of C combined with all the
blazing speed of Smalltalk." Modern historians suspect the two
were dyslexic.
(
http://james-iry.blogspot.no/2009/05/brief-incomplete-and-mostly-wrong.html
)
On 4/17/2014 12:41 PM, Steven Schveighoffer wrote:
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright
wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
An
On 4/17/2014 10:41 AM, Dicebot wrote:
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
With current limitations @nogc is only useful to verify that embedded code which
does not have GC at all does not use any GC-triggering language features before
it comes to weird linker errors
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 tried bt, does that work with a 64 bit register
On Thu, 17 Apr 2014 14:47:00 -0400, Walter Bright
wrote:
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C objects, which all
use RC.
And what about all allocated items?
What do you m
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.
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
On 4/17/2014 10:05 AM, Steven Schveighoffer wrote:
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C objects, which all use RC.
And what about all allocated items?
A UI is a good use case for ARC. A UI doesn't require high performance.
I'
On Thursday, 17 April 2014 at 18:26:25 UTC, Dicebot wrote:
I think for your scenario having dedicated @nogc threads makes
more sense, this can be built on top of plain function
attribute @nogc.
Yes, that could be a life saver. Nothing is more annoying than
random crashes due to concurrency is
On Thursday, 17 April 2014 at 18:18:49 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
Such weak @nogc could help to avoid triggering allocations by
an accident and encourage usage of output ranges / buffers.
Ok, more like a "lintish" feature of the "
On Thursday, 17 April 2014 at 18:00:25 UTC, Dicebot wrote:
Such weak @nogc could help to avoid triggering allocations by
an accident and encourage usage of output ranges / buffers.
Ok, more like a "lintish" feature of the "remind me if I use too
much of feature X in these sections" variety.
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 new?
Then what?
On Thursday, 17 April 2014 at 14:59:14 UTC, Steven Schveighoffer
wrote:
I don't think this is a viable mechanism to check pointers.
It's too slow.
I suggested to write a smart pointer. It could provide
compile-time checks and whatever developer feels like.
On Thu, Apr 17, 2014 at 03:16:20PM +, CJS via Digitalmars-d wrote:
> On Monday, 17 March 2014 at 21:25:34 UTC, bearophile wrote:
> >Jared Miller:
> >
> >>And yes, I think that a matrix / linear algebra library, as well as
> >>NumPy-style ND-Arrays are great candidates for future Phobos
> >>modu
On Thursday, 17 April 2014 at 16:27:26 UTC, Alix Pexton wrote:
I added a lookup scheme of my own, its not as fast as Walters
(in fact its the slowest without -inline - release -O) but it
uses 1 bit per entry in the table instead of a whole byte so
you can have lots and lots of different tables.
On Thursday, 17 April 2014 at 17:48:39 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
put() may call GC to grow the buffer, this is the very point.
What is desired is to check if anything _else_ does call GC,
thus the "weak @nogc" parallel.
What do
On Thursday, 17 April 2014 at 12:38:24 UTC, Steven Schveighoffer
wrote:
I actually am ignorant of how this works under the hood for
slices, what triggers element-wise copy vs. assign.
The compiler compiles whatever compiles. Currently only one
mistake (type) is required to compile the wrong th
On Thursday, 17 April 2014 at 15:49:44 UTC, Dicebot wrote:
put() may call GC to grow the buffer, this is the very point.
What is desired is to check if anything _else_ does call GC,
thus the "weak @nogc" parallel.
What do you need that for?
Of course, resorting to templates requires some
thi
On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright wrote:
With current limitations @nogc is only useful to verify that
embedded code which
does not have GC at all does not use any GC-triggering
language features before
it comes to weird linker errors / rt-asserts. But that does
not work
Walter Bright:
I know that you bring up the array literal issue and gc a lot,
but this is simply not a major issue with @nogc. The @nogc will
tell you if it will allocate on the gc or not, on a case by
case basis, and you can use easy workarounds as necessary.
Assuming you have seen my examp
On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote:
People who care would go to the effort of manually marking weak references.
And that's not compatible with having a guarantee of memory safety.
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 that.
I also wish to reiterate that GC's us
On Thu, 17 Apr 2014 04:35:34 -0400, Walter Bright
wrote:
On 4/16/2014 8:13 PM, Manu via Digitalmars-d wrote:
I've never heard of Obj-C users complaining about the inc/dec costs.
Obj-C only uses ARC for a minority of the objects.
Really? Every Obj-C API I've seen uses Objective-C obje
On 4/17/2014 8:02 AM, Dicebot wrote:
=== Problem #1 ===
First problem is that, by an analogy with `pure`, there is no such thing as
"weakly @nogc@". A common pattern for performance intensive code is to use
output buffers of some sort:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo
On 4/17/2014 9:42 AM, monarch_dodra wrote:
That said, your proposal could be applied for all attributes in general. Not
just @nogc in particular. In practice though, a simple unittest should cover all
your needs. simply create a @nogc (pure, nothrow, safe, ctfe-able) unitest, and
call it with a t
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 bloat and performance.
This is the first I've heard of it, and I've been going on about it for ages.
Con
On Thursday, 17 April 2014 at 16:36:29 UTC, FrankLike wrote:
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must
cast to int or cast to uint. It will be waste of time ,I think.
It's the same in C and
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
=== Problem #1 ===
First problem is that, by an analogy with `pure`, there is no
such thing as "weakly @nogc@". A common pattern for performance
intensive code is to use output buffers of some sort:
void foo(OutputRange buffer)
{
@nogc
module mymodule;
This is precisely what I had in mind.
Size_t on x86 is uint,on x64 is ulong,it's a good thing?
I don't think is ok.
it creates many convert thing,such as length is ulong ,must
cast to int or cast to uint. It will be waste of time ,I think.
I added a lookup scheme of my own, its not as fast as Walters (in fact
its the slowest without -inline - release -O) but it uses 1 bit per
entry in the table instead of a whole byte so you can have lots and lots
of different tables. I'm even reasonably sure that it works correctly!
==
On Wednesday, 16 April 2014 at 13:59:15 UTC, Bienlein wrote:
Being able to spawn as many thousand threads as needed without
caring about it seems to be an important aspect for being an
interesting offering for developing server-side software. It
would be nice if D could also play in that niche.
Just fixing an obvious typo in my code (that is still incomplete).
struct someRange
{
ulong seq;
bool fresh = true;
long line;
dchar front;
// and lets just pretend that there is
// somewhere for more characters to come from!
void popFront()
{
// adva
On Thursday, 17 April 2014 at 15:48:29 UTC, bearophile wrote:
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is n
On Thursday, 17 April 2014 at 15:39:38 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo` can't be @nogc here if OutputRange uses GC as backing
allocator. However I'd really like to use it to veri
Ola Fosheim Grøstad:
Where this falls apart is when you introduce a compacting GC
and the @nogc code is run in a real time priority thread. Then
you need both @nogc_function_calls and @nogc_memory .
Perhaps the @nogc proposal is not flexible enough. So probably
the problem needs to be looked
On 4/17/14, Steven Schveighoffer via Digitalmars-d
wrote:
> It's on the bug page. Look after the "Modified" field at the top.
Ah the "History" link. Thanks.
On Thursday, 17 April 2014 at 15:02:27 UTC, Dicebot wrote:
void foo(OutputRange buffer)
{
buffer.put(42);
}
`foo` can't be @nogc here if OutputRange uses GC as backing
allocator. However I'd really like to use it to verify that no
Can't you write foo as a template? Then if "buffer" is a r
On Monday, 17 March 2014 at 21:25:34 UTC, bearophile wrote:
Jared Miller:
And yes, I think that a matrix / linear algebra library, as
well as NumPy-style ND-Arrays are great candidates for future
Phobos modules.
I suggest to not put such library in Phobos before few years of
usage in the wi
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
OK, a bit late to the thread, seeing how it has already went to
ARC off-topic domain :( An attempt to get back to the o
On Thu, 17 Apr 2014 10:52:19 -0400, Timon Gehr wrote:
On 04/17/2014 08:55 AM, Manu via Digitalmars-d wrote:
If an API
could be provided in druntime, it may be used by GC's, ARC, allocators,
or systems that operate at the barrier between languages.
There already is.
bool isGCPointer(void*
On 04/17/2014 08:55 AM, 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.
Is this is a problem
On Thu, 17 Apr 2014 10:12:20 -0400, Andrej Mitrovic via Digitalmars-d
wrote:
On 4/17/14, Brad Roberts via Digitalmars-d
wrote:
According to the modification history for that bug
Btw, that's the first time I saw that page, and I always wanted this
feature. But, where is it linked from? (h
On Thursday, 17 April 2014 at 13:43:17 UTC, Manu via
Digitalmars-d wrote:
You would never allocate in a ray tracing loop. If you need a
temp, you
would use some pre-allocation strategy.
Path-tracing is predictable, but regular ray tracing may spawn
many rays per hit. So you pre-allocate a buf
On 04/17/2014 02:34 PM, Manu via Digitalmars-d wrote:
On 17 April 2014 21:57, John Colvin via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d
wrote:
ARC offers a solution that is usable by all parties.
On 4/17/14, Brad Roberts via Digitalmars-d wrote:
> According to the modification history for that bug
Btw, that's the first time I saw that page, and I always wanted this
feature. But, where is it linked from? (how did you find it?)
I should probably have said heap allocation rather than just
allocation, because the alloca calls are the ones that would have the
real benefit, those realtime applications are the reason I hope to be
able to implement an async collection mode. If I were able to
implement even a moderately compacti
On 17 April 2014 23:14, Orvid King via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I think the biggest advantage to this distinction would really be the
> cross-language API's, the GC can determine which pointers it owns,
> although I don't believe it currently exposes this capability.
>
On 17 April 2014 23:17, via Digitalmars-d wrote:
> On Thursday, 17 April 2014 at 12:20:06 UTC, Manu via Digitalmars-d wrote:
>
>> See, I just don't find managed memory incompatible with 'low level'
>> realtime or embedded code, even on tiny microcontrollers in principle.
>>
>
> RC isn't incompatib
On Wed, 16 Apr 2014 18:38:23 +0100, Walter Bright
wrote:
On 4/16/2014 8:01 AM, qznc wrote:
However, what is still an open issue is that @nogc can be stopped by
allocations
in another thread. We need threads which are not affected by
stop-the-world. As
far as I know, creating threads via p
On Thu, 17 Apr 2014 14:08:29 +0100, Orvid King via Digitalmars-d
wrote:
I'm just going to put my 2-cents into this discussion, it's my
personal opinion that while _allocations_ should be removed from
phobos wherever possible, replacing GC usage with manual calls to
malloc/free has no place in
On Thursday, 17 April 2014 at 12:20:06 UTC, Manu via
Digitalmars-d wrote:
See, I just don't find managed memory incompatible with 'low
level' realtime or embedded code, even on tiny microcontrollers
in principle.
RC isn't incompatible with realtime, since the overhead is O(1).
But it is slowe
I think the biggest advantage to this distinction would really be the
cross-language API's, the GC can determine which pointers it owns,
although I don't believe it currently exposes this capability.
On 4/17/14, Manu via Digitalmars-d wrote:
> On 17 April 2014 18:20, Kagamin via Digitalmars-d <
>
On 17 April 2014 22:28, Michel Fortin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 2014-04-17 03:13:48 +, Manu via Digitalmars-d <
> digitalmars-d@puremagic.com> said:
>
> Obviously, a critical part of ARC is the compilers ability to reduce
>> redundant inc/dec sequences. At w
I'm just going to put my 2-cents into this discussion, it's my
personal opinion that while _allocations_ should be removed from
phobos wherever possible, replacing GC usage with manual calls to
malloc/free has no place in the standard library, as it's quite simply
a mess that is really not needed,
This is very very annoying. Every time I open one of these messages I get
a huge pregnant 5-second pause, along with the Mac Beach Ball (hourglass)
while this message is opened in my news reader.
Whatever this is, can we get rid of it?
-Steve
On Wed, 16 Apr 2014 04:05:57 -0400, Kagamin wrote:
On Tuesday, 15 April 2014 at 15:59:31 UTC, Steven Schveighoffer wrote:
Requiring it simply adds unneeded hoops through which you must jump,
the left hand side denotes the operation, the right hand side does not
Unfortunately, this particula
On 17 April 2014 18:20, Kagamin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> You can do anything, what fits your task, see RefCounted and Unique for an
> example on how to write smart pointers.
>
... what?
I don't think you understood my post.
void f(void* ptr)
{
// was ptr alloc
On 17 April 2014 21:57, John Colvin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d wrote:
>
>> ARC offers a solution that is usable by all parties.
>>
>
> Is this a proven statement?
>
> If that paper is right then ARC w
On Wed, 16 Apr 2014 02:59:29 -0400, Steve Teale
wrote:
On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote:
Sorry, I had this wrong. The [] on the left hand side is actually part
of the []= operator. But on the right hand side, it simply is a []
operator, not tied to th
On 2014-04-17 03:13:48 +, Manu via Digitalmars-d
said:
Obviously, a critical part of ARC is the compilers ability to reduce
redundant inc/dec sequences. At which point your 'every time' assertion is
false. C++ can't do ARC, so it's not comparable.
With proper elimination, transferring owne
On Wed, 16 Apr 2014 12:09:49 -0400, sclytrack wrote:
On Saturday, 14 December 2013 at 15:16:50 UTC, Jacob Carlborg wrote:
On 2013-12-14 15:53, Steven Schveighoffer wrote:
I realize this is really old, and I sort of dropped off the D cliff
because all of a sudden I had 0 extra time.
But I am
On 17 April 2014 18:52, via Digitalmars-d wrote:
> On Thursday, 17 April 2014 at 08:22:32 UTC, Paulo Pinto wrote:
>
>> Of course it was sold at WWDC as "ARC is better than GC" and not as "ARC
>> is better than the crappy GC implementation we have done".
>>
>
> I have never seen a single instance o
On Wed, 16 Apr 2014 13:39:36 -0400, Walter Bright
wrote:
On 4/16/2014 1:49 AM, "Ola Fosheim Grøstad"
" wrote:
Btw, I think you should add @noalloc also which prevents both new and
malloc. It
would be useful for real time callbacks, interrupt handlers etc.
Not practical. malloc() is only
On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via
Digitalmars-d wrote:
ARC offers a solution that is usable by all parties.
Is this a proven statement?
If that paper is right then ARC with cycle management is in fact
equivalent to Garbage Collection.
Do we have evidence to the contrary?
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 precise and
collections are scheduled, instead of run rand
1 - 100 of 119 matches
Mail list logo
