Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nuklear: A single-header ANSI C GUI library

github.com

Post reply on HN
Print view View original

141–150 of 186 posts

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

#141

Post by pjmlp »

v_lisivka wrote: post #100
TeMPOraL wrote: post #34

Earlier quoted context omitted.

> he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files That part was justified by deploying libraries for Windows. Going for one file only was justified by this: "You don't need to zip or tar the files up, you don't have to remember to attach two…

For some reason, problems with DLL libraries are called as "DLL hell", not "SO hell". ;-) If your software needs library foo.so.x while other application needs library foo.so.y, just put both into /usr/lib. Problem solved.

Easy, Windows already had dynamic loading on Windows 3.x, which was the same model used by OS/2, while UNIX was still trying to figure out how to implemente dynamic libraries.

The first versions of dynamic linking on UNIX basically required patching a.out files, before ELF was designed.

So of course the expressetion regarding compatibily issues with dynamic libraries came to be "DLL hell", there weren't .so to talk about.

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

#142

Post by pjmlp »

c-smile wrote: post #129
badsectoracula wrote: post #53

Earlier quoted context omitted.

Why you need to do that with .c files? You can just drop the .c/.h pair into the same place as you would put the single .h file and the rest of your C/C++ files and use it like that.

Let's say you need zip lib functionality in your project. If it will be available as set of .h files you would include it by one line `#include zip.h` in your .c file. But libzip is made of .c files. How you would include it in your multiplatform project ? Visual Studio, XCode, etc... In general it would be great if C has `#include source "some.c"` feature. So you would add single file zip-lib.c that will contain `#i…

Easy, one links to the binary library.

It really feels strange that young devs find it so hard to use a linker.

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

#143

Post by gmueckl »

loup-vaillant wrote: post #95
c-smile wrote: post #38

Earlier quoted context omitted.

With .h only files, when you need to include needed functionality, you modify only your own source file. But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools. Think about the whole zoo: Visual Studio, XCode, Code::Blocks, make, NMake, etc.

> But with .c files, when you have multiplatform project, you need to put it in other "3rd party" tools. No you don't: just act as if you've written the damn thing yourself. Your tools don't have to know. How being multiplatform changes anything?

It changes everything. Each platform brings its own preferred build system with it, which needs a copy of a definitive and explicit lost of all source files to compile the project. This is cumbersome to maintain. Header files on the other hand are licked up be the compiler automatically after seeing the include statement in the source. So this is actually much less time consuming to maintain.

Also, it shows that building C and C++ is a sad affair.

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

#144

Post by pjmlp »

asveikau wrote: post #33
dangerbird2 wrote: post #28

Earlier quoted context omitted.

Reimplementing parts of the standard library is important for applications where you don't neccessarily have access to a standards-compliant libc (read Windows), or if you have need custom malloc/free implementations. Similar techniques are used in automake and similar build generators to provide non-standard libc function implementations. precompiled headers can help with the fact that good portions of the header wi…

I think you completely missed the point of what you're replying to. You can put those reimplentations in a different file . You don't have to expose the consumer of the library to them by jamming the whole thing, both interface and implementation, in a single header. This is like library design by the folks who mistakenly say that what they do with '#include ' is they are "including a library". Eg. Compile and link a…

Yeah it looks like they are afraid of touching a linker.

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

#145

Post by printf_kek0 »

CamperBob2 wrote: post #124
printf_kek0 wrote: post #18

Earlier quoted context omitted.

I would also like an explanation. The author(s) of Musl (libc alternative) mention on this page that it can potentially invoke undefined behavior: https://wiki.musl-libc.org/alternatives.html However, having used a few of these "single-header" libraries my main concern is navigating a 9000 sloc header file as opposed to a neatly re-factored version... An explanation of how undefined behaviour is possible would be wel…

An explanation of how undefined behaviour is possible would be welcome. Short summary: compilers that enable strict aliasing assumptions by default can introduce bugs into otherwise-working code by assuming that a pointer to one type will never refer to a variable of another type. This assumption is perilous but considered worthwhile by many, since it allows the compiler to take advantage of early-out optimizations a…

I agree with the last part; should ask the Musl author(s) to substantiate this assertion.

> [...] the standard should have included a keyword -- or the compiler authors a flag -- to allow people to opt in to these sorts of optimizations rather than requiring them to opt out.

As an amateur Linux kernel hacker, I see hacks in the kernel that circumvent compiler bugs and unexpected behavior because of compiler defiance of standards. The rants on lkml seem to assign most of blame to the compiler authors of gcc. Here is one of Linus' (many) denunciations of gcc:

https://lkml.org/lkml/2003/2/26/158

But also Andrew T: https://stackoverflow.com/a/2771041 who claims - if I understand correctly - that strict-aliasing was already part of the C89/C90 standard but that compiler authors didn't implement the standard correctly.

> It is way too late to change the way C works by default by doing stuff like this.

One thing that I am confused about in your explanation is this:

> Under these conditions, a single-header library can result in "riskier" optimizations that the compiler wouldn't attempt if the same code resided in its own translation unit.

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.

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

#146

Post by FraKtus »

FraKtus wrote: post #131
random_upvoter wrote: post #70

As a small criticism, looking at the project page I get no clue whether this library works on Microsoft Windows.

Yes you have a win32 and direct x 9 and 11 backend...

And to add more, this is one of my favourite about it, it's very easy to have a tiny .exe with no DLL dependencies thanks to that...

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

#147

Post by CamperBob2 »

printf_kek0 wrote: post #145
CamperBob2 wrote: post #124

Earlier quoted context omitted.

An explanation of how undefined behaviour is possible would be welcome. Short summary: compilers that enable strict aliasing assumptions by default can introduce bugs into otherwise-working code by assuming that a pointer to one type will never refer to a variable of another type. This assumption is perilous but considered worthwhile by many, since it allows the compiler to take advantage of early-out optimizations a…

I agree with the last part; should ask the Musl author(s) to substantiate this assertion. > [...] the standard should have included a keyword -- or the compiler authors a flag -- to allow people to opt in to these sorts of optimizations rather than requiring them to opt out. As an amateur Linux kernel hacker, I see hacks in the kernel that circumvent compiler bugs and unexpected behavior because of compiler defiance…

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 the function is implemented in a separate file, the optimizer has to assume that the function does something it doesn't know about.

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

#148

Post by FraKtus »

FraKtus wrote: post #130

I love it because I can write applications for iOS macOS android windows and have most of the code identical. There is no need of resources to make that easy. Almost too good to be true.

I could make an iOS application that is only 1 MB in size thanks to Nuklear.. More and more users will not want to try an app if it feels bloated. Nuklear allows to generate tiny binaries, I appreciate that.

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

#149

Post by a_t48 »

moefh wrote: post #91
kaslai wrote: post #85

Earlier quoted context omitted.

The C preprocessor is the least of your worries with regard to compile times. Parsing a #if 0 can be done almost as quickly as a memcmp operation. Even my naive implementation can process an #if 0 at around 600 MBps. Even if you had a gigabyte of text in an #if 0, that's only about 2 more seconds on the compile, provided your disk can manage the throughput.

> Even if you had a gigabyte of text in an #if 0, that's only about 2 more seconds on the compile Are you sure your implementation is correct? How does it handle this: #if 0 "\ #endif \ " #endif I'm not saying gcc's and clang's preprocessors are not really fast, but preprocessing is trickier than most people expect. In particular (as you can see from my example), while skipping over an "#if 0" you still have to split…

I agree with the sentiment, but it should be easy enough to smash line continuations together while you're searching for that #endif (famous last words)

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

#150

Post by FraKtus »

kilpikaarna wrote: post #22
zevv wrote: 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?

Especially when that single header is over 13k lines and reimplements half the standard library. This looks pretty cool and I have an idea for an OpenGL project that needs a GUI, so I'll probably try it out at some point, but it doesn't really seem as lean and straightforward as the blurb implies...

once you grasp the concept of immediate mode it is straight forward. You need to parse system events and feed them to Nuklear, then you make a single function that will draw your interface and update the application state variables you need. I like a lot the fact that within just a few lines of code I can have a GUI and focus on the main work...
Post reply on HN