Live data from Hacker News

Nuklear: A single-header ANSI C GUI library

github.com

161–170 of 186 posts

Re: Nuklear: A single-header ANSI C GUI library

#161

Earlier quoted context omitted.

How exactly does a compiler generate "riskier" optimizations from a single-header as opposed to separate translation units? I fail to understand how after the pre-processing phase, this would be less safe. For instance, the optimizer might conclude that it's safe to either elide an inline function call or compile it very differently if it sees that you're referring to the same object in two separate parameters. If th…

Thank you. Please indulge me if you have time with two more questions: 1. In some libraries (SQLLite for instance, and libev too I think) the authors have a script that "amalgamates" all sources into a single translation unit.Their reasoning being that a compiler with full-visibility of the source can do global / interprodecural optimization that would not be possible otherwise. Is there any sense in this if it pract…

1. It's almost certain that the speed increase you'd get from intentionally merging a lot of source files into one is less than what you could achieve with a more intelligent profile-based refactoring approach. I wouldn't have a very high opinion of the approach you describe, not knowing any more about those libraries or their authors' motivations.

2. Read a lot of C code written by people like Sean Barrett. You would just pick up a lot of bad habits from mine. :)

Re: Nuklear: A single-header ANSI C GUI library

#162
post #154
post #142

Earlier quoted context omitted.

Easy, one links to the binary library. It really feels strange that young devs find it so hard to use a linker.

It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.

Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file.

So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time.

The time I waste installing a binary library?

Once per platform for the longevity of the project.

The time I waste building software with header only library?

Every single time I do make all.

Re: Nuklear: A single-header ANSI C GUI library

#163
post #113

Earlier quoted context omitted.

Make is so simple that it can actually build you single file project without a makefile with less characters to type: make tool Et voilà.

Errr, I actually have to spend 5 minutes googling how to install make on Windows, then getting mingw and hating myself. So no, no it's really not that simple in general.

Not really fair to blame make for your daft OS.

Re: Nuklear: A single-header ANSI C GUI library

#164
post #162
post #154

Earlier quoted context omitted.

It feels strange that you're unfamiliar with the headaches that brings for cross platform projects.

Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file. So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time. The time I waste installing a binary library? Once per platform for the longevity of the project. The time I wa…

The point of single-file header libraries is that generally they are relatively small, and do not rely on linking with other libraries (outside the C runtime).

Re: Nuklear: A single-header ANSI C GUI library

#165
post #77

Earlier quoted context omitted.

Yes it works on windows. Hopefully this does not come across as rude, but from the readme "It was designed as a simple embeddable user interface for application and does not have any dependencies, a default renderbackend or OS window and input handling but instead provides a very modular library approach by using simple input state for input and draw commands describing primitive shapes as output. So instead of provi…

Yes, I did see the readme and I do remember thinking "so does this means it runs on Windows as well?". It's not unheard of for linux-specific projects to simply ignore the existence of Microsoft world. So I cloned the repository and opened up nuklear.h. If this library supports Windows, then CERTAINLY this file has to include "Windows.h", somewhere, right? Uhm.. no, it does not. Bad sign, I thought. So, still confuse…

That would be a bit inaccurate though - the core library doesn't have a backend. The example you found e.g. implements an OpenGL backend.

It doesn't reference any external libraries (maybe C runtime). IIRC it does not assume you have a malloc() function by default; you provide one or use a #define before include to tell the header it can rely on standard malloc.

Re: Nuklear: A single-header ANSI C GUI library

#166

C# Wrapper please!

There should be a link on the page. I started binding it to C# over Christmas out of frustration of one not existing, and someone else quickly picked it up and made a cleaner binding that I recommend more. Google NuklearDotNet for the latter.

Re: Nuklear: A single-header ANSI C GUI library

#167
post #162

Earlier quoted context omitted.

Those headers have code that most likely require linking with other libraries, many of each are not available in source code that one can dump into an header file. So it appears like a little convenience just for not having to deal with installing binary libraries, at the expense of wasting everyone's time. The time I waste installing a binary library? Once per platform for the longevity of the project. The time I wa…

The point of single-file header libraries is that generally they are relatively small, and do not rely on linking with other libraries (outside the C runtime).

That might be the point, but it doesn't mirror many use cases.

Re: Nuklear: A single-header ANSI C GUI library

#168
post #102
post #89

Earlier quoted context omitted.

I have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. I mean, we've been nicely organising our sources in files, modules and libraries for 30 years, and that's been fine: very easy, logical and giving us many benefits (such as quick partial builds, splitting different operations, isolating problems f…

I have not heard this 'criticism' ever before and it's absolutely ridiculous on so many levels to me as a person tangentially interested in gamedev, C, C++, runtimes, system programming, retro stuff, history of gaemdev, etc. 1. Why would a web dev suddenly decide to write in such a spartan way an algorithm heavy library in C or C++? This makes no sense except to somehow tie modern web dev failures like left pad with…

That's all fine and dandy. You can quote all the shiny names you want from your domain and write a novel about them as it seems you are in the mood for doing that, it will not change anything to what I witness on each C forum I follow: it is always:

1. young people

2. coming from Javascript

3. coming from the land of IDEs which blur the difference in nature between files, between external and internal files, between copy inside the project and inclusion/linking from outside, etc.

4. who take a try at C, because they have heard C is hardcore or something like that and they want to taste low-level to become real programmers, not just web devs

5. who offer or request single header libraries because they have no idea it could be otherwise, or because they think linking or writing a basic makefile is an issue an enormous amount of work, because they come from the land of language-dependant automatic package managers.

That's somehow the same horrible movement that ends up giving us projects which ship with all the dependencies inside the package. Well, not all dependencies, just almost all, because there will always be a random couple of libraries you'll have to install yourself, without knowing why... And then those 'internalised' libraries will never get patched, never get updated, never get fixed, that's wonderful.

End of story. I do not even know why, along your text wall, you go on fighting things you pretend I have said, when I haven't. I haven't spoken of this library in particular, I haven't spoken of gamedev (I would not touch that with a 10 feet pole), I have spoken of what I witnessed. And that's a true phenomenon that started only 2 or 3 years ago.

Re: Nuklear: A single-header ANSI C GUI library

#169
post #89

Earlier quoted context omitted.

I have mostly seen it done by (young) people who come from web dev. They bring their bad habits together with them. And they usually don't get a very warm welcome for that. I mean, we've been nicely organising our sources in files, modules and libraries for 30 years, and that's been fine: very easy, logical and giving us many benefits (such as quick partial builds, splitting different operations, isolating problems f…

What are you talking about, C doesn't have a concept of a module or a library in the first place. Nothing about C is easy or logical. C only makes sense in 1965 on PDP7. All these hacks just work around the inherent shittyness of C/C++.

Not sure why you felt necessary to create an account to post this message.

It is not funny and yet it is wrong on all accounts.

Do I even need to discuss that C doesn't have libraries???

And a module == a compilation unit.

Re: Nuklear: A single-header ANSI C GUI library

#170
post #140
post #13

I really do not understand why 'single header' is considered a good thing, but I see this more and more often on libraries. What is the reason all the code is put in the header file?

Developers that don't want to bother how to properly use a linker.

Apparently, passing "-lmylib" to a compiler/linker has become a terrible effort indeed.
Post reply on HN