Menu
Search

Forums

Forum Index

September 15
Gravatar of bachmeierPosted by bachmeier
in reply to monkyyy		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to monkyyy


Reply

On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:

>

a language includes its std and there's no alternative for std: string, algorithm, range to be nogc'ed with a nice easy-to-grab data structure. A betterc project is just going to be segmented from the rest of d and be a very different project.

If d were to start adding data structures to the std and 1 or 2 of them happened to work ok with betterc; maybe my answer would change. But I really really do mean that d has one data structure of note, the built-in dynamic array, and adding more is obviously not a priority(despite that being insane).

betterC and @nogc are rather different. You don't have, and should not want, a GC in betterC code. @nogc is useful in the context of a regular D program that has places you want to guarantee the GC won't run. betterC code is perfectly fine to add to a regular D project. I do that with Mir.

September 15
Gravatar of Atila NevesPosted by Atila Neves
in reply to Sergey		Reply
Atila Neves
Gravatar of Atila Neves
Posted in reply to Sergey


Reply
On Thursday, 14 September 2023 at 18:53:02 UTC, Sergey wrote:
> On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 wrote:
>> On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe wrote:
>>
>>> This is a mistaken decision.
>>
>> Can you explain why?
>
> Maybe because experimental.allocators broken by design?

How so?
September 15
Gravatar of Atila NevesPosted by Atila Neves
in reply to monkyyy		Reply
Atila Neves
Gravatar of Atila Neves
Posted in reply to monkyyy


Reply

On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:

>

On Friday, 15 September 2023 at 16:09:44 UTC, bachmeier wrote:

>

On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

>

d as is, is gc'ed to hell and back

That's why I use it.

>

nogc is a bandaid to advertise its something its not.

This is what the spec says. I don't see anything wrong with it. It restricts what you can do inside a function and that's what it's supposed to do.

a language includes its std and there's no alternative for std: string, algorithm, range to be nogc'ed

std.string, I get, but algorithm and range are poster children for @nogc. I'm not going to claim that nothing in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

Which is good because allocating when not needed is silly, not because avoiding the GC is a good idea. It isn't. If your program is slow and you profiled and it's GC allocation that's slowing it down, then think about doing something else.

September 15
Gravatar of Jonathan M DavisPosted by Jonathan M Davis
in reply to Atila Neves		Reply
Jonathan M Davis
Gravatar of Jonathan M Davis
Posted in reply to Atila Neves


Reply
On Friday, September 15, 2023 2:38:12 PM MDT Atila Neves via Digitalmars-d wrote:
> std.string, I get, but algorithm and range are poster children for `@nogc`. I'm not going to claim that *nothing* in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

I recall complaints in the past about not being able to use @nogc with std.algorithm and friends due to issues with lamdbas allocating closures. I don't know that that's actually an issue at this point (and it really shouldn't be in general), but it can also be worked around with other forms of callables if need be. It's just more annoying than using a lambda.

But yeah, there should be _very_ little in terms of explicit allocations occuring in std.algorithm (possibly even none). It's templated and designed to operate on generic ranges, and very little of it does anything with exceptions, so almost none of it should be allocating anything - though of course, if your ranges themselves can't be @nogc for some reason, then obviously, std.algorithm can't be either. So, I suspect that strings, for instance, can't be @nogc with std.algorithm (at least without byCodeUnit) due to the decoding possibly throwing. A lot of other stuff should be able to work with std.algorithm and be @nogc with no problem though.

- Jonathan M Davis
September 15
Gravatar of monkyyyPosted by monkyyy
in reply to bachmeier		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to bachmeier


Reply

On Friday, 15 September 2023 at 17:55:49 UTC, bachmeier wrote:

>

betterC and @nogc are rather different.

Maybe I'm missing something cause like; I very much don't want to make big complex projects I just go "import std;" and write out 100 lines.

I see two main languges: d and ranges(that mostly just wrap [] cause its there), and the std; betterc, libc and manual memory management cause you have nothin.

Is there a real project that's inbetween; that are using c strings and finding a way to use the std anyway?

September 15
Gravatar of monkyyyPosted by monkyyy
in reply to Atila Neves		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to Atila Neves


Reply

On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

>

On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:

>

On Friday, 15 September 2023 at 16:09:44 UTC, bachmeier wrote:

>

On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

>

d as is, is gc'ed to hell and back

That's why I use it.

>

nogc is a bandaid to advertise its something its not.

This is what the spec says. I don't see anything wrong with it. It restricts what you can do inside a function and that's what it's supposed to do.

a language includes its std and there's no alternative for std: string, algorithm, range to be nogc'ed

std.string, I get, but algorithm and range are poster children for @nogc. I'm not going to claim that nothing in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

Which is good because allocating when not needed is silly, not because avoiding the GC is a good idea. It isn't. If your program is slow and you profiled and it's GC allocation that's slowing it down, then think about doing something else.

I'm mostly talking about existing data structures and string handling(strings being probably the most important data structure)

Given my definition of language above of compiler + std, a betterc project is probably using libc for strings and rolling their own data structures; at which point they can't use my code(I use import std casually) I don't want to use their code even if it even works.

Not getting involved in your attribute debates, to use std.algorithm I need data structures that were designed to work with it(and probably tested with it), and static arrays aren't on the list.

I mostly rant and rave about this on discord but I've been complaining about this for years, but for stepovs idea of templates where you get n*m solutions out of n+m code you should attempt to balance n algorithms with m data structures, and nogc by disabling the one good data structure makes 100ish algorithms x 1 ==100 into 100x0==0 making the situation so much worse.

If you want nogc to be usable(rn if I want to make something with wasm I would need to write a bunch of data structures), the problem with data structures, in general, should be addressed.

September 16
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Atila Neves		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Atila Neves


Reply

On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

>

std.string, I get, but algorithm and range are poster children for @nogc. I'm not going to claim that nothing in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

Autodecoding and exceptions.

-Steve

September 16
Gravatar of Vladimir PanteleevPosted by Vladimir Panteleev
in reply to Atila Neves		Reply
Vladimir Panteleev
Gravatar of Vladimir Panteleev
Posted in reply to Atila Neves


Reply

On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

>

std.string, I get, but algorithm and range are poster children for @nogc. I'm not going to claim that nothing in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

It's not possible to map a range and add a variable to every element.

Functor predicates are the solution: https://github.com/CyberShadow/ae/blob/bb876371c963130dd94a0f44a9a5a2561ff053b4/utils/functor/algorithm.d#L23-L69

September 16
Gravatar of Sebastiaan KoppePosted by Sebastiaan Koppe
in reply to Vladimir Panteleev		Reply
Sebastiaan Koppe
Gravatar of Sebastiaan Koppe
Posted in reply to Vladimir Panteleev


Reply

On Saturday, 16 September 2023 at 05:32:19 UTC, Vladimir Panteleev wrote:

>

On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

>

std.string, I get, but algorithm and range are poster children for @nogc. I'm not going to claim that nothing in those packages allocates on the GC heap, but I'd be very surprised if there were many functions that did.

It's not possible to map a range and add a variable to every element.

Functor predicates are the solution: https://github.com/CyberShadow/ae/blob/bb876371c963130dd94a0f44a9a5a2561ff053b4/utils/functor/algorithm.d#L23-L69

I came to the same conclusion.

September 18
Gravatar of SergeyPosted by Sergey
in reply to Maximilian Naderer		Reply
Sergey
Gravatar of Sergey
Posted in reply to Maximilian Naderer


Reply

On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian Naderer wrote:

>

Hello,

I think D is a great language and a general theme is that everybody is complaining about the lack of libraries, frameworks and/or bindings to popular C/C++ libraries.

I checked the GitHub repo and so some todos, I would like to contribute to the language.

What popular frameworks / libraries would you like to see bindings for so that those could be used in D?

Best regards,
Max

Please also consider support of great existing libraries:
Mir framework needs new maintainer.
Archttp (performant web server from Hunt authors) is lacking of maintenance now.
Also the autho of Tilix (gtk application for Linux terminal) searched new maintainer quite a while..

« First   ‹ Prev
1 2 3 4
Next ›   Last »