* Why is glibc not extensive? @ 2022-11-17 6:35 A via Libc-alpha 2022-11-17 9:46 ` Xi Ruoyao via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: A via Libc-alpha @ 2022-11-17 6:35 UTC (permalink / raw) To: libc-alpha Hi, In my opinion, glibc should have support for maps, sets, balanced binary trees, many more string functions, etc. (I know tree and hash are there in glibc), so that developers don't have to implement them themselves, thus saving lots of man hours all over the world. This will also make C more user friendly like C++ and Java. Amit ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 6:35 Why is glibc not extensive? A via Libc-alpha @ 2022-11-17 9:46 ` Xi Ruoyao via Libc-alpha 2022-11-17 10:54 ` A via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: Xi Ruoyao via Libc-alpha @ 2022-11-17 9:46 UTC (permalink / raw) To: A, libc-alpha On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote: > Hi, > > In my opinion, glibc should have support for maps, sets, balanced > binary trees, many more string functions, etc. (I know tree and hash > are there in glibc), so that developers don't have to implement them > themselves, thus saving lots of man hours all over the world. Because it will save more man hours by implementing them in a separate library. You can link the library against any libc (glibc, musl, msvcrt, binoic, the libc on Mac OS X - I can't recall the name, ...) instead of adding the implementation into all libc implementations. > This will also make C more user friendly like C++ and Java. Glibc just contains one implementation of C standard library, it's not "the reference implementation": there is just no such a thing in the world. The proposal of changing the spec of C language or standard library should be sent to WG14, not here. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 9:46 ` Xi Ruoyao via Libc-alpha @ 2022-11-17 10:54 ` A via Libc-alpha 2022-11-17 10:59 ` Xi Ruoyao via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: A via Libc-alpha @ 2022-11-17 10:54 UTC (permalink / raw) To: Xi Ruoyao; +Cc: libc-alpha On Thu, Nov 17, 2022 at 3:16 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote: > > Hi, > > > > In my opinion, glibc should have support for maps, sets, balanced > > binary trees, many more string functions, etc. (I know tree and hash > > are there in glibc), so that developers don't have to implement them > > themselves, thus saving lots of man hours all over the world. > > Because it will save more man hours by implementing them in a separate > library. You can link the library against any libc (glibc, musl, > msvcrt, binoic, the libc on Mac OS X - I can't recall the name, ...) > instead of adding the implementation into all libc implementations. > So, do glibc developers also take care of musl, msvcrt, etc.? I didn't know this. And if not, then why would glibc developers bother about other libc implementations. So, implementing a balanced binary tree in 10 - 20 libraries will consume more man hours than thousands of programmers around the world trying to implement balanced binary tree in their C projects? I don't believe this. > Glibc just contains one implementation of C standard library, it's not > "the reference implementation": there is just no such a thing in the > world. The proposal of changing the spec of C language or standard > library should be sent to WG14, not here. Hmm...I will see if I can contact them. I searched on Internet but couldn't figure out who is the right person to contact for this. Do you know who should I contact? Amit ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 10:54 ` A via Libc-alpha @ 2022-11-17 10:59 ` Xi Ruoyao via Libc-alpha 2022-11-17 11:08 ` A via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: Xi Ruoyao via Libc-alpha @ 2022-11-17 10:59 UTC (permalink / raw) To: A; +Cc: libc-alpha On Thu, 2022-11-17 at 16:24 +0530, A wrote: > On Thu, Nov 17, 2022 at 3:16 PM Xi Ruoyao <xry111@xry111.site> wrote: > > > > On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote: > > > Hi, > > > > > > In my opinion, glibc should have support for maps, sets, balanced > > > binary trees, many more string functions, etc. (I know tree and hash > > > are there in glibc), so that developers don't have to implement them > > > themselves, thus saving lots of man hours all over the world. > > > > Because it will save more man hours by implementing them in a separate > > library. You can link the library against any libc (glibc, musl, > > msvcrt, binoic, the libc on Mac OS X - I can't recall the name, ...) > > instead of adding the implementation into all libc implementations. > > > > So, do glibc developers also take care of musl, msvcrt, etc.? I didn't > know this. And if not, then why would glibc developers bother about > other libc implementations. Because if the fancy features are supported by Glibc but not other libc implementations, the programmers will likely re-implement the feature anyway because they want there program functional with different libc implementations. > So, implementing a balanced binary tree in 10 - 20 libraries will > consume more man hours than thousands of programmers around the world > trying to implement balanced binary tree in their C projects? I don't > believe this. It will consume more man hours than implementing a balanced binary tree as a separate library and link all these projects to the library. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 10:59 ` Xi Ruoyao via Libc-alpha @ 2022-11-17 11:08 ` A via Libc-alpha 2022-11-17 11:13 ` Xi Ruoyao via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: A via Libc-alpha @ 2022-11-17 11:08 UTC (permalink / raw) To: Xi Ruoyao; +Cc: libc-alpha On Thu, Nov 17, 2022 at 4:29 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Thu, 2022-11-17 at 16:24 +0530, A wrote: > > So, do glibc developers also take care of musl, msvcrt, etc.? I didn't > > know this. And if not, then why would glibc developers bother about > > other libc implementations. > > Because if the fancy features are supported by Glibc but not other libc > implementations, the programmers will likely re-implement the feature > anyway because they want there program functional with different libc > implementations. They will not implement again. They will copy from glibc.Currently, everyone is implementing their own and using lots of man hours. Copying is 5 minutes job. Amit ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 11:08 ` A via Libc-alpha @ 2022-11-17 11:13 ` Xi Ruoyao via Libc-alpha 2022-11-17 11:19 ` Xi Ruoyao via Libc-alpha 0 siblings, 1 reply; 7+ messages in thread From: Xi Ruoyao via Libc-alpha @ 2022-11-17 11:13 UTC (permalink / raw) To: A; +Cc: libc-alpha On Thu, 2022-11-17 at 16:38 +0530, A wrote: > On Thu, Nov 17, 2022 at 4:29 PM Xi Ruoyao <xry111@xry111.site> wrote: > > > > On Thu, 2022-11-17 at 16:24 +0530, A wrote: > > > So, do glibc developers also take care of musl, msvcrt, etc.? I didn't > > > know this. And if not, then why would glibc developers bother about > > > other libc implementations. > > > > Because if the fancy features are supported by Glibc but not other libc > > implementations, the programmers will likely re-implement the feature > > anyway because they want there program functional with different libc > > implementations. > > They will not implement again. They will copy from glibc.Currently, > everyone is implementing their own and using lots of man hours. > Copying is 5 minutes job. Copying from Glibc to another project (which is not under GPL or LGPL) is not allowed by LGPL. So why not just post your implementation and tell others to copy from it? -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Why is glibc not extensive? 2022-11-17 11:13 ` Xi Ruoyao via Libc-alpha @ 2022-11-17 11:19 ` Xi Ruoyao via Libc-alpha 0 siblings, 0 replies; 7+ messages in thread From: Xi Ruoyao via Libc-alpha @ 2022-11-17 11:19 UTC (permalink / raw) To: A; +Cc: libc-alpha On Thu, 2022-11-17 at 19:13 +0800, Xi Ruoyao via Libc-alpha wrote: > On Thu, 2022-11-17 at 16:38 +0530, A wrote: > > On Thu, Nov 17, 2022 at 4:29 PM Xi Ruoyao <xry111@xry111.site> > > wrote: > > > > > > On Thu, 2022-11-17 at 16:24 +0530, A wrote: > > > > So, do glibc developers also take care of musl, msvcrt, etc.? I > > > > didn't > > > > know this. And if not, then why would glibc developers bother > > > > about > > > > other libc implementations. > > > > > > Because if the fancy features are supported by Glibc but not other > > > libc > > > implementations, the programmers will likely re-implement the > > > feature > > > anyway because they want there program functional with different > > > libc > > > implementations. > > > > They will not implement again. They will copy from glibc.Currently, > > everyone is implementing their own and using lots of man hours. > > Copying is 5 minutes job. > > Copying from Glibc to another project (which is not under GPL or LGPL) > is not allowed by LGPL. > > So why not just post your implementation and tell others to copy from > it? For example there is already https://c-util.github.io/c-rbtree/ It's dual-licensed with Apache license so there will be no license problem to copy from it. If you don't need to hack the code you can also just link to this library. If a project is not using this library, it's either (1) In this project AVL tree (or something) performs better than this RB tree implementation; (2) The maintainer is stupid. (3) The maintainer just loves to reinvent wheels. Adding an rbtree into Glibc won't resolve any one of (1) (2) (3). -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-11-17 11:20 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-17 6:35 Why is glibc not extensive? A via Libc-alpha 2022-11-17 9:46 ` Xi Ruoyao via Libc-alpha 2022-11-17 10:54 ` A via Libc-alpha 2022-11-17 10:59 ` Xi Ruoyao via Libc-alpha 2022-11-17 11:08 ` A via Libc-alpha 2022-11-17 11:13 ` Xi Ruoyao via Libc-alpha 2022-11-17 11:19 ` Xi Ruoyao via Libc-alpha
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).