作者 主题:替换C标准库:您的愿望清单? (Read 2084 times)

0位成员和1位访客正在查看此主题。

 在线的 硅向导

  • 超级贡献者
  • ***
  • 帖子:5929
  • 国家:  fr
回复:替代C标准库:您的愿望清单?
« 在以下问题上回复#25: 2021年1月8日,下午03:12:26»
除了替换不安全的功能(即使其中一些功能已被弃用)之外,我'd想查看标准的哈希表/词典。而且,正如您提到的,池分配功能。

 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#26: 2021年1月8日,下午05:18:57»
我认为您完全意识到挑战和问题。所以...这实际上意味着您要加倍努力并不要'不要使用C。如果您有好的想法,请展望未来,而不是过去。
你为什么坚持D,Rust和Go是"the future", and C is "the past"? 不,我对您的说服力或其他人说的没兴趣;我对赞成或反对或个人经历的逻辑论据感兴趣。

就像我说的,我不'想要更多抽象。 D ++是面向对象的,我不知道'不需要那种抽象。  I don'也不希望像Go这样的运行时;如果您曾经使用其他语言处理过C ++运行时,那么您就会知道为什么。 也许Go可以避免这种特殊的陷阱,但是这还有待观察。 我想要一种有效的低级系统编程语言,那就是C。 不,C并不是特别好。 标准库不是很好,很大一部分是通过将用POSIX C编写的程序与在标准C中执行相同操作的程序进行比较而容易地显示出来的,因此我想知道我们可以做的更好。 Rust最接近,但我'我还不相信它比C更好,我不知道'看不到我该如何在那做任何有意义的事情。

至于"better",我打算准备一个现实世界的可编译代码,每个人都可以查看并比较它们,并告诉我如何以及为什么'm wrong. 这将很有用。

我知道实际上不同的编程语言才是真正的止痛药。
是的,我同意。 也许有一天,我也会迈出这一步。

但是就目前而言,独立式C提供了一个简单的起点。  我打算创建该库,然后实现一些典型的服务守护程序,以便可以将它们与用C和其他语言编写的类似守护程序进行比较。 我希望有形的,真实的代码可以进行检查和比较,而不是抽象的示例或不费吹灰之力。 (并且不仅要比较人类可读的部分,还要比较生成的二进制文件以及运行时资源的使用。)

我想我'我错过了一些东西。托管的或独立的C环境是什么,或者,不同之处是什么?
在托管环境中,标准C库为您提供了许多功能,从malloc()到exit()。 在独立的环境中,您不会这样做;您只有一些宏(仍然可以包含特定的头文件)和可变参数支持(来自<stdarg.h>).

I'd想查看标准的哈希表/词典。
环境变量是每个进程都可以访问的词典的一个示例,对此我有一个想法。

你有接口的例子吗've found useful? 函数原型将提供一个很好的主意,并提供实际的用例示例。
比较例如使用qsort_r()而不是qsort()进行排序:比较操作通常需要外部信息,例如字符串中的偏移量或列以开始比较,并且将无类型的用户指针传递给比较函数使此操作在线程安全中变得容易一种方式,因为不需要使用全局变量。

和其他所有人一样,如果您发现编写低级代码时使用的特别有用的功能(服务守护程序,命令行实用程序等),请告诉我;最有趣的是 如何 / 为什么 you found it useful.
« 最后编辑:2021年1月8日,下午05:21:38通过名义动物 »
 

 离线 敦刻海

  • 超级贡献者
  • ***
  • 帖子:2489
回复:替代C标准库:您的愿望清单?
« 在以下回复#27: 2021年1月8日,下午05:47:04»
引用
在托管环境中,标准C库为您提供了许多功能,从malloc()到exit()。 在独立的环境中,您不会这样做;您只有一些宏(仍然可以包含特定的头文件)和可变参数支持(来自<stdarg.h>).

好,谢谢。我第一次'我遇到了这种区别。好吧,无论如何这些名字。

 

 离线 定点

  • 定期贡献者
  • *
  • 帖子:81
  • 国家:  德
回复:替代C标准库:您的愿望清单?
« 在以下回复#28: 2021年1月8日,下午7:43:45»
我认为您完全意识到挑战和问题。所以...这实际上意味着您要加倍努力并不要'不要使用C。如果您有好的想法,请展望未来,而不是过去。
你为什么坚持D,Rust和Go是"the future", and C is "the past"?

请严格遵守对方所说的话,否则我们不会取得任何进展。我从未说过D,Rust或Go是未来。我以这些语言为例,介绍了已开发的新语言并修复了C的严重缺陷。(我重复了我先前所说的内容:我明确不建议使用Go。)我并不是说这些语言是未来。我什至希望他们不是。

引用
不,我对您的说服力或其他人说的没兴趣;我对赞成或反对或个人经历的逻辑论据感兴趣。

那是什么样的反智态?有实际的研究可用,研究可以提供所有这些"logical arguments",是许多数学和CS界人士对DECADES所做的研究,其中有些人甚至很聪明。你告诉我"不,我对其他人说的不感兴趣"。好吧-您对我有什么期望?我应该如何应对?拍手您认为这样的话会让您成为自由思想家吗?老实说,我不'不知道该怎么做。

大学教师'不要误会我的意思:如果您对这些东西特别感兴趣,那么我绝对愿意谈论它。但目前我的印象是'并非如此。

顺便说一下,面向对象与此无关。 D(名称是D,不是D ++)支持对象方向,但这并不意味着-

不,我'对不起。我已经开始对101进行演讲了。't do that.
 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#29: 2021年1月8日,下午09:23:10»
我认为您完全意识到挑战和问题。所以...这实际上意味着您要加倍努力并不要'不要使用C。如果您有好的想法,请展望未来,而不是过去。
你为什么坚持D,Rust和Go是"the future", and C is "the past"?
请严格遵守对方所说的话,否则我们不会取得任何进展。我从未说过D,Rust或Go是未来。我以这些语言为例,介绍了已开发的新语言并修复了C的严重缺陷。(我重复了我先前所说的内容:我明确不建议使用Go。)我并不是说这些语言是未来。我什至希望他们不是。
你写了,
在过去的十年中,已经开发出了比C更好的选项(包括嵌入式用例),例如D,Rust或Go(我不知道)。'建议不要使用Go,但我当然必须在此处添加它)。
然后,
我认为您完全意识到挑战和问题。所以...这实际上意味着您要加倍努力并不要'不要使用C。如果您有好的想法,请展望未来,而不是过去。
I'对不起,但是我不明白我应该怎么解释这些,除了"don'不要使用C,因为它将回顾过去",并据此推断 例如 D, Rust, or Go are "the future"我应该研究的。

那是什么样的反智态?有实际的研究可用,研究可以提供所有这些"logical arguments",是许多数学和CS界人士对DECADES所做的研究,其中有些人甚至很聪明。你告诉我"不,我对其他人说的不感兴趣".
啊 "请严格遵守对方所说的话,否则我们不会取得任何进展。"

我没有这么遥远地说任何话。  I said, "坦白说,我的CS文章'在过去的十年左右的时间里,与着眼于健壮,高效,长期可维护的代码库相比,他们更专注于构建可帮助不熟练的开发人员编写代码以及自动检测和纠正其所产生的编程错误的抽象。 没有任何真正的发明或进步,热空气和喜爱的东西涌出。"  I later said, "不,我对您的说服力或其他人说的没兴趣;我对赞成或反对或个人经历的逻辑论据感兴趣。"

换句话说,关于CS的大多数CS文章(在ACM中,包括 托普拉斯 ),或者在实践中无关紧要,或者质量很差;通常都是。  Consider github中的编程语言和代码质量的大规模研究:被引用了126次,但最近 生殖研究 表明相同的数据实际上并不支持所声称的原始结论。 也许您认为好的例子中只有一个不好的例子,但是根据我的经验,这是当前CS文章中的典型例子。 当然,那里有许多好的论文描述了一种算法,甚至在某些特定情况下,即使对于某些工作负载,效率也会提高百分之几, 但是我没有'几年来,没有发现任何可以显着影响软件工程的东西。 没有任何实际意义上的差异。

也许我没有'没有足够的阅读;当然有可能! 如果您不同意,请仅向我指出一份您认为与低级系统编程有关的论文,如果/如果实施,将对软件项目有所帮助' code quality. 现在,我相信您会看到重大进展,其中我仅看到抽象的,偶尔的渐进式开发;我看不到任何真正影响实际应用软件工程的东西。

我对此的立场很简单:C是一种在实践中证明的语言,但是其标准库中有很多容易证明的问题。 C编译器不会强迫我们链接到标准库,因此创建替换库是非常简单的事情,该库不实现标准C函数,但提供了不同的集合。 我相信我至少对哪种set / API有部分了解"better",但我非常感谢其他人的经验和发现,因为这些肯定会有所帮助:我并不了解所有事情,而且我经常犯错。 意见没有理由的理由有用,因为有了理由,我就可以比较自己的理由,并决定自己的意见是否基于较弱的理由,是否应该改变。
除了垃圾收集(以及检测程序员错误的自动方法)以外,我几乎不了解与过去十年左右有关的低级系统编程相关的优秀CS文章。 绝对没有一个可以比独立的C和a更好地描述任何比我认为更好的东西"better" base library.
 
以下用户感谢这篇文章: 滴滴

 离线 边际稳定

  • 贡献者
  • 帖子:13
  • 国家:  我们
回复:替代C标准库:您的愿望清单?
« 在以下方面回复#30: 2021年1月8日,下午09:42:41»
第一件事是禁止free()并使C库基于垃圾回收。我不同意Apple的观点,而不是引用计数。 Boehm库运行良好,进行了一些修改-我大大减少了所需的静态内存量,并优化了对象大小存储桶以及许多其他功能。

我在这里不同意。 我认为,应该通过使语言更简单并减少麻烦来实现对C的改进,尤其是在更易于理解方面& simpler to predict. 垃圾回收的实现总是有极端的情况,并且很难预测行为(例如,运行时变慢)。

It'太糟糕了,以至于动态内存分配已经无法预测,我不知道't want more of this  :(

垃圾回收比malloc / free快。我可以(并且已经)证明,对于大范围的os程序,使用LD_PRELOAD用Boehm GC替换C库malloc可以使它们更快地完成处理和/或减少CPU时间。

那'即使在完全不了解它们现在在GC下运行的程序上也是如此。

正确编写的GC可以很容易地将最大暂停时间限制在无法察觉的水平。


那将取决于程序是否曾经垃圾回收。通过简单地不调用free并希望您在程序完成之前不耗尽内存,您可能会看到相同的性能提高。
 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#31: 2021年1月8日,晚上10:20:28»
垃圾回收比malloc / free快。我可以(并且已经)证明,对于大范围的os程序,使用LD_PRELOAD用Boehm GC替换C库malloc可以使它们更快地完成处理和/或减少CPU时间。
那将取决于程序是否曾经垃圾回收。通过简单地不调用free并希望您在程序完成之前不耗尽内存,您可能会看到相同的性能提高。
还有缓存效果。 意思是,如果GC而不是访问不同的缓存行,则导致该进程访问 相同的缓存行 (通过重用为该进程分配的相同内存区域),它实际上可以比永不free()代码以更少的挂钟时间运行,因为更少的缓存未命中。
 

 离线 布鲁斯胡特

  • 超级贡献者
  • ***
  • 职位:1962
  • 国家:  nz
  • 前身为SiFive,Samsung R&D
回复:替代C标准库:您的愿望清单?
« 在以下回复#32: 2021年1月8日,下午11:09:28»
第一件事是禁止free()并使C库基于垃圾回收。我不同意Apple的观点,而不是引用计数。 Boehm库运行良好,进行了一些修改-我大大减少了所需的静态内存量,并优化了对象大小存储桶以及许多其他功能。

我在这里不同意。 我认为,应该通过使语言更简单并减少麻烦来实现对C的改进,尤其是在更易于理解方面& simpler to predict. 垃圾回收的实现总是有极端的情况,并且很难预测行为(例如,运行时变慢)。

It'太糟糕了,以至于动态内存分配已经无法预测,我不知道't want more of this  :(

垃圾回收比malloc / free快。我可以(并且已经)证明,对于大范围的os程序,使用LD_PRELOAD用Boehm GC替换C库malloc可以使它们更快地完成处理和/或减少CPU时间。

那'即使在完全不了解它们现在在GC下运行的程序上也是如此。

正确编写的GC可以很容易地将最大暂停时间限制在无法察觉的水平。


那将取决于程序是否曾经垃圾回收。通过简单地不调用free并希望您在程序完成之前不耗尽内存,您可能会看到相同的性能提高。

是的,您也可以尝试。我有。 例如,使用gcc编译(运行时间相对较短的程序)。

你什么'会发现,即使是相对较小的编译,也会很快使用GB RAM。'做几个GC的速度更快。但不是太多。

也许我'将整理一个页面,介绍如何自己尝试该实验。
 

 在线的 魔法

  • 超级贡献者
  • ***
  • 帖子:2917
  • 国家:  PL
回复:替代C标准库:您的愿望清单?
« 在以下回复#33: 2021年1月9日,上午01:19:59»
固定int,long,char等的大小;大学教师'不要让它们针对特定平台。 在实践中,这意味着必须像stdint.h一样使用不同的类型名称(否则,您将破坏与其他代码的兼容性& compilers), 我通常会选择更明智的名字,例如   u8, u16, u32, u64,   s8, s16, s32, s64,   f32, f64 (而不是像uint32_t,uint64_t等之类的东西)
找到了x86用户 :D

C被设计为在32位比16位慢的平台上运行,并且在相反的情况下运行。它甚至可以支持36位CPU,尽管如今可能很少有人在乎。

我同意后一部分,标准的uint_t名称令人讨厌。
 

 离线 鲸鱼

  • 超级贡献者
  • ***
  • 职位:1147
  • 国家:  au
    • 哈勒斯特伦
回复:替代C标准库:您的愿望清单?
« 在以下回复#34: 2021年1月9日,上午01:44:52»
固定int,long,char等的大小;大学教师'不要让它们针对特定平台。 [...]
找到了x86用户 :D

我花了整整10分钟的时间来提出令人信服的辩护。 它所做的一切提醒我,是我想念我 雪笔记本电脑 (现在编辑7年?!?!)
« 最后编辑:鲸鱼2021年1月9日上午01:48:01 »
 
以下用户感谢这篇文章: 滴滴

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#35: 2021年1月9日,上午05:24:25»
C被设计为在32位比16位慢的平台上运行,并且在相反的情况下运行。它甚至可以支持36位CPU,尽管如今可能很少有人在乎。
这是完全正确的,但是我们所有的交换格式都使用这些基本整数和IEEE-754浮点类型。这就是我们真正需要它们的地方。

在实际应用中 size_t (在较小程度上, ü/整型ptr_t)是"common"整数类型,能够描述任何内存结构的大小(以char为单位,"byte").

两者之间的区别"int" and "long"之所以变得烦人,是因为在LP64 x86-64 ABI上,长"cheaper"而不是整数,因为本机通用寄存器的大小为64位。 在ILP64上,没有区别。 我们需要的是一组(可以描述)整数类型 至少 特定范围的值。 我们可以看看Fortran( 种类 =符号),但使其更简单,明确;以便声明一个无符号整数类型变量 , 我们'd use
    INT(0, max) ;
并声明一个有符号的整数类型变量 酒吧 ,
    INT(min, max) 酒吧 ;
预处理器宏的计算结果为可表示所有整数的标量无符号或有符号类型 直到并包括 最大限度 –但可能范围更大–使用当前硬件的最快表示和大小;如果在预处理时不存在合适的类型,则发出编译错误。 是的,这意味着例如
    typedef INT(0,256 * 256 * 256-1)  rgb_color;
    typedef INT(-1,1024 * 1024 * 1024-1)  my_size;
将是完全可接受的声明整数类型的方式。

不幸的是,C预处理器并没有真正使之成为可能。它需要一个三元宏表达式评估器,该评估器在预处理时进行评估,并在预处理阶段评估数值(使用基本+-* /整数算术)。 (不过,这对于标准C代码也肯定很有用。)

我们拥有的最好的,就是名字不好的 uintfast N _t 整型fastN _t types, with <stdint.h> defining them for N = 8, 16, 32, and 64. 我们可以为所有人定义它们 N 介于8到64之间,但由于没有GCC和clang编译为具有其他任何值的整数类型的硬件 N,有避风港'没有任何实际需要。 不过,也许我们至少应该 N 8/16/32的倍数?

对于这些类型,我仍然必须为它提供一个很好的简短描述性名称,也很容易键入。
 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#36: 2021年1月9日,上午05:26:43»
有一个主意确实困扰着我:  What if we used uNesNe 对于精确宽度类型,以及 uNsN 对于可能具有更大范围的快速类型?

换句话说, u32 == uintfast 32_t , 和 s64e == 整型64_t?

我知道这是与现有做法的重大突破,对许多人来说很奇怪,但是在我看来,这将更好地匹配实际用例。
如果您具有函数或局部变量,则要使用快速类型。  您仅应在数据结构(以及通过强制转换的算术表达式)中使用精确宽度类型。
« 最后编辑:2021年1月9日,上午05:28:28由名义动物 »
 

 离线 布鲁斯胡特

  • 超级贡献者
  • ***
  • 职位:1962
  • 国家:  nz
  • 前身为SiFive,Samsung R&D
回复:替代C标准库:您的愿望清单?
« 在以下回复#37: 2021年1月9日,上午06:08:05»
固定int,long,char等的大小;大学教师'不要让它们针对特定平台。 [...]
找到了x86用户 :D

我花了整整10分钟的时间来提出令人信服的辩护。 它所做的一切提醒我,是我想念我 雪笔记本电脑 (现在编辑7年?!?!)

真是的'的形状比我的2011年差得多11"MacBook Air(双核i7 1.8 GHz,2.9 GHz Turbo)

双1.7 GHz A15绝对不容小at。一世'在Odroid XU4中拥有四核A15 2.0,如果32位足够好,它会摇摆。一世'我很惊讶它可以依靠电池运行。好吧,我的意思是……任何*可以* ...只是时间不长。
 

 在线的 魔法

  • 超级贡献者
  • ***
  • 帖子:2917
  • 国家:  PL
回复:替代C标准库:您的愿望清单?
« 在以下回复#38: 2021年1月9日,上午09:06:48»
我花了整整10分钟的时间来提出令人信服的辩护。 它所做的一切提醒我,是我想念我 雪笔记本电脑 (现在编辑7年?!?!)
好的,因此您可能知道ARM除了加载/存储IIRC之外没有16位寄存器和16位操作。因此,也许32位非常适合ARM上的int,但然后尝试在AVR上使用它,看看会发生什么 :scared:

两者之间的区别"int" and "long"之所以变得烦人,是因为在LP64 x86-64 ABI上,长"cheaper"而不是整数,因为本机通用寄存器的大小为64位。 在ILP64上,没有区别。
在您真正需要64位之前,x86-64上没有比64位便宜的产品。有一整套32位寄存器,并且对它们进行了有效的全套操作。实际上,要获得64位算术运算,您需要在相应的32位指令中添加一个特殊的前缀字节。顺便说一句,访问R8-R15寄存器时也一样。老实说,x86-64是LP64架构-如果您真的坚持的话,它是一个i386,具有长指针并且能够执行64位算术运算。如果您考虑一下,它的主要设计目标是本机运行32位Windows(与Intel Itanic不同) :P
« 上次修改:2021年1月9日,上午09:14:05通过魔术 »
 

 在线的 滴滴

  • 常客
  • **
  • 帖子:286
  • 国家:  b
回复:替代C标准库:您的愿望清单?
« 在以下回复#39: 2021年1月9日,上午11:36:51»
昨天,我试图在i686 32位Linux机器上编译带有很多大模板的C ++项目,而g ++崩溃是因为无法管理超过2GB的堆栈或类似的东西。 CPU已经是64位的,但是我有两个内核和两个rootfs, 32位和64位,所以我将计算机重新启动到64位i686,一切正常。

gcc饿了
g ++看起来很饿
 

 在线的 滴滴

  • 常客
  • **
  • 帖子:286
  • 国家:  b
回复:替代C标准库:您的愿望清单?
« 在以下回复#40: 2021年1月9日,上午11:51:39»
我同意后一部分,标准的uint_t名称令人讨厌。

我不同意。我不知道'不会感到烦人,但相当优雅,实用和连贯 :D
 

 在线的 硅向导

  • 超级贡献者
  • ***
  • 帖子:5929
  • 国家:  fr
回复:替代C标准库:您的愿望清单?
« 在以下回复#41: 2021年1月9日,下午04:58:29»
我同意后一部分,标准的uint_t名称令人讨厌。

我不同意。我不知道'不会感到烦人,但相当优雅,实用和连贯 :D

同上。这实际上是std C类型的一致命名约定,我也在自己的代码中使用过。
当然不应该 '不能改变。较短且不那么一致的标识符不仅会变得不一致,甚至可能不明确,而且会大大增加标识符冲突的可能性,因此,std理事会很乐意尽一切可能避免这种冲突。
 

 在线的 魔法

  • 超级贡献者
  • ***
  • 帖子:2917
  • 国家:  PL
回复:替代C标准库:您的愿望清单?
« 在以下回复#42: 2021年1月9日,下午7:36:34»
鲸鱼 提出的集合并没有前后矛盾或令人困惑,在许多实际的C项目中也使用了该集合。

至少,该死的 _t 。好像我没有't know that 整型NN 是一种类型,好像每个人都在't使用仍会突出显示它的编辑器  | O
« 上次编辑:2021年1月9日,晚上07:38:31通过魔术 »
 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#43: 2021年1月10日,上午05:58:50»
有没有人真的喜欢任何特殊的功能接口?

当我'我已经提到过,我真的很喜欢 getline(),因为它避免了行长限制。 (也许应该有一个可选的长度限制,或者是最大的内存使用限制。)  I'd love a getdelim() 它使用一组可能的定界符而不是单个字符,并且取反(只读取输入,只要它们在指定集中即可),类似于strspn()和strcspn();但不占用定界符(如getdelim()一样)。 这将允许直接在类似文件的流上进行词法分析,以及通用的换行符支持,而开销却很小。 我认为它不是一级流类型'd最好使缓冲区类型(只读,读写,只写)公开此功能,并附加到文件描述符。 我认为将流抽象明确地描述为抽象也可以帮助新程序员更全面地了解Linux / BSD / etc。操作系统操作。

我也发现 iconv_open(), iconv() , iconv_close() 对于字符集转换非常强大; POSIX 正则表达式 (regcomp(),regexec(),regfree())用于正则表达式; nftw() 用于遍历文件系统树(尽管它使用的文件描述符数量需要工作,并且需要atfile支持); scandirat() 用于列出目录内容; glob()用于查找与模式匹配的文件(除非它也需要atfile支持)。

我打算公开而不是open() 打开( dirfd , 路径名, 什么 , 如何 [, 模式 ]) , 和 如何 包含影响文件描述符的标志,以及 什么 影响文件名的分辨率(O_DIRECTORY,O_BENEATH,openat2()RESOLVE_标志)。 (所需标志的数量超过了32个,因此我认为不必将其分成更大的类型,而是将其故意分成两个更好)。 

由于Unix域套接字和命名管道(FIFO)在文件系统中可见,我认为我们应该通过以下方式公开它们: 什么 flags explicitly.  A synthetic dirfd 常量将公开抽象的Unix域套接字(在文件系统中不可见),带有 如何 确定是连接还是听,以及 什么 确定套接字类型(流,数据报,seqpacket)。 希望是鼓励为IPC使用Unix域套接字。

(我确实认为由于开发历史的缘故,必须使用mkfifo(),bind()和connect()来访问文件系统可见的FIFO和套接字是一个愚蠢的复杂问题,并且上述内容只是为了解决这一问题,而不提供抽象性)
« 最后编辑:2021年1月10日,上午06:09:05由名义动物 »
 

 离线 敦刻海

  • 超级贡献者
  • ***
  • 帖子:2489
回复:替代C标准库:您的愿望清单?
« 在以下回复#44: 2021年1月10日,上午11:34:40»
引用
当我'我已经提到过,我真的很喜欢 getline(),因为它避免了行长限制。

但它'不一致。有时您必须要free(),有时则不必,即使您说自己不这样做,有时也必须要free()'想要任何东西!我认为它'尝试覆盖太多的基础,最好将其分为两个功能:一个分配内存,另一个使用预分配的内存。

编辑:也是'通话阻塞。当然,我们今天都使用RTOS,但有时我们不使用't(这是专门针对小型嵌入式系统的,'别忘了)。如果没有't封锁可以足够容易地添加封锁,反之则不那么容易。
« 上次编辑:2021年1月10日,上午11:38:10 by dunkemhigh »
 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#45: 2021年1月10日,上午11:53:38»
引用
当我'我已经提到过,我真的很喜欢 getline(),因为它避免了行长限制。
但它'不一致。有时您必须要free(),有时则不必,即使您说自己不这样做,有时也必须要free()'想要任何东西!我认为它'尝试覆盖太多的基础,最好将其分为两个功能:一个分配内存,另一个使用预分配的内存。
我不知道'不能理解你的意思。  You start with
代码: [选择]
char   *buffer_ptr = NULL;
size_t   buffer_max = 0;
或搭配
代码: [选择]
size_t   buffer_max = somenumber;
char   *buffer_ptr = malloc(buffer_max); /* verified to have succeeded */
buffer_ptr 必须始终为NULL或malloc(),calloc(),realloc()或aligned_alloc()返回的动态分配内存的指针。 它不能也不能指向静态分配的内存。

要读取输入行,您需要
代码: [选择]
ssize_t  len = getline(&buffer_ptr, &buffer_max, file_handle);
如果 len==-1,那么要么没有更多数据可读取,要么发生错误。

无论结果如何,始终可以通过以下方法丢弃缓冲区:
代码: [选择]
fr ee(buffer_ptr);
buffer_ptr = NULL;
buffer_max = 0;
因为 免费(空) 是安全的,即使这样做, buffer_ptr == NULL.

您一定要知道 getline() 调用,该函数可能已修改 buffer_ptrbuffer_max;您不能假定它们没有变化。

TL; DR:您可以从NULL指针和零大小开始,或者已经动态分配了缓冲区,并且可以随时随意丢弃(或窃取动态分配的缓冲区)。  After you'完成后,您总是会丢弃缓冲区。 非常一致,非常简单,非常强大。

那么,不一致之处是什么?
« 最后编辑:2021年1月10日,上午11:56:30通过名义动物 »
 

 离线 西瓦斯塔加

  • 超级贡献者
  • ***
  • 帖子:3458
  • 国家:  科幻
回复:替代C标准库:您的愿望清单?
« 在以下回复#46: 2021年1月10日,下午12:54:56»
基本的C语言实际上是相当不错的,大多数功能都与设计愚蠢的标准库有关。同样,大多数复杂的事情都与库有关。人们认为他们更喜欢"higher level"语言具有核心语言功能,但我认为它们实际上喜欢上述语言附带的易于使用且功能强大的库。

使用C,总是需要做一些额外的内务处理,但是没有理由为什么搜索,连接,解析和生成字符串例如必须是100行精巧的工作,而对于在其中使用两行代码则必须如此。"modern"语言。有了一个像样的现代图书馆,它在C中将是10行工作。

因此,我认为该项目正处于正确的轨道上。独立的C加上一些核心库功能(那些可能是由编译器内置程序提供的,而不是实际上链接到stdlib的功能)很好,例如memcpy或malloc,但是由所有复杂,不安全和无用的库引起的混乱"helpers"使成熟的标准C变得比原来更难。
 

 离线 敦刻海

  • 超级贡献者
  • ***
  • 帖子:2489
回复:替代C标准库:您的愿望清单?
« 在以下回复#47: 2021年1月10日,下午03:14:19»
这会缓冲行直到它'完全阅读,然后?如果该流是一个串行端口,那么在每次调用-1之后,它是否会返回,同时缓冲输入,直到看到分隔符,然后返回缓冲区长度?如果是这样,我会误解说明。

 

 离线 名义动物

  • 超级贡献者
  • ***
  • 帖子:2329
  • 国家:  科幻
    • 我的主页和电子邮件地址
回复:替代C标准库:您的愿望清单?
« 在以下回复#48: 2021年1月10日,下午04:07:47»
这会缓冲行直到它'完全阅读,然后?如果该流是一个串行端口,那么在每次调用-1之后,它是否会返回,同时缓冲输入,直到看到分隔符,然后返回缓冲区长度?如果是这样,我会误解说明。
简明阅读 IEEE标准1003.1-2017 表示如果发生错误,getline()和getdelim()应该返回-1,并设置errno,但大多数当前实现都返回当前缓冲的数据。 他们中的大多数人还假定read()返回短计数时,这是由于输入结束或错误导致的,而这仅仅是因为't true in practice.

您和POSIX描述的行为–当基础描述符处于非阻塞状态时,调用将返回一个错误,指示如果缓冲区不包含定界符和输入结束符hasn,则它将阻塞'尚未收到(因为缓冲区填充read()调用报告错误,EAGAIN / EWOULDBLOCK)–显然是有意义的。 当底层的read()被信号传递中断时,这也适用。 而不是返回缓冲区中可能包含的任何内容,它应该返回一个错误(EAGAIN / EWOULDBLOCK或EINTR)。

就像我说的,我喜欢界面;不一定是实施细节(无论如何我还是认为它有问题)。
 

 离线 敦刻海

  • 超级贡献者
  • ***
  • 帖子:2489
回复:替代C标准库:您的愿望清单?
« 在以下回复#49: 2021年1月10日,下午4:13:24»
好的。那我撤回反对。
 


分享我

 掘客   Facebook   SlashDot   可口的  Technorati   推特    谷歌    雅虎
中频