Am 09.01.2014 15:28, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>":
> And, if it isn't in D already I would very much like to have a weak
> pointer type that will be set to null if the object is only pointed to
> by weak pointers.
>
> It is a PITA to have objects die and get them out of a bunch of
> event-queues etc.

Didn't phobos get such a weak pointer type lately? I at least saw a implementation on the newsgroup very recently.

It used core.memory.setAttr to store information in objects. Then you can overwrite the collectHandler in core.runtime to null the weak references up destruction.

-- 
Kind Regards
Benjamin Thaut

On Thursday, 9 January 2014 at 14:40:16 UTC, Paulo Pinto wrote:
> On a game you might miss a few rendering frames, a GC induced
> delay on a missile tracking system might turn out a bit ugly.

You have GC in games, but you limit it to a small set of objects (<50000?)
So you can have real time with GC with an upper-bound.

Putting everything under GC is probably not a future proof concept, since memory capacity most likely will increase faster than CPU speed for technical reasons.

> However, unless you target systems without an OS, you'll have anyway the OS making whatever it wants with the existing cores.

Yes, but you don't blame the application if the scheduler isn't real time friendly. Linux has been a been kind of bad, because distributions have been focused on servers. But you find real time friendly schedulers too.

On Thu, Jan 9, 2014 at 7:11 AM, Manu <turkeyman@gmail.com> wrote:

> You're making a keen assumption here that C programmers use STL. And no sane programmer that I've ever worked with uses STL precisely for this reason :P


I think this sentence is misleading. I've made high performance application
with no copy with the STL. Your "sane programmers" are just people who
don't want to learn it.
Sane programemrs make sure they know the strengh and pitfalls of their
tools. They don't avoid tools because they make incorrect assomptions, like
you are doing here.
Also, this have nothing to do with STL.

On Thursday, 9 January 2014 at 14:57:31 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 9 January 2014 at 14:40:16 UTC, Paulo Pinto wrote:
>> On a game you might miss a few rendering frames, a GC induced
>> delay on a missile tracking system might turn out a bit ugly.
>
> You have GC in games, but you limit it to a small set of objects (<50000?)
> So you can have real time with GC with an upper-bound.
>
> Putting everything under GC is probably not a future proof concept, since memory capacity most likely will increase faster than CPU speed for technical reasons.
>

Sure. As I mentioned in another thread, the other GC enabled system programming languages I know, also allow for static, global and stack allocation.

And you also have an escape hatch to do manual memory management if you really have to.

Namely Oberon(-2), Component Pascal, Active Oberon, Modula-3, Sing# and Cedar. Just in case you feel like looking any of them up.

While those ended up never being adopted by the industry at large, we can draw lessons from the experience of their users. Positive features and related flaws.

Currently I am digging up the Mesa/Cedar reports from Xerox PARC.

I think D already has the necessary features, their performance just needs to be improved.

--
Paulo

On Thursday, 9 January 2014 at 00:37:27 UTC, Atila Neves wrote:
> Thanks. Not many votes though given all the downvotes. The comments manage to be even worse than on my first blog post.
>
> For some reason they all assume I don't know C++ even though I know it way better than D, not to mention that they nearly all miss the point altogether. Sigh.

I wonder if someone who "knows" C++ is going to help you out and improve your code, much like others did with the other languages you used.

On Thu, Jan 09, 2014 at 08:40:29AM +0000, digitalmars-d-bounces@puremagic.com wrote:
> On Thursday, 9 January 2014 at 07:07:29 UTC, Walter Bright wrote:
> >and it works without copying in D, it just returns s1. In C, I gotta copy, ALWAYS.
> 
> Only if you write libraries, in an application you can set your own
> policies (invariants).

Yes, programming by convention, which falls flat as soon as you have a large team on the project, and people don't know your conventions (you'll be surprised how many "seasoned" programmers will just walk all over your code writing what they're used to writing, with no thought to read the code first and figure out how their code might fit in with the rest). I see lots of this at my job, and it inevitably leads to problems, because in C, people just *expect* the usual copying conventions. Sure, if you're a one-man project, then you can remove some of this copying, but rest assured that in a team project things will go haywire, and inevitably you'll end up dictating that everyone must copy everything because that's the only way to guarantee module X, which is written by team B, doesn't do something screwy with our data.


> >(C's strings being 0 terminated also forces much extra copying,
> >but that's another topic.)
> 
> Not if you have your own allocator and split chopped strings (you can just overwrite the boundary character).

You can't do this if the caller still wishes to retain the original string.


> >The point is, no matter how slow the GC is relative to malloc, not allocating is faster than allocating, and a GC can greatly reduce the amount of alloc/copy going on.
> 
> But since malloc/free is tedious c-programmers tend to avoid it by embedding objects in large structs and put a variable sized object at the end of it... Or have their own pool (possibly on the stack at the location where it should be released).
[...]

One thing I miss in D is a nice way to allocate structs with a variable-length "static" array at the end. GCC supports this, probably as an extension (I don't remember if the C standard specifies this). I know I can just manually allocate this via core.gc and casts, but a built-in solution would be really nice.


T

-- 
Sometimes the best solution to morale problems is just to fire all of the unhappy people. -- despair.com

H. S. Teoh:

> One thing I miss in D is a nice way to allocate structs with a
> variable-length "static" array at the end. GCC supports this, probably as an extension (I don't remember if the C standard
> specifies this). I know I can just manually allocate this via
> core.gc and casts, but a built-in solution would be really nice.

Since dmd 2.065 D supports this very well (it was supported in past too, but a less well). See:
http://rosettacode.org/wiki/Sokoban#Faster_Version

Bye,
bearophile

On Thu, Jan 09, 2014 at 09:49:15AM +0000, Paulo Pinto wrote:
> On Thursday, 9 January 2014 at 09:38:31 UTC, Ola Fosheim Grøstad wrote:
> >On Thursday, 9 January 2014 at 09:10:07 UTC, Paulo Pinto wrote:
> >>I have only seen those things work in small AAA class teams.
> >
> >But you have probably seen c programs allocate a bunch of different small structs with a single malloc where it is known that they will be freed in the same location? A compiler needs whole program analysis to do the same.
> >
> >So yes, c programs will have fewer allocs if the programmer cared.
> 
> Yes, I did.
> 
> Not much different than memory pools in Turbo Pascal and Objective-C for that matter.
> 
> And even more strange things, where the whole memory gets allocated at start, then some "handles" are used with mysterious macros to convert back and forth to real pointers.
> 
> I have also seen lots of other storage tricks that go easily out of control when the team either grows over a certain size, or management decides to outsource part of the development or lowering the expected skill set of new team members.
> 
> Then you watch the older guys playing fire brigade to track down issues of release X.Y.Z at customer site, almost every week.
[...]

Exactly!! All these tricks are "possible" in C, but that's what they essentially are: tricks, hacks around the language. You can only keep it up with a small, dedicated core team. As soon as the PTBs decide to hire new grads and move people around, you're screwed, 'cos the old guy who was in charge of the tricky macros is no longer on the team, and nobody else understands how the macros work, and the new guys are under pressure to show contribution, so they barge in making assumptions about how things work -- which usually means naïve C semantics, lots of strcpy's, direct pointer arithmetic, I don't use these weird macros 'cos I don't understand what they do. Result: fire brigade. :-)

This is why compiler-enforced type attributes ultimately trumps any kind of coding convention. It forces everyone to do the Right Thing. This is why strings (arrays) with built-in length is better, because it allows slicing without needing to decide whether you should copy or modify in-place (*someone* will inevitably get it wrong).

C's superiority is keyed on the programmer being perfect -- the philosophy of the language is to trust the programmer, to believe that the programmer knows what he's doing. Theoretically speaking, this is a good thing, because the compiler won't stand in your way and annoy you when you're trying to do something clever. (This is also what made me like C in the first place -- I was 19 at the time, so it figures. :-P) Unfortunately, in practice, humans are fallible -- very much fallible and error-prone -- so this philosophy only leads to pain and more pain. With a single-person project you can still somewhat maintain some semblance of order. But when you have a team of 15+ programmers (at my job we have up to 50), then it's total chaos, and you start to code by paranoia, i.e,, assume everyone else will screw up and add every possible safeguard you can think of in your part of the code, so that when things go wrong it's not your fault. Which means every string modification requires copying, which means performance is out the window. It means adding layers of indirection to shield your code from the outside world. Which means even more pointers to work with, which in turn means you start getting into pointer management problems, and start needing reference counting (which, as I described in an earlier post, people *still* screw up). At some point, you start wishing C had a GC to clean up the mess.


T

-- 
Public parking: euphemism for paid parking. -- Flora

On 1/9/2014 2:46 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 9 January 2014 at 09:58:24 UTC, Walter Bright wrote:
>> Please explain how this can work passing both string literals and allocated
>> strings to cat().
>
> By having your own string allocator that tests for membership when you free (if
> you allow free and foreign strings in your cat)?

How does that work when you pass it "hello"? allocated with malloc()? basically any data that has mixed ancestry?

Note that your code doesn't always have control over this - you may have written a library intended to be used by others, or you may be calling a library written by others.


>> How do you return a string that is the path part of a path/filename? (The
>> terminating 0 is not a problem solved by creating your own allocator.)
> If you discard the original you split at '/'.

That doesn't work if you pass a string literal, or if you are not the owner of the data.


> If you use your own
> stringallocator you don't have to worry about free... You either let the garbage
> remain until the pool is released or have a separate allocation structure that
> allows internal splits (no private size info before first char).

That doesn't work if you're passing strings with mixed ancestry.

On 1/9/2014 3:40 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 9 January 2014 at 09:55:42 UTC, Walter Bright wrote:
>> A GC does not prevent such techniques.
>
> No, but programmers gravitate towards less work... If alloc is transparent and
> free is hidden... You gain a lot from not being explicit, but you get more
> allocations overall.


GC doesn't even make those techniques harder.

I can't see any merit to the idea that GC makes for excessive allocation.