That would be the easiest thing, yeah. I had some more complex ideas in the concurrency list, but dunno if they're practical.

Sent from my iPhone

On Aug 30, 2011, at 5:37 PM, dsimcha <dsimcha@yahoo.com> wrote:

> On 8/30/2011 8:01 PM, Sean Kelly wrote:
>> I'd like to say that the 'shared' attribute on member functions should just mean "make this member visible through a shared reference"
> 
> So the idea would just be that shared is a programmer-verified seal of approval that "yes, this is thread-safe without the user of the object taking any additional precautions"?
> 

Am 30.08.2011 08:00, schrieb Andrei Alexandrescu:
> On 8/30/11 12:45 AM, Benjamin Thaut wrote:
>> Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
>>> On 8/29/11 4:36 PM, Walter Bright wrote:
>>>> On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
>>>>> Certainly, for the common case, adding move constructors is a needless
>>>>> complication, and I'd _very_ leery of the ramifications of the
>>>>> compiler not
>>>>> being able to rely on a move having the bits stay absolutely identical
>>>>> (and a
>>>>> move constructor would make it possible for the struct's state to
>>>>> change
>>>>> completely instead of really being a move). It's not necessarily
>>>>> completely
>>>>> unreasonable, but you appear to have found what I would expect to be a
>>>>> _very_
>>>>> abnormal use-case.
>>>>
>>>> Andrei and I have talked about adding move constructors, but I agree
>>>> with you that it really seems to be a tar pit we'd really like to
>>>> avoid.
>>>> C++ has a lot of subtle problems caused by supporting this, not the
>>>> least of which is efficiency problems.
>>>
>>> The language semantics make move construction unnecessary. Values are
>>> moveable as bits through memory.
>>>
>>> I think the article is a bit confused on this particular matter. Only
>>> objects with value semantics are freely moveable, so they have no direct
>>> interaction with the garbage collector. What they might want to do is to
>>> hold a pointer/reference _inside_ of them and deregister that pointer
>>> with the garbage collector with the destructor. Due to the indirection,
>>> it doesn't matter where the object is in memory.
>>>
>>>
>>> Andrei
>>
>> I don't see implementing a GC as that of a abnormal use case.
>
> Implementing a GC is an exceedingly rare privilege.
>
>> Especially
>> given the fact that D is a garbage collected language and could benefit
>> a lot from features that make implementing a GC easier.
>
> I don't believe D should be in the business of adding features that make
> implementing a GC easier. Such a task is extremely specialized; if the
> language allows it, that's about enough.
>
>> In thise special
>> case the discussed struct would be a wrapper for every reference on the
>> stack, so the references can be tracked by the GC and changed if
>> neccessary. Adding a level of indirection to every reference would
>> greatly impact performance because it would most likely add yet another
>> cache miss when accessing a reference. I'm very well aware of D's
>> concept of structs. But sometimes this concept is very bad for
>> performance, that is what I wanted to point out. Adding a move
>> constructor which most of the structs won't even use, should be less of
>> a performance impact, then adding another level of indirection.
>
> Clearly adding an extra level of indirection would be harmful, no two
> ways about it. But essentially the object model is what it is: there are
> value types that move, and there are reference types that don't. Deal
> with it. If you need to implement a garbage collector, you can't do it
> with move hooks because they're not provided. In a subtle way it's a
> given, although I totally understand how this or that hook would make
> your work easier. I don't find the complaint valid at all.
>
>
> Andrei

My problem currenlty mostly is, that the current GC takes way more time then the usual 5% slowdown that gets mentioned with most GCs. Thats why I would prefer adding features that would make implementing GCs
a) easier
b) would actually allow do implement a GC that is not a Mark & Sweep
c) faster because they won't have to scan all memory searching for a pointer

Currently there is no way to track the references or pointers on the stack because the language does not include such a feature, nor can it be build with any of the language provided mechanisms.

But maybe its just my point of view on this. In the field I'm mostly active in (3d games) performance is everything. Especially on the consoles. Most programmers even sacrifice most c++ features on the consoles (exceptions, RTTI, virtual functions to some extend) just to get more performance out of their game.
-- 
Kind Regards
Benjamin Thaut

Sean Kelly Wrote:

> The unshared methods are only ever meant to be called by the queue owner. They access some member data without synchronization to make the queue efficient for receive calls. I could make these methods shared anyway, but if they were called concurrently by accident it would mean data corruption.

If member data of a shared object is non-shared, it can be probably separated into another object, which will be really unshared. Unshared object can aggregate shared part through alias this if you want to see them as one object.

On Aug 31, 2011, at 11:36 AM, Kagamin wrote:

> Sean Kelly Wrote:
> 
>> The unshared methods are only ever meant to be called by the queue owner. They access some member data without synchronization to make the queue efficient for receive calls. I could make these methods shared anyway, but if they were called concurrently by accident it would mean data corruption.
> 
> If member data of a shared object is non-shared, it can be probably separated into another object, which will be really unshared. Unshared object can aggregate shared part through alias this if you want to see them as one object.

Fair enough.

On 8/28/2011 2:49 PM, Andrei Alexandrescu wrote:
> On 08/28/2011 04:31 PM, dsimcha wrote:
>> On 8/28/2011 5:18 PM, Mafi wrote:
>>>> dynamicCast: Cast a class to another. This should throw something
>>>> derived from Error (not Exception) on failure instead of just returning
>>>> null. If you want null, just use the cast operator. Maybe we should
>>>> change its name, though. How about checkedCast or downCast?
>>>
>>> I think, to!someClass(x) works like you want dynamic cast to work.
>>
>> (Slaps self in forehead.) You're right, I forgot about that. Never mind.
>
> I think such an addition would be worthwhile. We'd only need std.conv.reinterpretCast as that's a distinct way to convert types than to!T. The function would only work if the source and target types have the same size. Some overloads of it would be @safe (e.g. integral or floating point target) whereas others won't (e.g. those that forge pointers or references). Note that reinterpretCast would support conversions not covered by cast, e.g. converting a chunk of memory to a class object or one struct to another struct.
>
> Andrei
I don't know about others, but there's no way in hell that I will ever type "reinterpretCast" in my source code (let alone /import/ std.conv, just for a cast) unless the IDE was the one doing the typing.

On 8/31/2011 9:58 AM, Benjamin Thaut wrote:
> Currently there is no way to track the references or pointers on the stack
> because the language does not include such a feature, nor can it be build with
> any of the language provided mechanisms.

The trouble with precise GC is that all the type info consumes a large amount of memory.

> But maybe its just my point of view on this. In the field I'm mostly active in
> (3d games) performance is everything. Especially on the consoles. Most
> programmers even sacrifice most c++ features on the consoles (exceptions, RTTI,
> virtual functions to some extend) just to get more performance out of their game.

It's fairly straightforward to do the GC collection cycles during slack time, and avoid it during time critical sections.

And note that if you've got hard real time constraints, you cannot even use malloc/free, as they do not run in bounded time.

On Thu, Sep 1, 2011 at 3:23 PM, Walter Bright <newshound2@digitalmars.com> wrote:
>
> And note that if you've got hard real time constraints, you cannot even use malloc/free, as they do not run in bounded time.
>

They're generally avoided in game code anyway because they're slow.

Games don't have hard real time constraints though in the strictest sense, but you have a fixed budget with which to work all game logic and rendering having the GC kick in at the wrong time or run a bit longer than expected can lead to very nasty frame drops. You really need to be able to say when you want the GC to run, and how long you're willing to give it to execute.

On 8/31/2011 10:23 PM, Walter Bright wrote:
> On 8/31/2011 9:58 AM, Benjamin Thaut wrote:
>> Currently there is no way to track the references or pointers on the stack
>> because the language does not include such a feature, nor can it be build with
>> any of the language provided mechanisms.
>
> The trouble with precise GC is that all the type info consumes a large amount of memory.
Hm... how much per what unit? Is that an actual issue nowadays?

On 09/01/2011 12:23 AM, Walter Bright wrote:
> On 8/31/2011 9:58 AM, Benjamin Thaut wrote:
>> Currently there is no way to track the references or pointers on the
>> stack
>> because the language does not include such a feature, nor can it be
>> build with
>> any of the language provided mechanisms.
>
> The trouble with precise GC is that all the type info consumes a large
> amount of memory.

I think our community will be rid of a major hurdle once we get past the debate on whether precise GC is necessary. Precise GC is necessary, there's no two ways about it. We should worry about implementing, not debating, it.

Andrei

On 09/01/2011 12:06 AM, Mehrdad wrote:
> On 8/28/2011 2:49 PM, Andrei Alexandrescu wrote:
>> On 08/28/2011 04:31 PM, dsimcha wrote:
>>> On 8/28/2011 5:18 PM, Mafi wrote:
>>>>> dynamicCast: Cast a class to another. This should throw something
>>>>> derived from Error (not Exception) on failure instead of just
>>>>> returning
>>>>> null. If you want null, just use the cast operator. Maybe we should
>>>>> change its name, though. How about checkedCast or downCast?
>>>>
>>>> I think, to!someClass(x) works like you want dynamic cast to work.
>>>
>>> (Slaps self in forehead.) You're right, I forgot about that. Never mind.
>>
>> I think such an addition would be worthwhile. We'd only need
>> std.conv.reinterpretCast as that's a distinct way to convert types
>> than to!T. The function would only work if the source and target types
>> have the same size. Some overloads of it would be @safe (e.g. integral
>> or floating point target) whereas others won't (e.g. those that forge
>> pointers or references). Note that reinterpretCast would support
>> conversions not covered by cast, e.g. converting a chunk of memory to
>> a class object or one struct to another struct.
>>
>> Andrei
> I don't know about others, but there's no way in hell that I will ever
> type "reinterpretCast" in my source code (let alone /import/ std.conv,
> just for a cast) unless the IDE was the one doing the typing.

Verboseness would be the last problem of a program needing many instances of reinterpretCast.

Andrei