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

31–40 of 186 posts

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

#31

Post by chubot »

svdree wrote: post #27
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?

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where 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. The convenience of only having to include a single header is nice for quick weekend p…

Thanks for the link.

Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.

I'm still not convinced. I am convinced about a .c and .h -- that's how sqlite does it. Going to just a .h seems to provide negligible benefit and confuses the implementation and interface. It probably confuses a lot of tools too, e.g. source navigation tools, code coverage, code instrumentation, etc.

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

#33

Post by asveikau »

dangerbird2 wrote: post #28
kilpikaarna wrote: post #22

Earlier quoted context omitted.

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

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 are the same thing in a lot of people's minds, I think increasingly these days as C expertise is diminishing.

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

#34

Post by TeMPOraL »

svdree wrote: post #27
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?

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where 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. The convenience of only having to include a single header is nice for quick weekend p…

> 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 files, etc."

--

Unrelated, and probably colored by the fact I first learned to program on Windows, but I don't get the problem. Windows applications usually bundle DLLs with them and keep them locally, unlike Linux applications which typically install dependencies globally through a package manager. I don't think I've ever had a big DLL problem developing on Windows, whereas on Linux I've been occasionally bit by the "oh this software requires X <= v2.1 but you can't have that since something else is already using X v2.3 and that would be downgrade".

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

#35

Post by flohofwoe »

svdree wrote: post #27
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?

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where 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. The convenience of only having to include a single header is nice for quick weekend p…

Some advantages of header-only vs .h/.c pair:

- you can build simple tools contained in a single .c file, and you dont't need a build system for this (e.g. just call "cc tool.c -o tool" instead of mucking around with Makefiles or cmake)

- the library can be configured with macros before including the implementation (e.g. provide your own malloc, assert, etc...), with the implementation in a .c file, these config macros must be provided via command line args, which implies a build system

- you can put the implementations for all header-only libs used in a project into a single .c file instead of compiling the multiple .c implementation files, this might speed up compilation

Single-header libs have some of the advantages that a proper module system would bring to C and C++ (e.g. extremely simple integration into own project and increased compile speed), but without all the complexity of implanting a module system into C or C++.

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

#36

Post by pka »

> No global or hidden state

Does that mean that one can detach an input field, save its state somewhere, create a new one and attach it somewhere else again and have it appear exactly as it was before (i.e. cursor position, selection, focus, etc)?

That's one of the pain points with VDOM frameworks (i.e. need to diff around UI components which shouldn't lose state), so I'm curious if this library gets it right.

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

#37

Post by flohofwoe »

chubot wrote: post #31
svdree wrote: post #27

Earlier quoted context omitted.

Sean Barrett (who I think popularized the idea) has a FAQ on this ( https://github.com/nothings/stb ) where 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. The convenience of only having to include a single header is nice for quick weekend p…

Thanks for the link. Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc. I'm still not convinced. I am convinced about a .c and .h -- that's how sqlite does it. Going to just a .h seems to prov…

> and confuses the implementation and interface

Normally you have the implementation inside an "#ifdef IMPLEMENTATION" block, and the API interface (public structs and functions) outside of the implementation block, and all private functions inside the implementation block are defined as 'static' so they are not visible outside the special implementation source file. In the places where you include the header for normal use, only the public interface is accessible.

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

#38

Post by c-smile »

badsectoracula wrote: post #25
kzrdude wrote: post #15

Earlier quoted context omitted.

because dependency management and build systems are hard to get right and not standardized. It's a simple distribution model that works everywhere.

Yes, but why a single header file and not a pair of .c and .h files (personally this is what i do for my small libs)? With a single header file you'd need the user to put it in a specially designated "this is the implementation" .c file anyway. I can see it for C++ which supports placing code in a header as a language, but C requires jumping over awkward preprocessor hoops that can be avoided by using a .c file.

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.

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

#39

Post by TeMPOraL »

mwcampbell wrote: post #17

Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640

Your note is good in general, but for this particular case, note this is an immediate mode GUI library. I.e. the kind of stuff that's primarily used in videogames. A typical game (or supporting tool) where this is included would already be not accessible (imagine playing e.g. an RTS with a screen reader).

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

#40

Post by mwcampbell »

bastijn wrote: post #24
mwcampbell wrote: post #17

Before you use this in your next important application, please read the comment on accessibility that I posted the other day on the LCUI thread: https://news.ycombinator.com/item?id=16329640

Accessibility is always important to mention, which is why we should thank you for reminding us. In return, you have to understand that not every next important application will be used by blind people or people with disabilities, and as of such there is still room for people to develop new UI toolkits if they so please. Again, thanks for reminding everybody. People need to think about it. Your advice could be toned…

Thanks for your feedback. I do try to control the tone of my comments on this subject, because I get emotional about it, but I know a vitriolic comment isn't helpful. Still, I find it hard to moderate the scope of my advice. Several years ago, a blind acquaintance of mine briefly lost his job because some developer didn't pay enough attention to accessibility in an application that he was required to use. His employer re-hired him shortly afterward, because they found another role for him. But in the interim, he went through all the feelings associated with losing one's job, and he was lucky to regain employment so soon. I don't ever want anyone to go through that again because some developer used an inaccessible GUI toolkit, even if that toolkit was meant only for games. That's why I'm as vocal as I am here.
Post reply on HN