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

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.

Is it what people say "100% @nogc" which means that it doesn't use the garbage collector or does it use betterC?

Look here 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.

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.

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!

On Saturday, 11 March 2023 at 12:04:25 UTC, bomat wrote:

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?

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:

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

On Saturday, 11 March 2023 at 13:18:13 UTC, rempas wrote:

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

On Saturday, 11 March 2023 at 16:21:40 UTC, bomat wrote:

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

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.

My dear, if anyone would tell me that they are a fanboy of this mess called C++, I wouldn't believe them...

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.

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.

I have nothing to say for that, I have said it before and lots of others have as well.

Yeah, another thing I'll change in my language. The way immutability is treated is so so bad for so many reasons.

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

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:

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.

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

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.

Yeah, probably right. Actually very few people have ever agreed with me on that one. Maybe I'm weird. :)

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.

Completely true. Again, I'm totally new to D and my criticism is kinda academic. I know that.

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

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 could have done it better, I'm just trying to understand it.

Taking your first steps into a new language, you just stumble across these things.

Thanks again for your time!

On Saturday, 11 March 2023 at 22:14:36 UTC, rempas wrote:

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

Sounds intriguing. Anything I can look at yet? Or still all top secret? :)