They've got a bunch of other cool projects, too: https://tboox.org/project/

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.

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

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?

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

Oh, got it, I will modify headers.

Thanks.

I have fix these headers in dev branch. Thank you for reminding.

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

Provides stream, container, iterator, algorithm, coroutine, database .. modules.

And we use xmake to build it.

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

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

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

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

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

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)

C89 cannot mix variable declarations and code.

    printf("Hello World!\n");
    int x = 7;
    printf("%d!\n", x);
    return 0;

This is a very serious restriction for me.

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.

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.

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.

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"

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.

Yes, I agree.

Congrats on shipping! This is really good advertisment for Xmake btw :)

What does "modern" mean in this context?

Ok, Now the title has been modified, maybe the previous title is not reasonable.

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

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.

I don't want to have any third-party library dependencies.

oh no I thought you were talking about a glibc replacement (making your own libc) while this is about glib as in gnome, sorry

it wouldn't be a dependency if you built upon it I mean. this is a glibc alternative right?

The rust/C++ syntax is too complicated, I don't like it.

It's a C library. If it were a Rust or C++ library it would be written in those languages.

That does not always necessarily follow. The VC runtime, for the C portion of the library, is now written in C++ internally.