From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-2.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, PDS_OTHER_BAD_TLD,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4F7201F910 for ; Thu, 17 Nov 2022 11:00:06 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="v+x6JMIM"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7C7B9395B405 for ; Thu, 17 Nov 2022 11:00:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C7B9395B405 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668682805; bh=CkM13tEym7oYh0L53R0y53GweOTR7JQlHOuBMrd5sbk=; h=Subject:To:Cc:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=v+x6JMIMuuhnvR9VnVDKDWOqIsisK0JQfBkEQVTQJuE5v66vvM07jBh6Vde6DAabn 9k3+U4Tom1syDdffWjUqXsF8C/oAay/jpRYiaEoS01kXOi0IMPNu57Vwy+Wb2BC452 TrUq4qwoIWaZl9SvpmfhVbXfEhXgjenDxdrowJV8= Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id CA7CC394243F for ; Thu, 17 Nov 2022 10:59:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA7CC394243F Received: from [IPv6:240e:358:1127:2800:dc73:854d:832e:3] (unknown [IPv6:240e:358:1127:2800:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 3013C6676B; Thu, 17 Nov 2022 05:59:38 -0500 (EST) Message-ID: Subject: Re: Why is glibc not extensive? To: A Cc: libc-alpha@sourceware.org Date: Thu, 17 Nov 2022 18:59:31 +0800 In-Reply-To: References: <3a62e9dd71c1e542e38d6444c955a44185e07936.camel@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Xi Ruoyao via Libc-alpha Reply-To: Xi Ruoyao Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, 2022-11-17 at 16:24 +0530, A wrote: > On Thu, Nov 17, 2022 at 3:16 PM Xi Ruoyao wrote: > >=20 > > On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote: > > > Hi, > > >=20 > > > 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. > >=20 > > Because it will save more man hours by implementing them in a separate > > library.=C2=A0 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. > >=20 >=20 > 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. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University