Tbox: A GLib-like cross-platform C library(github.com)
github.com
Tbox: A GLib-like cross-platform C library
https://github.com/tboox/tbox
18 comments
I see "Micro: compiling micro library (~64K) for the embed system", now that caught my attention!
Should I then assume that the compatible platforms are actually more than the listed Windows, Linux, Mac, and mobile OSes?
I'm on the front of AVR development, and cool new things always arrive late (understandably, if they arrive at all...) to our little corner of the world :(
But I assume that "embedded" here will mean mainly ARM.
(similarly, I'm still excitedly waiting for more progress on the Rust front :)
Should I then assume that the compatible platforms are actually more than the listed Windows, Linux, Mac, and mobile OSes?
I'm on the front of AVR development, and cool new things always arrive late (understandably, if they arrive at all...) to our little corner of the world :(
But I assume that "embedded" here will mean mainly ARM.
(similarly, I'm still excitedly waiting for more progress on the Rust front :)
Yes.
Your source files contain the following in the commented header:
"Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements."
Did you in fact specifically license it to the ASF? Or are you just licensing it under the Apache license?
"Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements."
Did you in fact specifically license it to the ASF? Or are you just licensing it under the Apache license?
I just used the Apache license.
Apache committer here - you’ve got the wrong header there. That one’s for source which has been committed to ASF repos under a CLA.
You want the header for non-ASF code which can be found here:
http://www.apache.org/licenses/LICENSE-2.0.html#apply
You want the header for non-ASF code which can be found here:
http://www.apache.org/licenses/LICENSE-2.0.html#apply
I think that if you're going to compare your library to GLib, then at least a basic comparison of features, side by side, should be available
I’m working on a compiler right now that generates C. Should I use this for the generated code? (Or should I use glib, musl, or uclib?)
A comparison chart would be helpful! Similar to: http://www.etalabs.net/compare_libcs.html
A comparison chart would be helpful! Similar to: http://www.etalabs.net/compare_libcs.html
You've been heavily downvoted because you made a category error. GlibC, musl, and uclibc are implementations of the c standard library[1]. Glib[2], this, and NSPR[3] (among others), on the other hand, abstract away platform-specific things. So whereas strcpy is a standard function that you can count on being there, the process for opening a window is different on windows, mac (quartz), mac (cocoa), unix (x11), unix (wayland), and others; the cross-platform libraries handle this and provide you with a single api for (for example) opening a window.
Now, as a language developer, you actually don't have to worry about any of these. The c standard library will be provided by the os and you don't have to think about it. Some programming languages that want to replace c don't rely on the c standard library, but you shouldn't have to worry about that. As for abstracting out different platform apis, I would say that doesn't really belong in your language itself.
1: https://en.wikipedia.org/wiki/C_standard_library
2: https://developer.gnome.org/glib/
3: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
Now, as a language developer, you actually don't have to worry about any of these. The c standard library will be provided by the os and you don't have to think about it. Some programming languages that want to replace c don't rely on the c standard library, but you shouldn't have to worry about that. As for abstracting out different platform apis, I would say that doesn't really belong in your language itself.
1: https://en.wikipedia.org/wiki/C_standard_library
2: https://developer.gnome.org/glib/
3: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
To solve the problem in a robust way, the C library has to be part of the target. For example on Debian Linux, glibc is the native libc. On Alpine Linux, musl is the native libc. In LLVM terminology, this is the "C ABI environment" part of the "target triple".
If your compiler supports cross compiling, you might look into the strategies that Zig does[1]. If it only supports native builds, you probably want to detect the native libc. Again here it might be useful to look at what Zig does[2].
[1]: https://ziglang.org/download/0.4.0/release-notes.html#Zig-sh... [2]: https://ziglang.org/download/0.4.0/release-notes.html#Libc-D...
If your compiler supports cross compiling, you might look into the strategies that Zig does[1]. If it only supports native builds, you probably want to detect the native libc. Again here it might be useful to look at what Zig does[2].
[1]: https://ziglang.org/download/0.4.0/release-notes.html#Zig-sh... [2]: https://ziglang.org/download/0.4.0/release-notes.html#Libc-D...
That is the standard library, TBOX is just a third-party library, providing some easy-to-use cross-platform modules.
Any plans to do a Libc too? A lot of embedded systems like ESP32 could really use a good Libc without having to pull in Linux.
I haven't got this plan yet., but the tbox has a lightweight and compact libc implementation built in. The interface name looks like this: tb_snprintf, tb_strlcpy, ...
You can see https://github.com/tboox/tbox/tree/master/src/tbox/libc
You can see https://github.com/tboox/tbox/tree/master/src/tbox/libc
> Should I use this? (Or should I use glib, musl, or uclib?)
I agree that a comparison would be good, but musl and glibc are low level fundamental API's for things like printf and opening files.
Glib and this are higher level libraries to build applications with. If you're building a compiler you probably want one of these, for the generated code it would depend a lot on the specifics.
Edit - I'll also add that a lot of people's experience with C seems to com from college or beginner material where they're learning in a very bare bones environment. Combine C and libraries like this and it's not just good for app development but can be great for scripting where python or bash would typically be used.
I agree that a comparison would be good, but musl and glibc are low level fundamental API's for things like printf and opening files.
Glib and this are higher level libraries to build applications with. If you're building a compiler you probably want one of these, for the generated code it would depend a lot on the specifics.
Edit - I'll also add that a lot of people's experience with C seems to com from college or beginner material where they're learning in a very bare bones environment. Combine C and libraries like this and it's not just good for app development but can be great for scripting where python or bash would typically be used.
Yes.
Congratulations on an absolutely massive achievement! I love seeing high-quality C libraries appear. What version of C does it target?
c99
Not supporting obsolete versions of C is utterly awesome.
C89 is too old, too many grammar restrictions. And now the mainstream compiler basically supports c99.
What grammar restrictions? I've converted a few C99 libraries to C89 (since i prefer that one and i often work with older compilers because they are faster) and 99% of the time the reason a library uses C99 is inline variable declaration (which IMO is a bad style, but that is subjective) and // comments (which most C89 compilers support as an extension anyway).
The versions do have other differences, of course, but they're rarely used (the next most common one is designated initializers, which for me are the most annoying to convert).
I mean, it is your code, i just found the grammar restrictions part weird since really there isn't that much of a practical difference between C99 and C89 to the point i personally never felt the need to use C99.
(note that i focus on the language bits, C99 provides some extra library functionality but even then the most useful part is stdint.h which can be implemented in almost any C89 compiler anyway)
The versions do have other differences, of course, but they're rarely used (the next most common one is designated initializers, which for me are the most annoying to convert).
I mean, it is your code, i just found the grammar restrictions part weird since really there isn't that much of a practical difference between C99 and C89 to the point i personally never felt the need to use C99.
(note that i focus on the language bits, C99 provides some extra library functionality but even then the most useful part is stdint.h which can be implemented in almost any C89 compiler anyway)
C89 cannot mix variable declarations and code.
printf("Hello World!\n");
int x = 7;
printf("%d!\n", x);
return 0;
Yes, that is what i meant with "inline variables". IMO this is usually a sign of code that is too long to be readable and if you really need that you should either split the function to make it more readable or, if that cannot be done, enclose the affected code in their own brackets (with a comment that makes it easy to distinguish). Brackets also make sure that the variable wont "outlive" its context (although again that is a sign of code that is too long).
Of course that is my opinion (and i'm generalizing of course), but that comes from my experience with working with others' code.
Of course that is my opinion (and i'm generalizing of course), but that comes from my experience with working with others' code.
Even if the function code is very short, I still like to define and declare variables nearby.
Unless a function has only two lines of code.
Unless a function has only two lines of code.
Right, that is your style, but i wouldn't call that "too many grammar restrictions" :-).
It's too many grammar restrictions for this person. That's obviously what's implied by the person's original comment.
That could be interpreted as sarcasm. It's not.
some would say that C itself is obsolete.. Ok, I can hear a bunch of people already piping up and whining how they're programming on a 8-bit toaster and only have a C compiler..but apart from that there are no real reasons to use C anymore since it's obsolete.
Until rust came along you had three non CG options C, C++ and ADA. If you also have a no heap requirement you're left with just C and ADA.
Rust is interesting if you can live with slow compile times and 4X the memory footprint of C.
Rust is interesting if you can live with slow compile times and 4X the memory footprint of C.
Why does the no heap requirement preclude C++? Obviously, you couldn't use much of the STL (not really a loss in constrained environments), but I don't see a reason to write off the language itself?
It is used in embedded. I think that refutes the claim.
The memory footprint thing shouldn’t be different now; we stopped using jemalloc by default.
how does it handle u_128 (IPv6 comparison/sorting/hashing)
two u_64 is .. sad (sometimes unavoidable)
no bzip2 but other good modern compressors which I guess is about what you need for jar and zip files.
openssl compatible crypto .. oy vey the chain of "who audits the code is now a mile long at the microphone"
two u_64 is .. sad (sometimes unavoidable)
no bzip2 but other good modern compressors which I guess is about what you need for jar and zip files.
openssl compatible crypto .. oy vey the chain of "who audits the code is now a mile long at the microphone"
There is no support for u_128 yet, but I can consider it.
If you think about radix tries and other data structures (AVL) it would be useful to be able to code good x>y tests against the binary state of IPv6. If you have to segment into two u_64 then shift-and-mask stuff becomes harder. So, purely for IPv6 (and I work with internet addresses a lot so my bias is showing) I think this makes sense.
But I totally get it may not be in your use case or first pass. Tiny home router builds? they'd want this. Anything doing IPv6 packet work testing or finding IPs in a structure will want this unless people code to the /64 model.
But I totally get it may not be in your use case or first pass. Tiny home router builds? they'd want this. Anything doing IPv6 packet work testing or finding IPs in a structure will want this unless people code to the /64 model.
Yes, I agree.
Congrats on shipping! This is really good advertisment for Xmake btw :)
I'm not seeing tests anywhere. Am I blind or are they hidden away or non-existent? Thx in advance.
There are some tests in the demo (https://github.com/tboox/tbox/tree/master/src/demo), but I still don't have time to write complete test cases. I'm sorry.
> I'm seeing tests anywhere. Am I blind or are they hidden away or non-existent? Thx in advance.
While this might be a valid point, I really don't like the manner in which it is expressed. Feigned surprise, pretend humility and, most importantly, lack of basic respect towards fellow developer(s).
While this might be a valid point, I really don't like the manner in which it is expressed. Feigned surprise, pretend humility and, most importantly, lack of basic respect towards fellow developer(s).
Wait, you cited my text and changed it from the original dropping a key word and then attacked me for it. Not cool. There is no feigned surprise or lack of respect either implied or actually present in my inquiry about the lack of tests.
why didn't you build off musl?
I don't want to have any third-party library dependencies.
Why was it written in C instead of Rust/C++?
Additionally why are there a bunch of generic sounding Chinese names in the comments with dead comments? Bot comments/SEO?
Additionally why are there a bunch of generic sounding Chinese names in the comments with dead comments? Bot comments/SEO?
The rust/C++ syntax is too complicated, I don't like it.
> "Bot comments"
Pretty obviously. Gods know why though.
Pretty obviously. Gods know why though.
No, some simple comments from some of my colleagues and friends were identified as bot comments. I'm sorry.
So your colleagues all created accounts between forty and seventy minutes ago to make positive comments (except for one account that's existed for two years, but has only ever commented on this guy's stuff)?
Even if this is the case, that's arguably just as much of a voting ring as bots.
Even if this is the case, that's arguably just as much of a voting ring as bots.
The project has been around for 10 years and has almost 2500 stars on Github. The creator is Chinese but working in English as a courtesy and has used this body of code to create a number of fascinating projects, including an x86 emulator.
What have you given to the programming world lately?
EDIT: it was pointed out that this last comment was abusive. Sorry about that.
What have you given to the programming world lately?
EDIT: it was pointed out that this last comment was abusive. Sorry about that.
Good for him. I haven't known how to program very much for very long, and am a student, but so what? Am I not allowed to mention someone breaking rules? If you look above, I gave credit where credit was due, and only mentioned this near the bottom as a reply to a relevant comment. Quit white-knighting; I'm sure the author can defend himself.
Duly noted. I was hot-headed. I apologize.
Their own account, only one.
I'm sure the intentions were good, but this is outside what the community considers polite behavior. The FAQ mentions this about voting: https://news.ycombinator.com/newsfaq.html.
If users aren't posting qua community members then the expectation is to provide a disclaimer.
If users aren't posting qua community members then the expectation is to provide a disclaimer.
Ok, thanks. Also, awesome work; this looks very useful.
Provides stream, container, iterator, algorithm, coroutine, database .. modules.
And we use xmake to build it.
And we use xmake to build it.
I wouldn't have thought to look, but I saw something about xmake the other day (by the same people). I still am probably going to stick with cmake (inertia), but cool stuff.