On Thursday, 9 January 2014 at 00:52:04 UTC, H. S. Teoh wrote:
> On Wed, Jan 08, 2014 at 11:59:58PM +0000, digitalmars-d-bounces@puremagic.com wrote:
>> On Wednesday, 8 January 2014 at 23:43:43 UTC, NoUseForAName wrote:
> [...]
>> >(I am not part of that majority, though). I mean C gave us
>> >classics like "atoi".. still reminds me of "ahoi" every time I
>> >read it. And I will never get over C++'s "cout" and "cin". See?
>
> The absolute worst offender from the C days was creat(). I mean,
> seriously?? I'm actually a fan of abbreviated names myself, but that one
> simply takes it to a whole 'nother level of wrong.
>
>
>> I don't mind cout, I hardly use cin, I try to avoid cerr, and I've
>> never used clog… I mind how you configure iostreams though. It looks
>> worse than printf, not sure how they managed that.
> [...]
>
> I hate iostream with a passion.

I am on the other side of the fence, enjoying iostream since 1994. :)

--
Paulo

On Wednesday, 8 January 2014 at 23:59:59 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 January 2014 at 23:43:43 UTC, NoUseForAName wrote:
>> Looks pretty boring/conventional to me. If you know many programming languages you immediately recognize "let" as a common keyword for assignment.
>
> Yes, but I cannot think of a single one of them that I would like to use! ;-)
>
>> That leaves only the funny sounding "mut" as slightly unusual. It is the result of making immutable the default which I think is a good decision.
>
> Agree on the last point, immutable should be the default. Altough I think they should have skipped both "let" and "mut" and used a different symbol for initial-assignment instead.
>
>> (I am not part of that majority, though). I mean C gave us classics like "atoi".. still reminds me of "ahoi" every time I read it. And I will never get over C++'s "cout" and "cin". See?
>
> I don't mind cout, I hardly use cin, I try to avoid cerr, and I've never used clog… I mind how you configure iostreams though. It looks worse than printf, not sure how they managed that.
>
>> Rust makes C/C++ damaged people feel right at home even there ;P
>
> Well, I associate "let" with the functional-toy-languages we created/used at the university in the 90s so I kind of have problem taking Rust seriously. And the name? RUST? Decaying metal. Why? It gives me the eerie feeling that the designers are either brilliant, mad or both, or that it is a practical joke. I'm sure the compiler randomly tells you Aprils Fools! Or something.

You mean the toy languages that are slowly replacing C++ in the finance industry?

On Thursday, 9 January 2014 at 06:11:58 UTC, Manu wrote:
> On 9 January 2014 13:08, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
>>
>>> Additionaly programming with a GC often leads to a lot more allocations,
>>>
>>
>> I believe that this is incorrect. Using GC leads to fewer allocations,
>> because you do not have to make extra copies just so it's clear who owns
>> the allocations.
>>
>
> 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
> Sadly, being conscious of eliminating unnecessary copies in C/C++ takes a
> lot of work (see: time and money), so there is definitely value in
> factoring that problem away, but the existing GC is broken. Until it
> doesn't leak, stop the world, and/or can run incrementally, it remains no
> good for realtime usage.
> There were 2 presentations on improved GC's last year, why do we still have
> the lamest GC imaginable? I'm still yet to hear any proposal on how this
> situation will ever significantly improve...
>
> *cough* ARC...
>

For it to be done properly, RC needs to be compiler assisted, otherwise it is just too slow.

--
Paulo

On 1/8/2014 10:11 PM, Manu wrote:
> On 9 January 2014 13:08, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
>
>         Additionaly programming with a GC often leads to a lot more allocations,
>
>
>     I believe that this is incorrect. Using GC leads to fewer allocations,
>     because you do not have to make extra copies just so it's clear who owns the
>     allocations.
>
>
> You're making a keen assumption here that C programmers use STL.

My observation has nothing to do with the STL, nor does it have anything to do with how well the GC is implemented. Also, neither smart pointers nor ARC resolve the excessive copying problem as I described it.

I've been coding in C for 15-20 years before the STL, and the problem of excessive copying is a significant source of slowdown for C code.

Consider this C code:

char* cat(char* s1, char* s2) {
    size_t len1 = s1 ? strlen(s1) : 0;
    size_t len2 = s2 ? strlen(s2) : 0;
    char* s = (char*)malloc(len1 + len2 + 1);
    assert(s);
    memcpy(s, s1, len1);
    memcpy(s + len1, s2, len2);
    s[len1 + len2] = 0;
    return s;
}

Now consider D code:

string cat(string s1, string s2) {
    return s1 ~ s2;
}

I can call cat with:

    cat("hello", null);

and it works without copying in D, it just returns s1. In C, I gotta copy, ALWAYS.

(C's strings being 0 terminated also forces much extra copying, but that's another topic.)

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.

The reason that Java does excessive amounts of allocation is because Java doesn't have value types, not because Java has a GC.

On Thursday, 9 January 2014 at 07:07:29 UTC, Walter Bright wrote:
> On 1/8/2014 10:11 PM, Manu wrote:
>> On 9 January 2014 13:08, Walter Bright <newshound2@digitalmars.com
>> <mailto:newshound2@digitalmars.com>> wrote:
>>
> The reason that Java does excessive amounts of allocation is because Java doesn't have value types, not because Java has a GC.

That might change if IBM's extensions ever land in Java.

http://www.slideshare.net/rsciampacone/javaone-2013-introduction-to-packedobjects

Video presentation available here,
http://www.parleys.com/play/52504e5ee4b0a43ac121240b

Walter is right regarding D. All other GC enabled systems programming languages do have value objects and don't require everything to be on heap.

So the stress on the GC to clean memory is not as high as on Java and similar systems.

--
Paulo

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).

> (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).

> 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).

On Thursday, 9 January 2014 at 08:40:30 UTC, Ola Fosheim Grøstad 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).
>
>> (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).
>
>> 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).

I have only seen those things work in small AAA class teams.

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.

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.


--
Paulo

On 1/9/2014 1:38 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" 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.

A GC does not prevent such techniques.