任何不寻常的C ++实现？ [英] Any unusual C++ implementations?
问题描述
过去一年左右我一直在编写大部分C代码（而不是
C ++），而且在编写C代码时我总是把它完全编写便携式，允许
9位字节，允许在整数类型内填充，允许null
指针，其位表示不是全为零，允许任何一个<三个数字系统中的
，允许ASCII以外的字符集
（例如''A''不一定== 65）。
我正在研究的当前项目正在发展很多但是......
我觉得我被推到了切入C ++的边缘。我可以做的第一件事就是命名空间，但是一旦我获得批准，我就会使用类来完全重构代码。 br />
无论如何，我想问一下C ++是否有像C一样广泛的各种
实现？我的意思是你会找到一个C实现，它具有
9位字节或64位字节，或者一个填充整数
类型的实现。但是C ++怎么样？有多少？
我问的原因是，如果C ++没有太多变化，那么我可以转而使我的代码更少灵活。例如，我可能会假设
表示unsigned long没有填充，然后继续使用它来一次操作sizeof（unsigned long）字节。$ br / b >
我正在编写的程序主要由算法
组成，可以在C中完全移植，但现在我已经决定制作
一个接口（包括一个GUI），它会变得更加复杂。我会在心跳中切换到C ++，但我想保持尽可能好的便携性（当然我会失去一大块
如果我转向C ++，可移植性。）
你认为将算法
代码保留为C是不可能的，然后编写接口代码为C ++ ......？这样我就可以用算法来制作命令行程序了。
我不会做的一件事就是假设8位字节假设32位或64位系统，或者
，因为在十年内我们可以使用具有16位字节的
系统。
-
$ b $bTomásóhéilidhe
I''ve been writing mostly C code for the last year or so (rather than
C++), and in writing C code I always make it fully portable, allowing for
9-Bit bytes, allowing for padding within integer types, allowing for null
pointers whose bit representation isn''t all zeroes, allowing for either
of the three number systems, allowing for character sets other than ASCII
(e.g. ''A'' isn''t necessarily == 65).
The current project I''m working on is evolving quite a bit though...
and I think I''m being pushed to the edge to switch to C++. First thing I
could do with is namespaces, but also as soon as I get the go-ahead to
use classes I''ll be restructuring the code altogether.
Anyway, I''d like to ask if C++ has as wide a variety of
implementations as does C? I mean you''ll find a C implementation that has
9-Bit bytes, or 64-Bit bytes, or one that has padding in its integer
types. But what about C++? Is there variety?
The reason I ask is that if there isn''t much variety in C++, then I
might switch to making my code less flexible. For instance I might assume
that an unsigned long has no padding and then go on to use it to
manipulate sizeof(unsigned long) bytes at a time.
The program I''m currently writing is mostly comprised of algorithms
that can be coded fully-portably in C, but now that I''ve decided to make
an interface for it (including a GUI), it''s getting a bit more
complicated. I''d switch to C++ in a heartbeat but I want to maintain as
great portability as I can (and of course I''ll lose a good chunk of
portability if I move to C++).
Would it be out of the question do you think to leave the algorithmic
code as C, and then write the interface code as C++... ? That way I could
still make commandline programs out of the algorithms.
One thing I won''t be doing ever though is assuming 8-Bit bytes or
assuming a 32 or 64-Bit system, because in ten years we could be using
systems with 16-Bit bytes.
--
Tomás ó héilidhe
推荐答案
" Tom ??????????? ???????????????????????????????????? ?????????????????????????????????????????????????? "写道：
[你使用的不同于你在标题中声明的字符集吗？]
"Tom?????????????????????????????????????????????? ?????????????????????????????????????????????????? " wrote:
[Are you using an different character set than you declare in your headers?]
>
无论如何，我想问一下C ++是否有与C一样广泛的各种
实现？我的意思是你会找到一个C实现，
有9位字节，或64位字节，或者有一个填充整数
类型的实现。但是C ++怎么样？有多少？
>
Anyway, I''d like to ask if C++ has as wide a variety of
implementations as does C? I mean you''ll find a C implementation that
has 9-Bit bytes, or 64-Bit bytes, or one that has padding in its integer
types. But what about C++? Is there variety?
上面几乎没有，如果与语言或编译器有关。
它们是机器的功能，不是语言。
所以你的问题应该是那些具有
这些特性的机器的C ++编译器吗？这可能超出了这个群体的范围。
一个更好的问题是你打算将你的代码移植到这样一台机器上吗？只有你可以回答这个问题。
The above have little, if anything to do with the language or compiler.
They are features of the machine, not the language.
So your question should be are there C++ compilers for machines with
these characteristics? Which is probably beyond the scope of this group.
A better question is do you intend your code to be portable to such a
machine? Only you can answer that.
我问的原因是，如果C ++没有太多变化，那么我可以用b $ b切换到使我的代码不那么灵活。例如，我可能会认为
假设unsigned long没有填充，然后继续用它来
一次操作sizeof（无符号长整数）字节。
The reason I ask is that if there isn''t much variety in C++, then I
might switch to making my code less flexible. For instance I might
assume that an unsigned long has no padding and then go on to use it to
manipulate sizeof(unsigned long) bytes at a time.
一个公平的假设，如果你愿意，你可以随时测试。
A fair assumption, which you can always test for if you wish.
我目前的程序写作主要由算法
组成，可以在C中完全移植，但现在我已经决定为它设置一个接口（包括一个GUI） ），它会变得更加复杂。我会在心跳中切换到C ++，但我想保持尽可能好的便携性（当然我会失去一大块
如果我转向C ++，可移植性。）
The program I''m currently writing is mostly comprised of algorithms
that can be coded fully-portably in C, but now that I''ve decided to make
an interface for it (including a GUI), it''s getting a bit more
complicated. I''d switch to C++ in a heartbeat but I want to maintain as
great portability as I can (and of course I''ll lose a good chunk of
portability if I move to C++).
添加GUI会限制你的可能目标，而不是使用C ++的
。 br />
The addition of a GUI would restrict your possible targets more than the
use of C++.
你认为将算法
代码保留为C，然后将接口代码编写为C ++是不可能的。 ..？这样我就可以从算法中生成命令行程序。
Would it be out of the question do you think to leave the algorithmic
code as C, and then write the interface code as C++... ? That way I
could still make commandline programs out of the algorithms.
如果例程工作为C，哪一个最适合你并且你不能通过更改为C ++来提高代码的效率或清晰度，留下
。请记住，如果您更改为C ++，则必须提供
externC包装器，如果你想从C调用例程（或代码
用不同的C ++编译器构建）。
Which ever works best for you, if the routines works as C and you can''t
improve the efficiency or clarity of the code by changing to C++, leave
it be. Do remember that if you change to C++, you will have to provide
extern "C" wrappers if you wish to call the routines from C (or code
built with different C++ compilers).
我赢了一件事''假设32位或64位系统假设是8位字节或
，因为在十年内我们可以使用带有16位的
系统字节。
One thing I won''t be doing ever though is assuming 8-Bit bytes or
assuming a 32 or 64-Bit system, because in ten years we could be using
systems with 16-Bit bytes.
许多DSP程序员已经多年了！
-
Ian Collins 。
Many DSP programmers have been for years!
--
Ian Collins.
" Tom ??????????????????????????? ??????????????? ?????????????????????????????????????????????????? "写道：
"Tom?????????????????????????????????????????????? ?????????????????????????????????????????????????? " wrote:
例如我可能
假设unsigned long没有填充然后继续用它来
一次操作sizeof（无符号长整数）字节。
For instance I might
assume that an unsigned long has no padding and then go on to use it to
manipulate sizeof(unsigned long) bytes at a time.
这对我来说听起来像黑客优化，这在很多情况下是无效的。
无用。你究竟会如何一次操纵sizeof（unsigned long）字节
？注意举个例子？
That sounds like hacker optimization to me, which is in many cases
useless. Exactly how would you "manipulate sizeof(unsigned long) bytes
at a time"? Care to give an example?
Ian Collins< ia ****** @ hotmail.comwrote in comp.lang.c ++：
Ian Collins <ia******@hotmail.comwrote in comp.lang.c++:
" Tom ???????????????????????? ???????? ???????????????????????????????????????????????????????????????????????????????????? ????????"写道：
[你使用的是不同于你在
标题中声明的字符集吗？]
"Tom?????????????????????????????????????????????? ?????????????????????
?????????????????????????????" wrote:
[Are you using an different character set than you declare in your
headers?]
之前有人试图帮我解决这个问题，但我没有走得太远。
我的标题说UTF-8，但我不太确定我是哪个字符集'
使用。我最近一直在从新闻阅读器跳到新闻阅读器。我使用的最后一个
是Pan。在Linux下，但这是垃圾，所以现在我在Windows下使用XNews
，我认为到目前为止这是很好的。但是，我无法在XNews下找到任何选项
来设置字符集。我不认为任何人有任何想法我正在使用的字符集。 。 ？因为如果我不能让我的新闻阅读器以UTF-8发布，我会更改我的标题
来指定它。
Someone tried to help me out with this before but I didn''t get far.
My headers say UTF-8, but I''m not quite sure which character set I''m
using. I''ve been jumping from newsreader to newsreader lately. Last one I
used was "Pan" under Linux, but that was crap so now I''m using "XNews"
under Windows, which I think is great so far. I can''t find any option
under XNews however to set the character set. I don''t suppose anyone has
any idea which character set I''m using. . ? Because I''ll change my header
to specify it if I can''t actually get my newsreader to post in UTF-8.
以上几乎没有，如果与语言或
编译器有关。
它们是机器的功能，而不是语言。
The above have little, if anything to do with the language or
compiler.
They are features of the machine, not the language.
我意识到这一点。
I realise that.
所以你的问题应该是有C ++编译器吗？具有这些特征的机器是什么？这可能超出了这个
组的范围。
So your question should be are there C++ compilers for machines with
these characteristics? Which is probably beyond the scope of this
group.
我认为你的限制太多了。我不是要求WIN_CLASS_REG_INFO_EX的
定义。在Win32下。
实际上，如果你*真的*想要限制，你应该告诉
人停止发布代码，因为任何关于实际的讨论
编程应该正确地进入comp.programming。*层次结构，并且
comp.lang。*层次结构应保留用于讨论语言
本身。 （当我试图提出comp.lang.c ++时，我遇到了这个问题。十字架
平台）。
I think you''re being a bit too restrictive. I''m not asking for the
definition of "WIN_CLASS_REG_INFO_EX" under Win32.
Actually, if you *really* want to be restrictive, you should tell
people to stop posting code, because any discussion about actual
programming should rightfully go in the comp.programming.* hierarchy, and
the comp.lang.* hierarchy should be reserved for talk about the language
itself. (I had this issue when trying to put forward comp.lang.c++.cross-
platform).
A更好的问题是你打算将你的代码移植到这样一台机器上吗？只有你能回答这个问题。
A better question is do you intend your code to be portable to such a
machine? Only you can answer that.
我希望我的代码可以在这个星球上每台机器上运行，这台机器上有一个
键盘和一个显示器。
I''d like my code to run on every machine on the planet that has a
keyboard and a monitor.
>我问的原因是，如果C ++没有太多变化，那么
我可能会转而使我的代码不那么灵活。例如，我可能会假设unsigned long没有填充，然后继续使用
一次操作sizeof（unsigned long）字节。
> The reason I ask is that if there isn''t much variety in C++, then
I
might switch to making my code less flexible. For instance I might
assume that an unsigned long has no padding and then go on to use it
to manipulate sizeof(unsigned long) bytes at a time.
公平的假设，如果您愿意，您可以随时测试。
A fair assumption, which you can always test for if you wish.
编写两个实现需要做更多的工作，还有更多的工作
仍然要编写代码来检查是否可以使用实现A 。
It would take more work to write two implementations, and more work
still to write the code to check whether implementation A can be used.
>我目前正在编写的程序主要由
算法组成，可以在C中完全移植，但现在我已经决定为它创建一个接口（包括GUI），它变得更复杂了。我会在心跳中切换到C ++，但我想保持尽可能好的可移植性（当然，如果我转向C ++，我将失去很好的可移植性）。
> The program I''m currently writing is mostly comprised of
algorithms
that can be coded fully-portably in C, but now that I''ve decided to
make an interface for it (including a GUI), it''s getting a bit more
complicated. I''d switch to C++ in a heartbeat but I want to maintain
as great portability as I can (and of course I''ll lose a good chunk
of portability if I move to C++).
添加GUI会限制你的可能目标超过使用C ++的
。
The addition of a GUI would restrict your possible targets more than
the use of C++.
我意识到这一点。我会将程序的核心与
接口分开，这样我也可以将它编译成一个控制台应用程序并且
让它运行在任何一个屏幕和键盘。
I realise that. I''ll keep the heart of the program separate from the
interface, such that I can also compile it to a console application and
have it run on anything with a screen and a keyboard.
哪一个最适合你，如果例程工作为C而你
可以'通过更改为
C ++来提高代码的效率或清晰度，保持原样。
Which ever works best for you, if the routines works as C and you
can''t improve the efficiency or clarity of the code by changing to
C++, leave it be.
我只是想知道是否有点极端，或者单调乏味，
维持一个同时具有C和C的项目中的C ++？
I''m just wondering if it would be a bit extreme, or tedious, to
maintain a project which has both C and C++ in it?
>我不会做的一件事是假设8位字节或假设32位或64位系统，因为在十年内我们可以使用16位字节的系统。
> One thing I won''t be doing ever though is assuming 8-Bit bytes or
assuming a 32 or 64-Bit system, because in ten years we could be
using systems with 16-Bit bytes.
许多DSP程序员已经多年了！
Many DSP programmers have been for years!
啊是的，因为一个9位字节的系统可能不会那么高效地发送八位字节的以太网电缆。尽管这不是不可能的。
使用unsigned char和按位运算符，世界就是你的牡蛎。
实际上它只是发生在我在
首先要问的是什么问题：
是否每台机器都有一个C ++编译器，它有一个键盘和一个
显示器？如果没有，那么我们谈论的机器比例是多少？
我会从我在Antartica的朋友那里得到一个电话，告诉我他不能获得
获得一个C ++他的台式电脑的编译器？
-
$ b $bTomásóhéilidhe
Ah yes, because a 9-Bit-byte system probably wouldn''t so efficient at
sending octets down an ethernet cable. Still though it''s not impossible.
With unsigned char''s and bitwise operators, the world is your oyster.
Actually it just occurred to me what question I should have asked in the
first place:
Is there a C++ compiler for every machine that has a keyboard and a
monitor? If not, then what kind of proportion of machines are we talking?
Will I get a phonecall from my friend in Antartica telling me he can''t
get a C++ compiler for his desktop computer?
--
Tomás ó héilidhe
这篇关于任何不寻常的C ++实现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
