C还是C ++？ （跨平台解决方案的偏好） [英] C or C++? (Preference for cross platform solutions)
问题描述
我知道语言选择更多是宗教选择，而不是我们许多人的逻辑决定。无论如何，这是我的关注
（希望不会被视为巨魔）:-)
我被告知C ++编译器不适用于所有平台
，对于许多平台，他们只支持C ++特性的基本子集
（就像继承/重载等...）。对于嵌入式平台而言，这尤其是真正的b $ b。因此我建议使用C.
我希望我的代码可以在各种各样的平台上使用，因为它可能是b / b $ b。但是我没有太多的平台经验，除了在windows和linux上编码，并且havnt曾尝试过任何编译器，而不是
GCC / MSVC / Borland。所以我真的不知道目前的状况。
我注意到许多（几乎所有？）开源项目都在C中，甚至是新的b $ b b b那些。是因为个人选择还是因为可移植性而做出的决定？
我是一个完全爱上这种语言的核心C ++开发人员并且
所有（相对）新功能，我很难做到非b / b
非面向对象编程并且不使用
编写好的代码
模板/例外等...我也做过C编码而且它不会对我来说很难，但是我不想转移到C，除非它是
非常值得推荐的选项。
在这种情况下你会选择什么？如果我确实选择了C ++，那么它会对我的代码的可用性产生多大的影响。
Sachin Garg [印度]
www.sachingarg.com | www.c10n.info
ps，我正在考虑另一种选择（这可能会被你们中的某些人扔掉
的窗口:-)。也许我可以用C ++编写所有我想要的方式来编码它，并在需要时（如果需要）将它移植到C.我希望在需要的时候
，编译器会有所改进。
另一个想法（而不是愿望;-)，有什么好处的吗？ /可靠
翻译编译器，它可以翻译我的模板和异常
重C ++代码到C而不会损害代码的运行时效率
多吗？ Google给了我这样的失望：
http://en.wikipedia.org/ wiki / Cfront :-)
I know that language choices are more of a religious choice, rather
than a logical decision for many of us. Anyway, here is my concern
(which will hopefully not be considered a troll) :-)
I have been told that C++ compilers are not available for all platforms
and for many platforms they only support a basic subset of C++ features
(like just inheritance/overloading etc...). That this is especially
true for embedded platforms. Thus I am advised to use C.
I want my code to be usable on as wide variety of platforms as
possible. But I dont have much platform experience beyond coding on
windows and linux, and havnt ever tried any compiler beyond
GCC/MSVC/Borland. So I dont really know the current state of affairs.
I notice that many (almost all?) open source projects are in C, even
the new ones. Is it just because of personal choice or is it a decision
made for portability?
I am a hard-core C++ developer totally in love with the language and
all of its (relatively) new features, it will be hard for me to do
non-object-oriented programming and write good code without using
templates/exceptions etc... I have done C coding too and it wont be
technically hard for me, but I don''t want to shift to C unless it is a
really highly recommended option.
What would you choose in such a situation? If I do choose C++, how much
will it really impact the usability of my code.
Sachin Garg [India]
www.sachingarg.com | www.c10n.info
ps, I am considering another option (which probably will get tossed out
of window by some of you :-). Maybe I can just code it all in C++ the
way I want and port it to C when (and if) need arises. I am hoping that
by the time need arises, the compilers would have improved.
Another thought (rather a wish ;-), are there any good/reliable
translating compilers, which can translate my template and exception
heavy C++ code to C without hurting code''s run-time efficiency too
much? Google gave me this disappointment:
http://en.wikipedia.org/wiki/Cfront :-)
推荐答案
Sachin Garg写道：
Sachin Garg wrote :
我注意到许多（几乎所有？）开源项目都在C中，甚至是新的。是仅仅因为个人选择还是为可移植性做出决定？
I notice that many (almost all?) open source projects are in C, even
the new ones. Is it just because of personal choice or is it a decision
made for portability?
GNU项目（GNU / Linux，各种库，...... ）主要是在C.
这可能是原因。
The GNU project (GNU/Linux, various libraries, ...) is mostly in C.
That may be the reason.
Sachin Garg写道：
Sachin Garg wrote:
我希望我的代码可以在各种各样的平台上使用。
为什么？你怎么能找到1个客户，并且只针对_their_平台，然后才能获得神圣的妄想？
但我没有太多的平台经验，除了编码
windows和linux，并且havnt曾经尝试过任何编译器，而不是GCC / MSVC / Borland。所以我真的不知道目前的情况。
检查任何流行的
C ++巨型库（如Boost或ACE）的Makefile系统（偏离主题）。
这里是ACE的清单：
config-WinCE.h config-psos-diab-mips.h
config-aix-4.1.xh config-psos-diab-ppc.h
config-aix-4.2.xh config-psos-diab.h
config-aix -4.3.xh config-psos-tm.h
config-aix-4.xh config-psosim-g ++。h
config-aix-5.xh config- qnx-neutrino.h
config-all.h config-qnx-rtp-62x.h
config-borland-common.h config-qnx-rtp-common。 h $>
config-chorus.h config-qnx-rtp-pre62x.h
config-cray.h config-qnx-rtp.h
config-cxx-common.h config-rtems.h
config-cygwin32.h config-sco-4.2-nothread.h
config-dgux-4.11-epc .h config-sco-5.0.0-fsu-pthread.h
config-d gux-4.x-ghs.h config-sco-5.0.0-mit-pthread.h
config-doxygen.h config-sco-5.0.0-nothread.h
config-freebsd.h config-sco-5.0.0.h
config-fsu-pthread.h config-sunos4-g ++。h
config- g ++ - common.h config-sunos4-lucid3.2.h
config-ghs-common.h config-sunos4-sun3.xh
config-hpux-10。 x-g ++。h config-sunos4-sun4.1.4.h
config-hpux-10.x-hpc ++。h config-sunos4-sun4.xh
config- hpux-10.xh config-sunos5.10.h
config-hpux-11.00.h config-sunos5.4-centerline-2.xh
config-icc- common.h config-sunos5.4-g ++。h
config-integritySCA.h config-sunos5.4-sunc ++ - 4.xh
config-irix5.2。 h config-sunos5.5.h
config-irix5.3-g ++。h config-sunos5.6.h
config-irix5.3-sgic ++。h config -sunos5.7.h
config-irix6.5.x-sgic ++。h config-sunos5.8.h
config-irix6.x-common.h conf ig-sunos5.9.h
config-irix6.x-g ++。h config-tandem-nsk-mips-v2.h
config-irix6.x-kcc .h config-tandem-nsk-mips-v3.h
config-irix6.x-sgic ++ - nothreads.h config-tandem.h
config-irix6.x -sgic ++。h config-tru64.h
config-kcc-common.h config-unixware-2.01-g ++。h
config-linux-common.h config- unixware-2.1.2-g ++。h
config-linux.h config-unixware-7.1.0.h
config-lite.h config-unixware-7.1。 0.udk.h
config-lynxos.h config-visualage.h
config-m88k.h config-vxworks5.xh
config -macosx-panther.h config-vxworks6.2.h
config-macosx-tiger.h config-win32-borland.h
config-macosx.h config- win32-common.h
config-macros.h config-win32-dmc.h
config-minimal.h config-win32-ghs.h
config-mit-pthread.h config-win32-interix.h
config-mklinux.h config-win32-mingw.h
config-mvs.h config-win32-msvc-6.h
config-netbsd.h config-win32 -msvc-7.h
config-openbsd.h config-win32-msvc-8.h
config-openvms.h config-win32-msvc.h
config-osf1-3.2.h config-win32-visualage.h
config-osf1-4.0.h config-win32.h
config- pharlap.h
config-posix.h
注意列表很长，因为操作系统后平台和编译器的版本很多
部分。配置后的第一个字是操作系统。你真的认识到那个名单上的每个操作系统都是b $ b吗？我肯定不会。
你有没有这些操作系统的工作版本，在你交付之前运行你的自动
测试？或者你是否正在考虑承诺支持他们的世界'/ b
OSF社区，当你所做的一切都是为了支持他们的时候
选择C而不是C ++？
我注意到许多（几乎所有？）开源项目都在C中，甚至是新的。这只是因为个人选择还是为便携性做出的决定？
不幸的是系统性和受欢迎的开源项目都在C中。那是因为C有更广泛的基础，其标准是更长的时间。在C ++有标准之前，有些项目已经开始了，而且有些项目确实是以不支持C ++的操作系统和嵌入式硬件为目标。
这仍然不意味着任何用C编写的代码都是自动移植的。当你依赖strdup（）之类的便利时，你很快就会获得
，这超出了
标准，并且必须处理无限的平台特定问题。 ACE和
Boost是思想领袖编写的完整且受欢迎的系统，可以依靠一大批dweebs来维护他们所有的构建系统。
我是一个热爱C ++的开发人员，非常喜欢这个语言和所有（相对）新功能，我很难做到非面向对象的编程和写好的代码而不使用
模板/异常等...我也做了C编码，它对我来说技术上很难，但我不想转向C，除非它是一个
非常值得推荐的选项。
I want my code to be usable on as wide variety of platforms as
possible.
Why? How about you find 1 customer, and target only _their_ platform, before
achieving delusions of godhood?
But I dont have much platform experience beyond coding on
windows and linux, and havnt ever tried any compiler beyond
GCC/MSVC/Borland. So I dont really know the current state of affairs.
Examine the Makefile systems (which are off-topic) for any of the popular
C++ mega libraries, such as Boost or ACE.
Here''s the checklist for ACE:
config-WinCE.h config-psos-diab-mips.h
config-aix-4.1.x.h config-psos-diab-ppc.h
config-aix-4.2.x.h config-psos-diab.h
config-aix-4.3.x.h config-psos-tm.h
config-aix-4.x.h config-psosim-g++.h
config-aix-5.x.h config-qnx-neutrino.h
config-all.h config-qnx-rtp-62x.h
config-borland-common.h config-qnx-rtp-common.h
config-chorus.h config-qnx-rtp-pre62x.h
config-cray.h config-qnx-rtp.h
config-cxx-common.h config-rtems.h
config-cygwin32.h config-sco-4.2-nothread.h
config-dgux-4.11-epc.h config-sco-5.0.0-fsu-pthread.h
config-dgux-4.x-ghs.h config-sco-5.0.0-mit-pthread.h
config-doxygen.h config-sco-5.0.0-nothread.h
config-freebsd.h config-sco-5.0.0.h
config-fsu-pthread.h config-sunos4-g++.h
config-g++-common.h config-sunos4-lucid3.2.h
config-ghs-common.h config-sunos4-sun3.x.h
config-hpux-10.x-g++.h config-sunos4-sun4.1.4.h
config-hpux-10.x-hpc++.h config-sunos4-sun4.x.h
config-hpux-10.x.h config-sunos5.10.h
config-hpux-11.00.h config-sunos5.4-centerline-2.x.h
config-icc-common.h config-sunos5.4-g++.h
config-integritySCA.h config-sunos5.4-sunc++-4.x.h
config-irix5.2.h config-sunos5.5.h
config-irix5.3-g++.h config-sunos5.6.h
config-irix5.3-sgic++.h config-sunos5.7.h
config-irix6.5.x-sgic++.h config-sunos5.8.h
config-irix6.x-common.h config-sunos5.9.h
config-irix6.x-g++.h config-tandem-nsk-mips-v2.h
config-irix6.x-kcc.h config-tandem-nsk-mips-v3.h
config-irix6.x-sgic++-nothreads.h config-tandem.h
config-irix6.x-sgic++.h config-tru64.h
config-kcc-common.h config-unixware-2.01-g++.h
config-linux-common.h config-unixware-2.1.2-g++.h
config-linux.h config-unixware-7.1.0.h
config-lite.h config-unixware-7.1.0.udk.h
config-lynxos.h config-visualage.h
config-m88k.h config-vxworks5.x.h
config-macosx-panther.h config-vxworks6.2.h
config-macosx-tiger.h config-win32-borland.h
config-macosx.h config-win32-common.h
config-macros.h config-win32-dmc.h
config-minimal.h config-win32-ghs.h
config-mit-pthread.h config-win32-interix.h
config-mklinux.h config-win32-mingw.h
config-mvs.h config-win32-msvc-6.h
config-netbsd.h config-win32-msvc-7.h
config-openbsd.h config-win32-msvc-8.h
config-openvms.h config-win32-msvc.h
config-osf1-3.2.h config-win32-visualage.h
config-osf1-4.0.h config-win32.h
config-pharlap.h
config-posix.h
Note the list is long due to versions of platform and compiler after the OS
part. The first word after config- is the OS. Do you actually recognize
every OS on that list? I sure don''t.
Do you have a working version of each of those OSs, to run your automated
tests on, before you deliver? Or were you thinking of promising the world''s
OSF community that you support them, when all you did to support them was
pick C over C++?
I notice that many (almost all?) open source projects are in C, even
the new ones. Is it just because of personal choice or is it a decision
made for portability?
The systemic and popular open source projects are unfortunately in C. That''s
because C has a wider base, and its Standard has been law for longer. Some
of those projects started before C++ had a standard, and some really do
target the OSs and embedded hardwares that don''t support C++.
That still doesn''t mean any code written in C is automatically portable. As
soon as you rely on a convenience like strdup(), you are beyond the
Standard, and must attend to endless platform specific issues. ACE and
Boost, being complete and popular systems written by thought-leaders, can
rely on an army of dweebs to maintain all their build systems.
I am a hard-core C++ developer totally in love with the language and
all of its (relatively) new features, it will be hard for me to do
non-object-oriented programming and write good code without using
templates/exceptions etc... I have done C coding too and it wont be
technically hard for me, but I don''t want to shift to C unless it is a
really highly recommended option.
对。因此，如果你使用C ++，你将增加你足够的概率
客户需要狂热的便携性。
-
Phlip
http://c2.com/cgi/wiki?ZeekLand < - 不是博客!!!
Right. So if you use C++, you will increase the odds that you _get_ enough
customers to need rabid portability.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
文章< 1146912504.924340.136920
@ u72g2000cwu.googlegroups.com> ， sc*****@gmail.com 说...
[...]
In article <1146912504.924340.136920
@u72g2000cwu.googlegroups.com>, sc*****@gmail.com says...
[ ... ]
在这种情况下你会选择什么？如果我确实选择C ++，它会对我的代码的可用性产生多大的影响。
这在很大程度上取决于您编写的代码类型。
如果您编写的代码主要适用于
真正很小的系统，C ++很可能是代码的问题。如果你正在编写的东西主要适合在相对有能力的系统上运行，那么C ++
可能不会成为问题 - 而且还有一个能力
系统不仅包括台式电脑，还包括PDA，
智能手机等。
至少对我来说，C ++是明确的选择，除非你确定使用它将确保你几乎在整个目标市场上锁定
。
另一个想法（而不是愿望;-)，是否有任何好的/可靠的翻译编译器，它可以将我的模板和异常重C ++代码转换为C而不会损害代码的运行时效率
多吗？ Google给了我这样的失望：
http://en.wikipedia.org/ wiki / Cfront ： - ）
What would you choose in such a situation? If I do choose C++, how much
will it really impact the usability of my code.
This depends heavily on the kind of code you''re writing.
If the code you''re writing is suitable primarily for
truly tiny systems, C++ is likely to be a problem for
that code. If you''re writing things that are suited
primarily for running on relatively capable systems, C++
probably won''t be a problem -- and anymore, a capable
system includes not only desktop computers, but PDAs,
smart phones, etc.
At least for me, C++ is the clear choice unless you''re
_quite_ certain that using it will lock you out of
virtually your entire target market.
Another thought (rather a wish ;-), are there any good/reliable
translating compilers, which can translate my template and exception
heavy C++ code to C without hurting code''s run-time efficiency too
much? Google gave me this disappointment:
http://en.wikipedia.org/wiki/Cfront :-)
我会访问 www.comeaucomputing.com 如果我是你。
-
后来，
杰瑞。
宇宙是自己想象的虚构。
I''d visit www.comeaucomputing.com if I were you.
--
Later,
Jerry.
The universe is a figment of its own imagination.
这篇关于C还是C ++？ （跨平台解决方案的偏好）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
