[Issue 24614] Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from Richard (Rikki) Andrew Cattermole --- D classes depend upon druntime. Runtime exceptions ala ``Throwable`` hierarchy depend upon druntime. As of right now this is expected and correct behavior for runtime exceptions to not work in -betterC. There is a high desire to see some variant of value based sumtype returns in the language hooked into ``throw`` and ``catch`` that do not depend upon druntime, however that is not currently in the DIP queue due to a dependency upon sumtypes. --
[Issue 24614] New: Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614
Issue ID: 24614
Summary: Can’t throw in -betterC mode with -preview=dip1008
(@nogc Exceptions)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Maybe this is invalid, but the Description section of DIP 1008 ("Exceptions and
@nogc") gives the impression that this should be possible.
Quote from DIP 1008:
> The issue is [exceptions being GC allocated] […] prevents building D programs
> that do not link in the GC runtime.
The prime example for D programs without GC runtime are `-betterC` programs.
That `-betterC` mode does not allow for Exceptions may be due to reasons other
than being unable to GC-allocate them, but maybe not, and therefore this bug
report.
--
Re: How can I tell D that function args are @nogc etc.
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote: Not every day you get to blame a compiler bug. D is uniquely: hacky, expressive and buggy. Having more metaprograming then c++ without the raw man power comes at a cost, in d you should distrust the spec and instead see what the compiler actually does far more then any other languge. -- john -- monkyyy
Re: How can I tell D that function args are @nogc etc.
On Friday, 12 April 2024 at 15:08:50 UTC, Steven Schveighoffer
wrote:
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote:
What is the procedure for bug reporting? I'm looking at the
issues tracker and have no clue how to drive the search to see
if this is already there.
https://issues.dlang.org
While entering the bug title, it does a fuzzy search for
existing open and closed issues.
The typical problem with issue/bug database searches is you have
to know the important discriminating keywords that projects
evolve over time. When you are new to a system, as I am with D,
you end up looking manually through a lot of possibles. Another
barrier to noobs that project long timers may not notice.
Any rate, it appears
https://issues.dlang.org/show_bug.cgi?id=22046 is the same issue.
And I'm not sure how to interpret it, as a noob I don't have
enough context. It appears to be deliberate and also afflicts var
declarations. Since 2014.
From my point of view, either it's still a bug and needs to be
written up in a best practices list with all the other long term
stuff you need to work around until it can be fixed (eg. "in
alias and var function declarations, put attributes as a suffix
because...", https://dlang.org/dstyle.html *might* be a place),
or it has aged in to become the effective intended behavior and
should be documented other places and have a compiler error or
warning ("@safe in prefix position in alias, is ignored"). Or of
course, it could get fixed but my experiences have shown me that
after 10 years that is low probability with most projects.
I'm not trying to be a dick here. I've managed projects and know
what unintentional dumb stuff can happen. But, at the moment, I'm
evaluating D for a project (porting 30,000 lines of very old C
with strict timing requirements) and I've got some time to build
impressions of system language candidates. There appears to be a
lot of talk from time to time over in General about luring new
people in to work with D, and this kind of issue is relevant.
-Steve
--john
Re: How can I tell D that function args are @nogc etc.
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote: What is the procedure for bug reporting? I'm looking at the issues tracker and have no clue how to drive the search to see if this is already there. https://issues.dlang.org While entering the bug title, it does a fuzzy search for existing open and closed issues. -Steve
Re: How can I tell D that function args are @nogc etc.
On Thursday, 11 April 2024 at 15:00:49 UTC, Steven Schveighoffer
wrote:
So D can provide a nice mechanism to show what is happening --
`pragma(msg, ...)`
If I do that with the two types above I see something *very*
interesting:
```d
pragma(msg, FnPrefixT);
pragma(msg, FnSuffixT);
```
```
bool function(int) nothrow @nogc
bool function(int) nothrow @nogc @safe
```
That surprises me. `nothrow` and `@nogc` go onto the type, but
not `@safe` if put before the declaration? I have no idea why.
All I can think of is that it is a bug.
`pragma(msg,...)` is very useful. Thanks.
My general impressions were correct then. It shouldn't matter on
which side the attrs get put, except in some ambiguous cases.
It's just broken. Not every day you get to blame a compiler bug.
Feeding:
```d
alias FnPrefixT = @safe nothrow @nogc bool function(int);
alias FnSuffixT = bool function(int) @safe nothrow @nogc ;
pragma(msg, FnPrefixT);
pragma(msg, FnSuffixT);
void main() { return; }
```
into run.dlang and having it compile with all the
compilers...gets the same result all the way back to 2.060. It
has this issue with gdc 2.076, which is what I'm using normally.
What is the procedure for bug reporting? I'm looking at the
issues tracker and have no clue how to drive the search to see if
this is already there.
-Steve
-- john
Re: How can I tell D that function args are @nogc etc.
On Thursday, 11 April 2024 at 03:17:36 UTC, John Dougan wrote:
Interesting. Thank you to both of you.
On Wednesday, 10 April 2024 at 17:38:21 UTC, Steven
Schveighoffer wrote:
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Place your attributes on the right hand side of the function,
not the left side.
Use the left side for attributes/type qualifiers that go on
the return type.
Just a word of warning, this explanation suggests putting
qualifiers on the left side would affect the return type, this
is not the case.
So in my example, what did I actually tell the compiler with
the placement of the attributes? And how was it different
between the function type alias declaration, and the actual
function declaration?
More specifically, what are the semantic differences below?
```d
alias FnPrefixT = @nogc nothrow @safe bool function(int);
// Versus
alias FnSuffixT = bool function(int) @nogc nothrow @safe;
```
So D can provide a nice mechanism to show what is happening --
`pragma(msg, ...)`
If I do that with the two types above I see something *very*
interesting:
```d
pragma(msg, FnPrefixT);
pragma(msg, FnSuffixT);
```
```
bool function(int) nothrow @nogc
bool function(int) nothrow @nogc @safe
```
That surprises me. `nothrow` and `@nogc` go onto the type, but
not `@safe` if put before the declaration? I have no idea why.
All I can think of is that it is a bug.
and
```d
@nogc nothrow @safe bool fnPrefix(int) { stuff }
// Versus
bool fnSuffix(int) @nogc nothrow @safe { stuff }
```
```d
pragma(msg, typeof(fnPrefix));
pragma(msg, typeof(fnSuffix));
```
```
nothrow @nogc @safe bool(int)
nothrow @nogc @safe bool(int)
```
(as expected)
-Steve
Re: How can I tell D that function args are @nogc etc.
Interesting. Thank you to both of you.
On Wednesday, 10 April 2024 at 17:38:21 UTC, Steven Schveighoffer
wrote:
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Place your attributes on the right hand side of the function,
not the left side.
Use the left side for attributes/type qualifiers that go on
the return type.
Just a word of warning, this explanation suggests putting
qualifiers on the left side would affect the return type, this
is not the case.
So in my example, what did I actually tell the compiler with the
placement of the attributes? And how was it different between the
function type alias declaration, and the actual function
declaration?
More specifically, what are the semantic differences below?
```d
alias FnPrefixT = @nogc nothrow @safe bool function(int);
// Versus
alias FnSuffixT = bool function(int) @nogc nothrow @safe;
```
and
```d
@nogc nothrow @safe bool fnPrefix(int) { stuff }
// Versus
bool fnSuffix(int) @nogc nothrow @safe { stuff }
```
Is there a reasonably clear overview of how this works anywhere?
What I have seen so far led me to the vague impression that it
wasn't significant just like attribute ordering.
-- john
Re: How can I tell D that function args are @nogc etc.
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki) Andrew Cattermole wrote: Place your attributes on the right hand side of the function, not the left side. Use the left side for attributes/type qualifiers that go on the return type. Just a word of warning, this explanation suggests putting qualifiers on the left side would affect the return type, this is not the case. Attributes apply to the *declaration*. In some cases this effectively applies to the return type, in some cases it applies to the function, in some cases it applies to the context pointer. In order to apply type constructors to the return type, you need to use parentheses: ```d const int foo(); // const applies to the context pointer of `foo`, not `int` const(int) bar(); // const applies to `int` return type ref int baz(); // ref applies to `baz`, which in turn means "ref returning function" ``` Where this becomes tricky is return types that are function pointers/delegates. Then using the right side of the function/delegate *type* is the only way. ```d @safe void function() foo(); // `foo` is safe, the function pointer it returns is not void function() @safe bar(); // `bar` is not safe, the function pointer returned is void function() @safe baz() @safe; // both are safe ``` -Steve
Re: How can I tell D that function args are @nogc etc.
Place your attributes on the right hand side of the function, not the
left side.
Use the left side for attributes/type qualifiers that go on the return type.
```d
bool[7] stagesToProcess = false;
bool shouldDoInStages(int index) @nogc nothrow @safe
{
return stagesToProcess[index];
}
bool shouldDoNever(int index) @nogc nothrow @safe
{
return false;
}
template processSafely(int low, int high)
{
alias ShouldDoFnT = bool function(int) @nogc nothrow @safe;
uint processSafely(ShouldDoFnT shouldDo) @nogc nothrow @safe
{
assert(low < high);
uint stepsProcessed;
for (int ii = low; ii <= high; ii++)
{
if (shouldDo(ii))
{
stepsProcessed++;
}
}
return stepsProcessed;
}
}
void main()
{
stagesToProcess = [false, false, true, true, false, true,
false];
uint count = processSafely!(1, 4)();
assert(count == 2);
}
```
How can I tell D that function args are @nogc etc.
Below is a example program that illustrates my issue.
When compiled at run.dlang I get:
```
onlineapp.d(18): Error: `@safe` function
`onlineapp.processSafely!(1, 4).processSafely` cannot call
`@system` function pointer `shouldDo`
onlineapp.d(28): Error: template instance
`onlineapp.processSafely!(1, 4)` error instantiating
```
Why isn't this working? How can I get the effect I want?
Cheers,
-- john
```
bool[7] stagesToProcess = false;
@nogc nothrow @safe bool shouldDoInStages(int index)
{
return stagesToProcess[index];
}
@nogc nothrow @safe bool shouldDoNever(int index)
{
return false;
}
template processSafely(int low, int high)
{
alias ShouldDoFnT = @nogc nothrow @safe bool function(int);
@nogc nothrow @safe uint processSafely(ShouldDoFnT shouldDo)
{
assert(low < high);
uint stepsProcessed;
for (int ii = low; ii <= high; ii++)
{
if (shouldDo(ii))
{
stepsProcessed++;
}
}
return stepsProcessed;
}
}
void main()
{
stagesToProcess = [false, false, true, true, false, true,
false];
uint count = processSafely!(1, 4)();
assert(count == 2);
}
```
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 --- Comment #6 from Dlang Bot --- dlang/dmd pull request #16023 "fix Issue 24331 - @nogc and GC.disable() are often confused" was merged into master: - e04af29b775a42417d43081fdc905021766b6bb4 by Walter Bright: fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dmd/pull/16023 --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dlang.org pull request #3756 "fix Issue 24331 - @nogc and GC.disable() are often confused" was merged into master: - 5c56620fa0fbfc2db75e681751abbd5f85758cb1 by Walter Bright: fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dlang.org/pull/3756 --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 --- Comment #4 from Dlang Bot --- @WalterBright created dlang/dmd pull request #16023 "fix Issue 24331 - @nogc and GC.disable() are often confused" fixing this issue: - fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dmd/pull/16023 --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @WalterBright created dlang/dlang.org pull request #3756 "fix Issue 24331 - @nogc and GC.disable() are often confused" fixing this issue: - fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dlang.org/pull/3756 --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 Walter Bright changed: What|Removed |Added Keywords||industry Hardware|x86 |All OS|Windows |All --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #2 from timon.g...@gmx.ch --- (In reply to Walter Bright from comment #1) > Sounds like better documentation is needed for both @nogc and GC.disable(). Well, currently, the spec states: How Garbage Collection Works - The GC works by: - Stopping all other threads than the thread currently trying to allocate GC memory. - ‘Hijacking’ the current thread for GC work. - Scanning all ‘root’ memory ranges for pointers into GC allocated memory. - Recursively scanning all allocated memory pointed to by roots looking for more pointers into GC allocated memory. - Freeing all GC allocated memory that has no active pointers to it and do not need destructors to run. - Queueing all unreachable memory that needs destructors to run. - Resuming all other threads. - Running destructors for all queued memory. - Freeing any remaining unreachable memory. - Returning the current thread to whatever work it was doing. https://dlang.org/spec/garbage.html So what people are relying on is currently indeed specified behavior. This can of course be changed, but I do not think we can fault users for relying on this documented behavior of the GC. --
[Issue 24331] @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 --- Comment #1 from Walter Bright --- Sounds like better documentation is needed for both @nogc and GC.disable(). --
[Issue 24331] New: @nogc and GC.disable() are often confused
https://issues.dlang.org/show_bug.cgi?id=24331 Issue ID: 24331 Summary: @nogc and GC.disable() are often confused Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Adam Wilson writes: @nogc works just fine. We recently spent a good chunk of time in Discord educating a newbie on what it actually does. What @nogc is specified to do: Prevent GC allocations from occurring. Fantastic. What people actually do with @nogc: Use it to selectively disable the GC without using GC.disable(). The reason for this stems from a side-effect of how the current GC operates. Because allocations are the trigger for collections, by preventing allocations, collections are also prevented. And what people really want to do is disable collections because they don't like the collection pauses. They don't actually care about the allocations per se because that is generally as fast as a malloc and they are going to have to allocate at some point anyways. So @nogc works exactly as specified, but because of an unspecified implementation side-effect, that is not guaranteed to hold true in the future, the @nogc crowd writes their code as if @nogc does something else entirely. And we end up here in this thread. --
[Issue 24327] LDC --nogc should work for scope class instance
https://issues.dlang.org/show_bug.cgi?id=24327 --- Comment #1 from a11e99z --- BTW I prefer: auto c = scope C(); cuz new X means heap/GC, scope means scope --
[Issue 24327] LDC --nogc should work for scope class instance
https://issues.dlang.org/show_bug.cgi?id=24327 a11e99z changed: What|Removed |Added Summary|LDC --nogc |LDC --nogc should work for ||scope class instance --
[Issue 24327] New: LDC --nogc
https://issues.dlang.org/show_bug.cgi?id=24327
Issue ID: 24327
Summary: LDC --nogc
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: tools
Assignee: nob...@puremagic.com
Reporter: blac...@bk.ru
import core.stdc.stdio;
class C {
@nogc:
public:
this() { printf( "C.C\n"); }
~this() { printf( "C.~C\n"); }
}
void main() @nogc {
printf( "=> main\n");
scope(exit) printf( "<= main\n");
scope c = new C(); // LOC 14
}
//-
ldc2 file.d - OK
ldc2 --nogc file.d: file.d(14): Error: No implicit garbage collector calls
allowed with -nogc option enabled: `_d_callfinalizer`
shouldn't check/call GC for scope vars
--
Re: NuMem - safe(r) nogc memory managment
On Tuesday, 2 January 2024 at 10:30:52 UTC, Sergey wrote: On Saturday, 30 December 2023 at 15:17:36 UTC, Luna wrote: NuMem 0.5.4 has been released, numem is a new library Any meaningful comparison with another similar library will be highly appreciated https://code.dlang.org/packages/automem I'm not familiar with automem, and I'm not numem primary author. Goals seems very similar and from a cursory reading: - automem is much further along on many points such as: attribute forwarding, @nogc, @safe, DIP1000, allocator support, ranges, support for GC roots, and exists since 6 years. - numem is designed to allow C++ programmers to feel at ease, with a bit less runtime use maybe. Containers own their elements, like C++ containers (not sure how it is in automem). We plan a std::map-like.
Re: NuMem - safe(r) nogc memory managment
On Saturday, 30 December 2023 at 15:17:36 UTC, Luna wrote: NuMem 0.5.4 has been released, numem is a new library Any meaningful comparison with another similar library will be highly appreciated https://code.dlang.org/packages/automem
Re: NuMem - safe(r) nogc memory managment
On Saturday, 30 December 2023 at 16:36:38 UTC, ryuukk_ wrote: We plan to add more memory management utilities, thereby making writing completely GC-less D code a lot more user-friendly. I'd be happy to help What D really is missing _right now_, and will hopefully get _before_ phobosv3 is a good and minimalistic Allocator API, i modeled mine around zig's, no RAII, just a simple struct with 3 function ptr Yes, but first we can replace all the data structures in druntime to use non GC versions. I don't think there are that many of them. The non GC dynamic array would be a good fit here.
Re: NuMem - safe(r) nogc memory managment
On Saturday, 30 December 2023 at 16:36:38 UTC, ryuukk_ wrote: What D really is missing _right now_, and will hopefully get _before_ phobosv3 is a good and minimalistic Allocator API, i modeled mine around zig's, no RAII, just a simple struct with 3 function ptr FWIW it's possible to do a generic one with one function pointer: https://www.lua.org/manual/5.4/manual.html#lua_Alloc
Re: NuMem - safe(r) nogc memory managment
We plan to add more memory management utilities, thereby making writing completely GC-less D code a lot more user-friendly. I'd be happy to help What D really is missing _right now_, and will hopefully get _before_ phobosv3 is a good and minimalistic Allocator API, i modeled mine around zig's, no RAII, just a simple struct with 3 function ptr
Re: NuMem - safe(r) nogc memory managment
Nice, thanks for sharing, it'll be very useful for the C++ developers who want to give D a try
Re: NuMem - safe(r) nogc memory managment
On Saturday, 30 December 2023 at 15:17:36 UTC, Luna wrote: * C++ style smart pointers (unique_ptr, shared_ptr, weak_ptr) * C++ style vector type (with support for moving unique_ptr's in!) Indeed with numem you can have a relatively "C++11" experience with scoped ownership, which we intend to make use of because without GC it's easy to be plagued by leaks in user code.
NuMem - safe(r) nogc memory managment
NuMem 0.5.4 has been released, numem is a new library I am developing with contributions from Auburn Sounds/p0nce. It's meant to provide safer ways of writing nogc code, which is sometimes neccesary when the D garbage collector would be an unoptimal choice. NuMem currently features: * C++ style smart pointers (unique_ptr, shared_ptr, weak_ptr) * C++ style vector type (with support for moving unique_ptr's in!) * Alternative for new and destroy; `nogc_new` and `nogc_delete`. * A string alternative built on the vector implementation * Automatic null-pointer handling, for easy passing of strings to C. * A `minimal_rt` mode meant for environments where only a tiny subset of the D runtime is present, with custom handling of class destruction that doesn't use TypeInfo. * Eg. the port of D I'm making for the SEGA Dreamcast. We plan to add more memory management utilities, thereby making writing completely GC-less D code a lot more user-friendly. You can find the package here https://code.dlang.org/packages/numem Additionally, the `yxml` package uses numem's smart pointers and strings. https://code.dlang.org/packages/yxml
[Issue 24272] operations.arrayOp is forced @nogc nothrow pure
https://issues.dlang.org/show_bug.cgi?id=24272 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15890 "Fix 24272 - operations.arrayOp is forced @nogc nothrow pure" was merged into master: - 9e39e6916f5f13fd08bc929839c0a9ba9f4ee3e1 by Dennis Korpel: Fix 24272 - operations.arrayOp is forced @nogc nothrow pure https://github.com/dlang/dmd/pull/15890 --
[Issue 24272] operations.arrayOp is forced @nogc nothrow pure
https://issues.dlang.org/show_bug.cgi?id=24272 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15890 "Fix 24272 - operations.arrayOp is forced @nogc nothrow pure" fixing this issue: - Fix 24272 - operations.arrayOp is forced @nogc nothrow pure https://github.com/dlang/dmd/pull/15890 --
[Issue 24272] New: operations.arrayOp is forced @nogc nothrow pure
https://issues.dlang.org/show_bug.cgi?id=24272
Issue ID: 24272
Summary: operations.arrayOp is forced @nogc nothrow pure
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
Pointed out on the forum:
https://forum.dlang.org/post/lssjxaqshkvytbeey...@forum.dlang.org
```
void main() {
auto a = new BigInt[](100);
a[] = BigInt(1); // works fine
a[] += BigInt(1); // Error: `@nogc` function
`core.internal.array.operations.arrayOp!
// (BigInt[], BigInt, "+=").arrayOp` cannot call non-@nogc
function
// `std.bigint.BigInt.opOpAssign!("+", BigInt).opOpAssign`
}
```
arrayOp is a template, so function attributes should be inferred.
--
Re: D: Convert/parse uint integer to string. (@nogc)
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
I tried to look into https://dlang.org/phobos/std_conv.html
Most of the functions inside `std.conv` seem to be dependant on
[Garbage Collection](https://dlang.org/spec/garbage.html).
And I couldn't find a straightforward way to produce a `string`
value out of `uint` value.
How to convert or parse `uint` value to a `string` in `@nogc`
way?
There are various tricks to do such conversion very fast. For
example, the following article is essential for implementing it:
https://lemire.me/blog/2021/06/03/computing-the-number-of-digits-of-an-integer-even-faster/
Rather than doing conversion one digit at a time, it's much more
efficient to process multiple digits per loop iteration. Consider
an illustrative pseudocode like this:
```D
while (x >= 100) {
write(twodigits_lookup_table[x % 100]); // we can handle
two digits at once
x /= 100;
}
```
I have a @nogc compatible DUB module, which implements fast
formatted output to stdout: https://github.com/ssvb/speedy-stdio
(cutting some corners allows to squeeze some extra performance
out of it).
The same code can be adapted to do formatted output to a memory
buffer as well.
Re: D: Convert/parse uint integer to string. (@nogc)
On Tuesday, 28 November 2023 at 09:43:47 UTC, Dom DiSc wrote: On Tuesday, 28 November 2023 at 08:51:21 UTC, Mark Davies wrote: On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote: ``` import std.stdio; char[10] longToString(long n) @nogc ``` For a 'long' 10 characters is likely to be not enough (long max is 9223372036854775808 [...] `long.max` is 9223372036854775807, `long.min` is -9223372036854775808. Besides from the too short buffer the `longToString` function neither converts 0 (zero) nor `long.min` correctly.
Re: D: Convert/parse uint integer to string. (@nogc)
On Friday, 24 November 2023 at 13:05:30 UTC, Ferhat Kurtulmuş
wrote:
[...]
```
import core.stdc.stdio : sprintf;
import core.stdc.math : log10;
import std.exception : assumeUnique;
import std.stdio : writeln;
size_t nod(int num){
return cast(size_t)((num==0)?1:log10(num)+1);
}
void main()
{
int myint = 23;
char[80] str;
sprintf(str.ptr, "%d", myint);
string _dstring = str[0..nod(myint)].assumeUnique;
writeln(_dstring);
}
```
What happend to the indentation? Anyway
```
$ ./inttostr -1
$ ./inttostr -2147483648
```
I like `snprintf`:
```d
import core.stdc.stdio : snprintf;
import std.exception : assumeUnique, enforce;
import std.stdio;
import std.conv;
import core.stdc.locale;
import std.format;
void main (string [] args)
{
setlocale (LC_NUMERIC, "");
auto myint = args[1].to!long;
char[27] str;
auto n = snprintf(str.ptr, str.sizeof, "%'ld", myint);
enforce (n < str.sizeof, "buffer too small");
string _dstring = str[0..n].assumeUnique;
writeln(_dstring);
}
```
```
$ ./l2s -9223372036854775808
-9.223.372.036.854.775.808
```
Re: D: Convert/parse uint integer to string. (@nogc)
On Tuesday, 28 November 2023 at 08:51:21 UTC, Mark Davies wrote:
I did it this way ...
You always print the full array of bytes this way. Output piped
to `od -c` is
```
000 1 2 3 4 5 377 377 377 377 377 \n - 1 2
3 4
020 5 377 377 377 377 \n
```
Those 377s are `char.init`, 0xFF.
On Tuesday, 28 November 2023 at 09:43:47 UTC, Dom DiSc wrote:
For a 'long' 10 characters is likely to be not enough (long max
is 9223372036854775808 which has 19 chars, and you should
reserve additional one for the sign and one for the terminating
null), so I would at least recommend using char[21].
Signed max is all bits but the sign bit set, so 7FFF..., so
signed max is always an odd number. d can confirm:
```
$ rdmd --eval 'writeln(long.max)'
9223372036854775807
$ rdmd --eval 'writeln(2+to!string(long.max).length)'
21
```
There's no terminating NUL here, which might be an oversight.
with char[10] your function becomes a big hole in your
security, as it can easily be misused to write 10 bytes of
freely selectable garbage behind your allocated memory.
This is D though, so without separately disabling bounds checks,
there's an error:
```
core.exception.ArrayIndexError@d1.d(22): index [18] is out of
bounds for array of length 10
```
or with -betterC:
```
d1: d1.d:21: Assertion `array index out of bounds' failed.
Aborted
```
Here's a minimal edit to fix the `char.init` output:
```d
char[] longToString(long n) @nogc
{
static char[21] x;
size_t length;
ulong power;
x[0] = '-'*(n<0);
long t = (n<0)*-n + (n>0)*n ;
while (n != 0)
{
power++;
n /= 10;
}
length = power;
power -= (x[0] != '-');
while (t > 0)
{
x[power] = (t % 10) + '0';
power--;
t /= 10;
}
return x[0 .. length];
}
```
As you can see, slices from this longToString are good until the
next call to it. The other C-like way to manage memory is to pass
in the buffer to use, which in D can be a slice of a static array
on the caller's stack. You'll probably have a much better time
with manual memory management if you use custom allocators.
Re: D: Convert/parse uint integer to string. (@nogc)
On Tuesday, 28 November 2023 at 08:51:21 UTC, Mark Davies wrote: On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote: ``` import std.stdio; char[10] longToString(long n) @nogc ``` For a 'long' 10 characters is likely to be not enough (long max is 9223372036854775808 which has 19 chars, and you should reserve additional one for the sign and one for the terminating null), so I would at least recommend using char[21]. with char[10] your function becomes a big hole in your security, as it can easily be misused to write 10 bytes of freely selectable garbage behind your allocated memory. But as you want to avoid the gc, security might not be a goal for you, so continue living in the 1970's.
Re: D: Convert/parse uint integer to string. (@nogc)
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
I tried to look into https://dlang.org/phobos/std_conv.html
Most of the functions inside `std.conv` seem to be dependant on
[Garbage Collection](https://dlang.org/spec/garbage.html).
And I couldn't find a straightforward way to produce a `string`
value out of `uint` value.
How to convert or parse `uint` value to a `string` in `@nogc`
way?
I did it this way ...
```
import std.stdio;
char[10] longToString(long n) @nogc
{
char[10] x;
ulong power;
x[0] = '-'*(n<0);
long t = (n<0)*-n + (n>0)*n ;
while (n != 0)
{
power++;
n /= 10;
}
power -= (x[0] != '-');
while (t > 0)
{
x[power] = (t % 10) + '0';
power--;
t /= 10;
}
return x;
}
int main()
{
long p = 12345;
char[10] r = longToString(p);
writeln(r);
p = -12345;
r = longToString(p);
writeln(r);
return 0;
}
```
Re: D: Convert/parse uint integer to string. (@nogc)
On Monday, 27 November 2023 at 12:34:30 UTC, Nick Treleaven wrote:
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
You can use std.conv.toChars:
```d
void main() @nogc
{
int n = 515;
import std.conv;
char[10] s = 0;
auto r = n.toChars();
assert(r.length < s.length);
size_t i;
foreach (c; r)
s[i++] = c;
import core.stdc.stdio;
puts(s.ptr);
}
```
Or, using std.experimental.allocator:
```d
void main() @nogc
{
int n = 515;
import std.conv;
import std.experimental.allocator;
import std.experimental.allocator.mallocator;
alias a = Mallocator.instance;
auto s = a.makeArray(n.toChars);
assert(s == "515");
a.dispose(s);
}
```
Re: D: Convert/parse uint integer to string. (@nogc)
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
I tried to look into https://dlang.org/phobos/std_conv.html
Most of the functions inside `std.conv` seem to be dependant on
[Garbage Collection](https://dlang.org/spec/garbage.html).
And I couldn't find a straightforward way to produce a `string`
value out of `uint` value.
How to convert or parse `uint` value to a `string` in `@nogc`
way?
You can use std.conv.toChars:
```d
void main() @nogc
{
int n = 515;
import std.conv;
char[10] s = 0;
auto r = n.toChars();
assert(r.length < s.length);
size_t i;
foreach (c; r)
s[i++] = c;
import core.stdc.stdio;
puts(s.ptr);
}
```
Re: D: Convert/parse uint integer to string. (@nogc)
On Friday, 24 November 2023 at 09:35:00 UTC, BoQsc wrote:
I tried to look into https://dlang.org/phobos/std_conv.html
Most of the functions inside `std.conv` seem to be dependant on
[Garbage Collection](https://dlang.org/spec/garbage.html).
And I couldn't find a straightforward way to produce a `string`
value out of `uint` value.
How to convert or parse `uint` value to a `string` in `@nogc`
way?
I guess there are third-party libraries doing this. One would use
stdc functions such as sprintf. Probably, there should be a more
d-ish way.
```
import core.stdc.stdio : sprintf;
import core.stdc.math : log10;
import std.exception : assumeUnique;
import std.stdio : writeln;
size_t nod(int num){
return cast(size_t)((num==0)?1:log10(num)+1);
}
void main()
{
int myint = 23;
char[80] str;
sprintf(str.ptr, "%d", myint);
string _dstring = str[0..nod(myint)].assumeUnique;
writeln(_dstring);
}
```
D: Convert/parse uint integer to string. (@nogc)
I tried to look into https://dlang.org/phobos/std_conv.html Most of the functions inside `std.conv` seem to be dependant on [Garbage Collection](https://dlang.org/spec/garbage.html). And I couldn't find a straightforward way to produce a `string` value out of `uint` value. How to convert or parse `uint` value to a `string` in `@nogc` way?
[Issue 24256] New: `-preview=in` should allow array literals and delegate literals in a `@nogc` context
https://issues.dlang.org/show_bug.cgi?id=24256
Issue ID: 24256
Summary: `-preview=in` should allow array literals and delegate
literals in a `@nogc` context
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ogion@gmail.com
DMD allows passing array literals and delegate literals to `scope` parameters
in @nogc functions:
void foo(const scope int[]) @nogc {}
void bar(scope void delegate()) @nogc {}
void main() @nogc {
foo([1, 2, 3]);
int x;
bar(() { x++; });
}
I expect this to work with `in` parameters as well, since “input parameters
behave as if they have the `const scope` storage classes” according to spec.
But as of DMD v2.105.3 this fails to compile (`-preview=in` enabled):
void foo(in int[]) @nogc {}
void bar(in void delegate()) @nogc {}
void main() @nogc {
foo([1, 2, 3]);
int x;
bar(() { x++; });
}
app.d(4): Error: array literal in `@nogc` function `D main` may cause a GC
allocation
app.d(3): Error: function `D main` is `@nogc` yet allocates closure for
`main()` with the GC
app.d(6):`app.main.__lambda2` closes over variable `x` at app.d(5)
--
[Issue 24240] New: Missing @nogc compile error in -betterC leads to undefined reference linker error
https://issues.dlang.org/show_bug.cgi?id=24240
Issue ID: 24240
Summary: Missing @nogc compile error in -betterC leads to
undefined reference linker error
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andy.pj.han...@gmail.com
```
@nogc:
extern(C) void main() {
foo();
}
void foo() {
bar([1]);
}
void bar(int[]) {}
```
Compiling with `dmd a.d`, it correctly fails with:
```
a.d(8): Error: array literal in `@nogc` function `a.foo` may cause a GC
allocation
```
Compiling with `dmd -betterC a.d`, there is no compile error. Instead there is
a linker error:
```
/usr/bin/ld: a.o: in function `main':
a.d:(.text.main[main]+0x5): undefined reference to `_D1a3fooFNiZv'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
```
I don't see a good reason not to have a compile error with `-betterC`. The
linker error is harder to diagnose.
--
[Issue 23937] LDC with -nogc and DMD object.destroy
https://issues.dlang.org/show_bug.cgi?id=23937 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |MOVED --- Comment #2 from RazvanN --- Hello, this does not seem to be a dmd-druntime issue. Note that LDC has a modified version of druntime so from dmd's perspective this issue has nothing actionable. You can report this to ldc. > //scope( exit) c.~C(); // C++ style. doesnt compile This works if you call c.__dtor(); --
[Issue 23937] LDC with -nogc and DMD object.destroy
https://issues.dlang.org/show_bug.cgi?id=23937 --- Comment #1 from a11e99z --- ldc --release -nogc empl.d is working. strange. --
[Issue 23937] New: LDC with -nogc and DMD object.destroy
https://issues.dlang.org/show_bug.cgi?id=23937
Issue ID: 23937
Summary: LDC with -nogc and DMD object.destroy
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: blac...@bk.ru
code is totally @nogc
//~~
import std, core.lifetime;
class C {
@nogc:
long v;
this() @nogc { "C.this()\n".printf; }
~this() @nogc { "C.~this()\n".printf; }
void destroy() @nogc { "C.destroy()\n".printf; }
void sayHi() @nogc { "hi\n".printf; }
}
void[ __traits(classInstanceSize, C)] tmem;
void main() @nogc {
scope auto c = emplace!C( tmem );
//scope( exit) destroy( c); // Error: `@nogc` function `D main` cannot
call non-@nogc function `object.destroy!(true, C).destroy`
scope( exit) c.destroy(); // OK
//scope( exit) c.~C(); // C++ style. doesnt compile
c.sayHi();
}
//~~
1) cannot call global ::destroy( obj) in @nogc context so used own one.
https://issues.dlang.org/show_bug.cgi?id=22174
2) code compiles w/o -nogc switch and get strange error with it. why so?
\import\core\lifetime.d(107): Error: No implicit garbage collector calls
allowed with -nogc option enabled: `_d_array_slice_copy`
--
Re: DCV is @nogc nothrow now.
On Friday, 12 May 2023 at 12:22:06 UTC, Guillaume Piolat wrote: On Friday, 12 May 2023 at 08:41:56 UTC, Ferhat Kurtulmuş wrote: On Friday, 12 May 2023 at 07:40:54 UTC, Salih Dincer wrote: On Friday, 28 April 2023 at 13:50:35 UTC, Ferhat Kurtulmuş wrote: I see: "gamut": "~>1.0.0" "mir-algorithm": ">=3.15.3" "mir-core": "~>1.5.3" The first and third dependencies could be ~>1.0 and ~>1.5, there is a guarantee of non-breaking change outside majors. Contrarily, the second one (>=3.15.3) subscribe to future breakage in an eventual mir-algorithm v4. I will consider those and probably make the version changes you recommended. Thank you, Guillaume. DCV has many codes involved in your libraries.
Re: DCV is @nogc nothrow now.
On Friday, 12 May 2023 at 08:41:56 UTC, Ferhat Kurtulmuş wrote: On Friday, 12 May 2023 at 07:40:54 UTC, Salih Dincer wrote: On Friday, 28 April 2023 at 13:50:35 UTC, Ferhat Kurtulmuş wrote: Please give it a try and destroy me :) I've been pushing myself to try DCV for about a week now. But the libraries it depends on scare me. I would love to apply artificial intelligence in a video using only D. I guess that's not possible for now? I would like to thank dear Ferhat for his hard work and dedication... SDB@79 For a YOLO object detection you can take a look at https://github.com/aferust/dcv-tinyyolov3. I see: "gamut": "~>1.0.0" "mir-algorithm": ">=3.15.3" "mir-core": "~>1.5.3" The first and third dependencies could be ~>1.0 and ~>1.5, there is a guarantee of non-breaking change outside majors. Contrarily, the second one (>=3.15.3) subscribe to future breakage in an eventual mir-algorithm v4.
Re: DCV is @nogc nothrow now.
On Friday, 12 May 2023 at 07:40:54 UTC, Salih Dincer wrote: On Friday, 28 April 2023 at 13:50:35 UTC, Ferhat Kurtulmuş wrote: Please give it a try and destroy me :) I've been pushing myself to try DCV for about a week now. But the libraries it depends on scare me. I would love to apply artificial intelligence in a video using only D. I guess that's not possible for now? I would like to thank dear Ferhat for his hard work and dedication... SDB@79 For a YOLO object detection you can take a look at https://github.com/aferust/dcv-tinyyolov3.
Re: DCV is @nogc nothrow now.
On Friday, 12 May 2023 at 07:40:54 UTC, Salih Dincer wrote: On Friday, 28 April 2023 at 13:50:35 UTC, Ferhat Kurtulmuş wrote: Please give it a try and destroy me :) I've been pushing myself to try DCV for about a week now. But the libraries it depends on scare me. I would love to apply artificial intelligence in a video using only D. I guess that's not possible for now? I would like to thank dear Ferhat for his hard work and dedication... SDB@79 Hi Salih, Could you please provide some details about your problem, error messages etc?
Re: DCV is @nogc nothrow now.
On Friday, 28 April 2023 at 13:50:35 UTC, Ferhat Kurtulmuş wrote: Please give it a try and destroy me :) I've been pushing myself to try DCV for about a week now. But the libraries it depends on scare me. I would love to apply artificial intelligence in a video using only D. I guess that's not possible for now? I would like to thank dear Ferhat for his hard work and dedication... SDB@79
DCV is @nogc nothrow now.
I have been working on DCV for some time to make it GC-free. GC is good. However, people have a prejudice against GC, especially if computer vision is in question. You may probably ask if any performance improvement has been gained. I don't know at the moment; with some limited tests (for instance, convolution), there is no difference, I would say. I tested most of the things in video loops to detect memory leaks, and I believe we don't have any. For the rest, I will copy and paste some of the below information from the GitHub page https://github.com/libmir/dcv. - In the new API, all functions accept slice shells as Slice!(T*, N) as input. On the other hand, API functions return RC-allocated Slice!(RCI!T, N). In this way, ref-counted slices can be passed to API functions like input.lightScope. It is recommended to avoid using lightScope in loop bodies; instead, create a lightScope outside of the loop body before using it. It has a cost. - nogc capabilities of mir libraries and dplug:core are utilized when needed. - ThreadPool of dplug:core is used in the entire library for parallelism. - class Image and class Figure use manual memory management. A call of function destroyFigures deallocates all allocated figures automatically. If an Image instance is initialized with non-null ubyte[] data, this time, the Image instance behaves like a slice shell, and it does not attempt to deallocate the borrowed data slice. - All examples are up-to-date. Please refer to the examples instead of the docs at the moment. - There may be bugs in the library. We need more people to test for bugs. The docs and unittests are outdated. Please give it a try and destroy me :)
Re: @nogc and Phobos
On Tuesday, 14 March 2023 at 20:40:39 UTC, bomat wrote: Sounds intriguing. Anything I can look at yet? Or still all top secret? :) Oh, amazing! I let you on waiting for almost a month and I wouldn't had see it if I didn't came to post another question. I'm so so sorry for the waiting, I will not even use an excuse. So, if you are willing to make an account on [Codeberg](https://codeberg.org/), the repository is private but after making the account, follow [me](https://codeberg.org/rempas) and I will give you access! Tho, you may read something cringe! Be prepared, lol!
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 22:14:36 UTC, rempas wrote: The `foreach` will cover your needs like you said but ironically enough, I like and use the original `for` loop. Thanks for your reply as well, rempas... I guess I covered most things in my earlier reply, but on the `for` loop: Coming from Basic and then Pascal, when I first saw that atrocity I was like... seriously? I think most people don't see it anymore because they have become so used to it, but the sequence of abort condition and increment steps is completely arbitrary, and commas and semicolons are used like literally *nowhere else* in the language (C and C++ that is, not sure yet about D). It's a marvel of inconsistency. I don't mind it as much today, since I must have written thousands of `for` loops by now and I do it totally automatically. I just don't know how it could become such a success story in so many languages and it *just*. *won't*. *die*. :) Well, the competition is pretty weak, yeah. Tho based on my experience, it doesn't worth to waste your time on anything else at this point. We can speak about trying a different language after mine is out ;) Sounds intriguing. Anything I can look at yet? Or still all top secret? :)
Re: @nogc and Phobos
Thanks a lot for taking the time and replying in that much detail! On Saturday, 11 March 2023 at 21:07:18 UTC, H. S. Teoh wrote: I also came from a C/C++ background. The GC turned me off D for a long time, until one day I decided to just give it a try to see if it was all as bad as people made it sound. [...] That is actually not my issue at all. While I see the benefits of "manual" memory management, these quickly go away when it's done badly, and in my day job I am actually maintaining a project where it is a mess and just using a garbage collected language would have been a much better choice. Because guess what, if you go for manually managing your memory, you actually *have* to do the management properly. Why am I saying all this? Because to be frank, you haven't really used D if you've been avoiding its standard library like the plague. Again, I'm afraid this is a bit of a misunderstanding. I'm not trying to avoid the standard library, in fact I wanted to use it and thought I couldn't because I'm also using a @nogc library. But turns out I was just doing it wrong. :) As for implicit type conversions: I don't know where you got your information from, but D's implicit conversions are a WHOLE different world from C++. I am still a complete noob in D, at this point very little of my information comes from practical experience, but mostly what I've read in "Programming in D" by Ali Cehreli (yeah, I still kinda like books, I'm weird that way). As for the conversion, it might not be as bad as in C++ where it will just silently construct new objects as long as there's a ctor with a matching parameter list somewhere, but it will still implicitly cast an `enum` to its underlying type, or a `bool` to an `int`. Now you may call me too strict about this, or point out that it will never be a problem in any real world use case, but if you take this classic example (which happens to actually be in the book as well, p. 20): `(30 > 20) > 10`, equals `false`. Well at least you have to use the parantheses, which is an improvement I guess, but still, this is something that I hate to see in any language that calls itself type safe. You see, the second language I ever learned was Pascal, and while that has many issues of it's own, it irks me how so many modern languages do things wrong that Pascal did right as early as 1970. And to me, one of those things is that above code *should not even compile*. "True" should not be comparable to 10, because "True" is not a number. And it should not be treated as such just because of how it is stored internally, as this is, after all, just an implementation detail. When you ask someone on the street if "True" plus two was three, he would call you a fool, and so should your compiler. Otherwise in practice it's not even an issue IME. Yeah, probably right. Actually very few people have ever agreed with me on that one. Maybe I'm weird. :) For-loop syntax: I can't remember the last time I wrote one in D. Maybe I did like 1 or 2 times (across my 20+ D projects) when I really needed to do something weird with my loops. As I wrote, I expected as much. So it's not so much a real problem as a general concept that I dislike; even if something is rarely (if ever) used: when you put it into your language, why do it in such a weird and ugly way just to have it look similar to C? I don't get it, is all. But I also didn't get it in JavaScript or any other language that adopted the C syntax, so it's not D specific. Again, not something you'll understand if you never tried to use D in a serious way. Completely true. Again, I'm totally new to D and my criticism is kinda academic. I know that. I recommend actually trying to write D, not as transplanted C++, but the way D code is meant to be written. But this is actually my point. Since D is *not* C++, it should not have adapted the `for` or `switch` syntax in almost exactly the same weird way. And saying that I shouldn't bother because I can always choose to not use it just seems like a very bad argument to me, sorry. It's kinda like saying that C++ wasn't a bad language when you just ignore 50% of it, which most people actually do. :) As for const: I hardly ever use it. It's useful occasional for low-level code, but not much beyond that. My advice: don't bother. Just pretend it doesn't exist, and your life will be happier. [...] Same here. I have no problem with stuff in a language that I don't want to use, after all I guess you'll have that in every language. Still, especially as a beginner, I think it is legitimate to wonder why it was put in. `const` has always gotten a lot of heat by C++ programmers, so what is the reasoning behind putting an even stricter version of it into a language that aspires to be a cleaner and better version of C++? And again, I'm not trying to be the smartass who c
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 16:21:40 UTC, bomat wrote: first: I didn't want to sound aggressive or like I was trying to bash D, sorry if it came across like that. Oh don't worry! People have openly criticized (and still doing) the language before. It's nothing to worry, criticism help us becoming better. But I didn't got these vibes from your post to begin with ;) Second: I find it super interesting what you say about you not actually liking Phobos and the built-in structures of D. Although I have not seen very much yet, I think I have to agree to that. Well, when I first started using D, coding on it was very very easy and enjoyable. I didn't had to think a lot and things "just worked"™️. Then, things chanced... Haven't made anything at this point except for some small programs. Now, I'm making my first "big" project and it's a compiler for my new language. So ironically enough, that will be my first and final project in D. Although I come from a C++ background, I'm not exactly a fanboy of that language (you can probably tell, otherwise I wouldn't be here). My dear, if anyone would tell me that they are a fanboy of this mess called C++, I wouldn't believe them... But after hearing praise for D for being a cleaner and better version of C/C++, I am a bit disappointed so far, tbh. Well, of course we are a little bit disappointed when things are not tuned EXACTLY how we want them. There are things that D OBJECTIVELY does just wrong and they could have been much better. However, it's still much much much much better than C and even C++. And that's not a lie and I'm not a "fanboy". I tried to use them both for my project and D is straight up day and night with these two. If D has 3-4 annoying things, C and C++ have 10! And again, this is with `betterC` in mind. I don't even use the whole power of D. But again, nothing is perfect unless you build it, hence why I making my own that will include a lot of great features from D as it also objectively handles some things with a good way. but I think it repeats too many old sins, like implicit type conversions, the `for` loop syntax (although I guess one wouldn't need it that often because of `foreach`), Does it have "implicit" type conversion? I didn't even knew, lol! The `foreach` will cover your needs like you said but ironically enough, I like and use the original `for` loop. the `switch` `case` fallthrough, I have nothing to say for that, I have said it before and lots of others have as well. and the cancerous `const` (as far as I can tell, `immutable` is an even worse flavor of it). Yeah, another thing I'll change in my language. The way immutability is treated is so so bad for so many reasons. Despite all of that, I can't argue with the fact that it may still be the best compiled language currently around. Sadly enough, though, imo that isn't that much of a compliment. :) Well, the competition is pretty weak, yeah. Tho based on my experience, it doesn't worth to waste your time on anything else at this point. We can speak about trying a different language after mine is out ;)
Re: @nogc and Phobos
On Sat, Mar 11, 2023 at 04:21:40PM +, bomat via Digitalmars-d-learn wrote: [...] > Although I come from a C++ background, I'm not exactly a fanboy of > that language (you can probably tell, otherwise I wouldn't be here). > But after hearing praise for D for being a cleaner and better version > of C/C++, I am a bit disappointed so far, tbh. I don't want to go into > too much detail here to not derail the thread entirely, but I think it > repeats too many old sins, like implicit type conversions, the `for` > loop syntax (although I guess one wouldn't need it that often because > of `foreach`), the `switch` `case` fallthrough, and the cancerous > `const` (as far as I can tell, `immutable` is an even worse flavor of > it). [...] I also came from a C/C++ background. The GC turned me off D for a long time, until one day I decided to just give it a try to see if it was all as bad as people made it sound. I have to admit that GC phobia stuck with me for a long time, but once I actually started using the language seriously, I discovered to my surprise that it wasn't *that* big of a deal as I had thought. In fact, I found that I quite liked it, because it made my APIs cleaner. A LOT cleaner because I didn't have to pollute every function call with memory management paraphrenalia; they can be nice and clean with no extraneous detritus and things Just Work(tm). Also, the amount of time/effort spent (i.e., wasted) debugging memory problems was gone, and I was a LOT more productive than I ever was in C++. True, I have to relinquish 100% control of my memory, and as an ex-C++ fanboy I totally understand that it's not a pleasant feeling. But I have to say that I was pleasantly surprised at how much D's GC *didn't* get in my way, once I actually started using it for real (toy examples can be misleading). Why am I saying all this? Because to be frank, you haven't really used D if you've been avoiding its standard library like the plague. Not all of Phobos is GC-dependent; the range-based stuff, for example, lets you avoid GC use most of the time. True, for exceptions you need GC, but exceptions are supposed to be ... exceptions ... not the norm, and in practice it isn't really *that* big of a deal. You shouldn't be catching exceptions inside performance-sensitive inner loops anyway. D's strong points don't really show until you start using range-based stuff with UFCS chains -- now *that's* power. Even if you dislike the GC you can still mostly manage your own memory, and let the GC be the fallback mechanism for stuff you missed. As for implicit type conversions: I don't know where you got your information from, but D's implicit conversions are a WHOLE different world from C++. Walter has resisted adding implicit conversion mechanisms in spite of harsh criticism and constant pressure, and in practice, you aren't gonna see a lot of it in D code, if at all. It's not even close to C++ where SFINAE + Koenig lookup gang up on you from behind and you don't even know what hit you. Issues with implicit conversions in D only really come up if you go out of your way to abuse alias this and/or use short ints a little too zealously. Otherwise in practice it's not even an issue IME. For-loop syntax: I can't remember the last time I wrote one in D. Maybe I did like 1 or 2 times (across my 20+ D projects) when I really needed to do something weird with my loops. But foreach covers 90% of my looping needs, and while loops take care of the 9.9% of the cases. Besides, once you start getting used to UFCS chains and Phobos algorithms, most of the time you won't even be writing any loops at all. You won't believe how much more readable your code becomes when you can finally stop worrying about pesky fragile loop conditions and just tack on a couple more components to your UFCS chain and it just automagically takes care of itself. Again, not something you'll understand if you never tried to use D in a serious way. I recommend actually trying to write D, not as transplanted C++, but the way D code is meant to be written. As for switch: yeah D switch has some crazy parts (like Duff's device -- you can actually write that in D). But I've never needed to use it... also, final switch + enums = awesome. As for const: I hardly ever use it. It's useful occasional for low-level code, but not much beyond that. My advice: don't bother. Just pretend it doesn't exist, and your life will be happier. Well OK, once in a while you do need to deal with it. But if it were me, I'd avoid it unless I have to. It doesn't mix well with high-level code, I'll put it that way. Immutable is the same thing, I only use it as `static immutable` just so the compiler would put my data in the preinitialized segment. Other than that, I don't bother. T -- If you're not part of the solution, you're part of the precipitate.
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 13:18:13 UTC, rempas wrote: Even if the first was the case (which again, only things that need the GC will not be able to be used), D is far from been "useless". You can use `betterC` and use C's libraries. Personally, that's what I'm doing anyway. Even if there was no garbage collector and a runtime, I still don't like Phobos and the built-in structures of D. It is still far far better than pretty much any other (compiled) language out there in case of usability so it's not useless at all even if you cannot use the standard library! Hi rempas, just wanted to answer to this one separately for two reasons, first: I didn't want to sound aggressive or like I was trying to bash D, sorry if it came across like that. Second: I find it super interesting what you say about you not actually liking Phobos and the built-in structures of D. Although I have not seen very much yet, I think I have to agree to that. Although I come from a C++ background, I'm not exactly a fanboy of that language (you can probably tell, otherwise I wouldn't be here). But after hearing praise for D for being a cleaner and better version of C/C++, I am a bit disappointed so far, tbh. I don't want to go into too much detail here to not derail the thread entirely, but I think it repeats too many old sins, like implicit type conversions, the `for` loop syntax (although I guess one wouldn't need it that often because of `foreach`), the `switch` `case` fallthrough, and the cancerous `const` (as far as I can tell, `immutable` is an even worse flavor of it). Despite all of that, I can't argue with the fact that it may still be the best compiled language currently around. Sadly enough, though, imo that isn't that much of a compliment. :)
Re: @nogc and Phobos
Thanks for the responses everyone, that was all very helpful and got me on the right track. Especially this: On Saturday, 11 March 2023 at 14:41:01 UTC, Steven Schveighoffer wrote: I think it is an error to mark a library which centers on callbacks with always being @nogc. You can work around nothrow and @safe, but not @nogc. Turns out it was my fault. I was working off example code that came with d-imgui, and the original author took the (rather lazy) approach of wrapping the entire main loop into `nothrow @nogc:` I just got rid of that and only marked the callbacks accordingly. Now I can just set status data in the callbacks, then handle it in the main loop. Sorry, still kinda finding my feet here. :)
Re: @nogc and Phobos
On 3/11/23 7:04 AM, bomat wrote: Hi all, I am a C++ programmer in my "day job" and was playing around with D to maybe use it in a personal project. I'm using Dear ImGui for the graphical user interface, for which I use this port: https://github.com/KytoDragon/imgui/ It works fairly well so far, just one problem: Dear ImGui is obviously `@nogc`, and I noticed that it doesn't mix with standard library functions. I tried `std.process.executeShell()` (which I'd kinda need for my project unless I want do do OS specific API calls), and `std.stdio.writeln()` (which I won't exactly be needing, just as a very basic test). So my question is: Is Phobos essentially incompatible to `@nogc`? Or is there a trick for mixing GC code with non-GC code that I don't know? Most of Phobos uses exceptions, which require the gc. I'm assuming the second, for if the first was true I'd say that D would be pretty much useless when combined with non-D libs... I think it is an error to mark a library which centers on callbacks with always being @nogc. You can work around nothrow and @safe, but not @nogc. This also brings up a point that there just isn't a way to do a callback-centered library that can be simultaneously used with nogc or gc, unless you template based on that. It's not a good situation, and I don't know of a good solution. -Steve
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 12:04:25 UTC, bomat wrote: So my question is: Is Phobos essentially incompatible to `@nogc`? Or is there a trick for mixing GC code with non-GC code that I don't know? I'm assuming the second, for if the first was true I'd say that D would be pretty much useless when combined with non-D libs... Any function annotated with `@nogc` can only call other `@nogc` functions, but they can be called by *any* function. So it won't affect your use of the GC or Phobos in that regard. Or is there a specific problem you've encountered?
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 12:04:25 UTC, bomat wrote: Hello! First of all, let's start by making clear of what `@nogc` means. It it an attribute that is used one function signatures and it annotates that the garbage collector will not be used inside this function. However, in the scenario that we have `func1` that is annotated with `@nogc` and `func2` that is called by `func1`, I don't know if `func2` needs to be annotated with `@nogc` as well. This is not been said inside the SPEC (or at least, I didn't found it with the quick search I did) so someone could confirm or deny this if they know. It works fairly well so far, just one problem: Dear ImGui is obviously `@nogc`, and I noticed that it doesn't mix with standard library functions. Is it what people say "100% `@nogc`" which means that it doesn't use the garbage collector or does it use [betterC](https://dlang.org/spec/betterc.html)? So my question is: Is Phobos essentially incompatible to `@nogc`? Look [here](https://dlang.org/spec/function.html#nogc-functions) about the features that cannot be used with `@nogc`. Keep in mind that using `@nogc` in your project, will still have it link with Phobos and D's runtime library. `BetterC` is what disables the garbage collector completely (so no need for `@nogc`) but also doesn't make your binary/library link with D's runtime and Phobos. But if you don't use this mode, you will be able to link with the standard library and use the functions that do not use the garbage collector. Or is there a trick for mixing GC code with non-GC code that I don't know? For what I know, you can combine both methods by using the GC and also mannually allocating memory with libc's "malloc" (or of course your own allocator) but you'll probably have to look into some documentation on how to combine them without any sneaky bugs. However, you will probably not have to do anything "special" to make it work. As I never did it, maybe someone else could help on that one. I'm assuming the second, for if the first was true I'd say that D would be pretty much useless when combined with non-D libs... Even if the first was the case (which again, only things that need the GC will not be able to be used), D is far from been "useless". You can use `betterC` and use C's libraries. Personally, that's what I'm doing anyway. Even if there was no garbage collector and a runtime, I still don't like Phobos and the built-in structures of D. It is still far far better than pretty much any other (compiled) language out there in case of usability so it's not useless at all even if you cannot use the standard library!
@nogc and Phobos
Hi all, I am a C++ programmer in my "day job" and was playing around with D to maybe use it in a personal project. I'm using Dear ImGui for the graphical user interface, for which I use this port: https://github.com/KytoDragon/imgui/ It works fairly well so far, just one problem: Dear ImGui is obviously `@nogc`, and I noticed that it doesn't mix with standard library functions. I tried `std.process.executeShell()` (which I'd kinda need for my project unless I want do do OS specific API calls), and `std.stdio.writeln()` (which I won't exactly be needing, just as a very basic test). So my question is: Is Phobos essentially incompatible to `@nogc`? Or is there a trick for mixing GC code with non-GC code that I don't know? I'm assuming the second, for if the first was true I'd say that D would be pretty much useless when combined with non-D libs...
[Issue 23741] Functions in core.sys.windows.dbghelp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23741 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 23742] Functions in core.sys.windows.imagehlp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23742 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 23742] New: Functions in core.sys.windows.imagehlp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23742 Issue ID: 23742 Summary: Functions in core.sys.windows.imagehlp should be marked @nogc nothrow Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com The functions in core.sys.windows.imagehlp are Win32 functions and do not allocate gc memory or throw exceptions. --
[Issue 23741] New: Functions in core.sys.windows.dbghelp should be marked @nogc nothrow
https://issues.dlang.org/show_bug.cgi?id=23741 Issue ID: 23741 Summary: Functions in core.sys.windows.dbghelp should be marked @nogc nothrow Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com The function type aliases in core.sys.windows.dbghelp are Win32 functions and do not allocate gc memory or throw exceptions. --
[Issue 18830] Document Allowance for "new" with "scope" in @nogc Functions
https://issues.dlang.org/show_bug.cgi?id=18830 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dlang.org pull request #3515 "Fixed issue 18830 - document "new" with "scope" in @nogc Functions" was merged into master: - 9d04378250a90b506bf1ed22ff35d35edd762589 by RaresCon: Fixed issue 18830 - document "new" with "scope" in @nogc Functions - f5706c8e76ff48c92dd1e5e3ba7bcccb4e114a2f by RaresCon: Fix Issue 18830 - document "new" with "scope" in @nogc Functions https://github.com/dlang/dlang.org/pull/3515 --
[Issue 18830] Document Allowance for "new" with "scope" in @nogc Functions
https://issues.dlang.org/show_bug.cgi?id=18830 --- Comment #2 from Dlang Bot --- @RaresCon created dlang/dlang.org pull request #3515 "Fixed issue 18830 - document "new" with "scope" in @nogc Functions" mentioning this issue: - Fixed issue 18830 - document "new" with "scope" in @nogc Functions https://github.com/dlang/dlang.org/pull/3515 --
[Issue 20101] BetterC: Template instantiation in CTFE only context should skip codegen / nogc / ... Phases
https://issues.dlang.org/show_bug.cgi?id=20101 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23606 --
[Issue 20101] BetterC: Template instantiation in CTFE only context should skip codegen / nogc / ... Phases
https://issues.dlang.org/show_bug.cgi?id=20101 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #14789 "fix Issue 20101 - BetterC: Template instantiation in CTFE only contex…" was merged into master: - ab2a21273c951f050be7aef1a1981ff0aefc1bad by Walter Bright: fix Issue 20101 - BetterC: Template instantiation in CTFE only context should skip codegen https://github.com/dlang/dmd/pull/14789 --
[Issue 20101] BetterC: Template instantiation in CTFE only context should skip codegen / nogc / ... Phases
https://issues.dlang.org/show_bug.cgi?id=20101 --- Comment #2 from Walter Bright --- Noting that this worked in the __traits(compiles,...) was the clue I needed. Thanks! --
[Issue 20101] BetterC: Template instantiation in CTFE only context should skip codegen / nogc / ... Phases
https://issues.dlang.org/show_bug.cgi?id=20101 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14789 "fix Issue 20101 - BetterC: Template instantiation in CTFE only contex…" fixing this issue: - fix Issue 20101 - BetterC: Template instantiation in CTFE only context should skip codegen https://github.com/dlang/dmd/pull/14789 --
[Issue 18106] @nogc: yields a wrong error where @nogc on each definition does not
https://issues.dlang.org/show_bug.cgi?id=18106 Iain Buclaw changed: What|Removed |Added Priority|P3 |P2 --
[Issue 4677] disallow GC via cmd line argument -nogc
https://issues.dlang.org/show_bug.cgi?id=4677 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 14771] Hidden @nogc violation around closure creation
https://issues.dlang.org/show_bug.cgi?id=14771 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 18439] Error: cannot use operator ~= in @nogc delegate 'main.test.__lambda1'
https://issues.dlang.org/show_bug.cgi?id=18439 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 22653] @safe @nogc delegate should allocate but doesn't, calls member function on dead object
https://issues.dlang.org/show_bug.cgi?id=22653 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 15408] S.init for struct containing member field with array literal initializer fails @nogc
https://issues.dlang.org/show_bug.cgi?id=15408 Iain Buclaw changed: What|Removed |Added Priority|P1 |P2 --
[Issue 20091] nogc callback inferred as non-nogc
https://issues.dlang.org/show_bug.cgi?id=20091 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 22748] ~this() @nogc { synchronized ...... } liable to onMemoryOperationError
https://issues.dlang.org/show_bug.cgi?id=22748 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 21165] Spurious @nogc error with delegate taking `immutable size_t`
https://issues.dlang.org/show_bug.cgi?id=21165 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 19682] Unused alias causes @nogc error
https://issues.dlang.org/show_bug.cgi?id=19682 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 21803] "@nogc:" incorrectly propagates into function blocks, explicit "pure" too
https://issues.dlang.org/show_bug.cgi?id=21803 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 23287] Invalid @nogc code succeeds when compiling with -o-
https://issues.dlang.org/show_bug.cgi?id=23287 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 18058] @nogc and forwarding lazy argument, particularly with scope
https://issues.dlang.org/show_bug.cgi?id=18058 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 22506] Accessing immutable AA in @nogc with index results in compilation error
https://issues.dlang.org/show_bug.cgi?id=22506 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 18830] Document Allowance for "new" with "scope" in @nogc Functions
https://issues.dlang.org/show_bug.cgi?id=18830 Iain Buclaw changed: What|Removed |Added Priority|P1 |P3 --
[Issue 12808] Small amount of escape analysis to allow more @nogc functions
https://issues.dlang.org/show_bug.cgi?id=12808 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 17004] std.containers should be usable with @nogc
https://issues.dlang.org/show_bug.cgi?id=17004 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 18369] std.algorithm.skipOver should be @nogc and nothrow
https://issues.dlang.org/show_bug.cgi?id=18369 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 12768] Trivial uses of `std.algorithm.iteration : splitter` should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=12768 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 15484] core.memory.GC.disable() is not @nogc
https://issues.dlang.org/show_bug.cgi?id=15484 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 12805] @nogc std.range.iota(FP)
https://issues.dlang.org/show_bug.cgi?id=12805 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 18494] nogc ignores invariant
https://issues.dlang.org/show_bug.cgi?id=18494 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 13458] std.utf.decode not @nogc
https://issues.dlang.org/show_bug.cgi?id=13458 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 12736] @nogc std.algorithm.all
https://issues.dlang.org/show_bug.cgi?id=12736 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
[Issue 18119] Allow code that may allocated inside __ctfe condition branches in @nogc functions
https://issues.dlang.org/show_bug.cgi?id=18119 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --
