这里有一个类似的问题,但它没有有价值的信息,所以我想再问一遍 - 是否可以使用constexpr函数加载任意文件的内容？我知道这似乎是不可能的,因为在这种情况下无法调用允许文件I/O(fopen,open...)的所有可能的函数constexpr.但是 - 由于这里有许多人关注c ++ 17的开发并且正在进行 - 是否有希望进一步的标准将包含一些文件I/O API,它们将constexpr在编译时用于加载文件？
仅仅为了比较--Haxe允许通过编译时宏执行几乎任何操作,因此在C++中使用类似的东西会非常酷.例如,通过反序列化文件生成类实例.
这是(至少对我来说)在语言之间移动时过度复杂化的典型案例.是的,您可以实现将编译时文件加载添加到C++中的功能,我们还可以添加运行时反射.但是在我看来,这些并不是必需的,也不是想要的功能.
如果你有编写需要的程序的技能constexpr,你可以理解预构建事件的概念(使用Microsoft术语),如果你能够读取文件,你应该有足够的能力编写代码来解析文件到其他格式.
在这种情况下,编译时解决方案是编写一个独立的工具来解析有问题的文件,并生成一个.h(头文件)文件,其中包含所需的常量和对这些常量的评估.然后,可以在运行构建过程之前运行此工具.
因此,你的constexpr就变成了一个恒定的表达式
以"程序版本号"为例,常见的解决方案是使用开发人员IDE或独立工具创建包含作为软件版本的常量值的头文件.
许多FOSS软件在其./configure脚本中包含这样的功能- 从Git或类似地解析当前版本号 - 这意味着任何内置版本的软件都可以输出构建号,从而允许跟踪问题.
简而言之 - 如果c ++ 17或任何其他未来版本提供您正在寻找的功能,我会非常惊讶和失望 - 这样做增加了理解用户文件系统的要求,并且只能成功实现最佳功能留给最终用户.
但是,我们不应该陷入尝试添加每个可能的功能以试图取悦每个人的陷阱.~Bjarn Stroustrup
通俗地说,就像出售一辆自行车以及单一尺寸的头盔和自行车短裤(法律要求用户使用).它可能适合大多数用户的需求,但试图用我的腰围适合所述短裤将是...有问题的.
想象一下,为架构,嵌入式系统等之间的交叉编译器添加了复杂性.
这可能不是一个完美的答案 - 并且在某种程度上是基于意见的; 我试图提供的是一种理解,虽然可以说大多数用户都是面向桌面的,但添加这样的东西会使嵌入式系统和其他应用程序的编译器开发变得非常复杂.这就是C++试图避免的.
在评论中指出"为什么不让编译器只将文件内容添加为a char *,这是一个很好的问题!在这方面我有两点要提出.
char*的constantexp？如果是这样,那么你将需要一个循环和变量 - 你无法可靠使用的东西.并再次-什么比这些简单的例子更复杂变得十分复杂,很难以标准定义,如果文件是二进制？它应该是文字吗？什么是线路结尾？应该解析吗？
同时,您可以轻松使用现有工具,甚至可以与其他方法结合使用.例如,编写一个解析二进制文件的工具,将其重新编码为一系列转义序列(例如:) \0x0, \0x12, \0x22,将其自动添加到定义指向所述数据的指针的头文件中.然后,#include这个头-你有你想要的东西,对于平台上的工作,并没有可能建立在C++标准的漏洞可能导致固有的复杂性.
请记住,C++作为一种语言最终会从非常糟糕的新闻中恢复过来.到目前为止的编译器在某些情况下仍然完全不同.
在我看来,每个C++程序员都想要一个我可以编写"完美的面向对象的C++代码一次"的世界,然后它将适用于从1990年的诺基亚手机到最新的量子光学univac的所有东西.而最后我们得到一点点接近这样做,以证明C的价值++到更广阔的世界.在Java上射击我们的死亡之星,或者某些挑衅性的声明.
因此,我说 - 这个想法很好,但不是必需的.当然,如果你想撰写一份完整的提案,概述你将如何避免任何可能损害未来C++的问题 - 乌托邦,我会恳求你这样做.如果这样的功能可以在不损害预处理器,平台独立性,创建不可能复杂的错误或类似的情况下完成.然后你会比我更聪明 - 因为我无法看到目前的情况如何.
| 归档时间： |
|
| 查看次数： |
1863 次 |
| 最近记录： |