为何选择C？ [英] Why C?

问题描述

亲爱的朋友们：


在另一个帖子中，John Bode写道：

2.今天的大多数高级程序员都是从C开始感受到的
使用他们熟悉的东西更舒服。


在同一个帖子中，Robert Tisdale写道：

C仍然存在的唯一原因是
有大量的C程序员仍然对C ++感到不舒服。
现在没有理由期望他们学习C ++。
我们只是在等待他们退休或死亡。

Tisdale先生经常在这里被称为巨魔。


在我读完这句话之前，我从未理解为什么。


但他说的是Bode先生同样的事情。


用另一种语言，是的，但同样的事情。


顺便说一句，我今年54岁，我感到有点担心...


:-)


我太老了学习什么？


无论如何，我希望Tisdale先生不得不等待很长时间，不想现在就离开。


问题的关键在于我从未吞噬过面向炒作的对象
。我认为面向对象

编程在许多应用程序中都可以，这些应用程序可以通过分层模型很好地描述，但不是

*所有*应用程序。


肯定不是。


我看到Bjarne从更好的C和
$的想法开始b $ b陷入了复杂的海洋中，吞噬了他和他勇敢的合作者。


这是因为他的面向对象思维定势？


也许，也许不是。还有许多其他更简单的语言（所有面向对象的）在C ++之后已经开始使用
。当他开始时已经有了客观的C，

在Mac中以及后来的下一步操作系统的后续

咒语中幸存下来。

对象的创建/销毁是C ++创新的一部分。是的，但是：


自动创建和销毁对象可以通过良好的GC获得
。而且我指的是不是在C ++意义上的对象，而是在C意义上，即连续数量的

内存单元，它们具有相关的信息结构

用程序员定义的方式。


制作一个难以理解的编译器的问题，

生成的代码完全不可能使用算法

手动（即记住）是没有人知道

更准确的软件是如何工作的。


复杂性导致英国软件，即修补

没有任何理解，因为要修补它

必须了解其中的所有类层次结构。


C软件是透明与C ++相比。这个

固有的简单性是强大的力量和

C的巨大弱点。


因为我不是C挥动旗帜或者。

数据处理比这复杂得多。


C ++的积极方面是STL。


STL可以在C语言中以更简单的方式完成。模板

只是宏。唯一要做的就是在C中创建一个可以编程的宏

工具。


我正在考虑一个开放的编译器接口，你在哪里

不要在模板C ++中编写宏。但是在C.


编译器会加载DLL /共享对象并在那里执行

程序，这将产生（最终）文本为

插入当前位置。你在编译时编写C

在C中对它进行参数化。


一种递归语言。


I" 没有做到到C ++有很多原因，我认为b $ b的原因是有效的。遗憾的是，关于数据处理中的真正问题，这里有很少的讨论，而我们在我喜欢它的表面层面上保持

。或者我不喜欢它。


jacob

解决方案

" jacob navia" < JA *** @ jacob.remcomp.fr>在消息中写道

news：41 *********************** @ news.wanadoo.fr ...

我没有成功到C ++有很多原因，我认为有效的原因。遗憾的是，关于数据处理中的真正问题，我们很少讨论，而且我们仍然处于我喜欢它的表面层面。或者我不喜欢它。

数据处理和数据处理都没有。也不是数据处理中的真正问题

这里是热门话题。语言比较，倡导等也没有。

标准C语言就是这里的主题。


-Mike

jacob navia写道：

亲爱的朋友们：

在另一个帖子中，John Bode写道：

>今天的大多数高级程序员都是从C开始，感觉
>使用他们熟悉的东西更舒服。
在同一个帖子中，Robert Tisdale写道：

> C仍然存在的唯一原因是
>有大量的C程序员
>仍然对C ++不满意。
>现在没有理由期望他们学习C ++。
>我们只是在等他们退休或死去。

Tisdale先生在这里经常被称为巨魔。
我直到读完那句话才明白为什么。
但他说的是Bode先生的同样的事情。
用另一种语言，是的，但是同样的事情。

我只是相信他们实际上在说话关于他们自己。

顺便说一下，我今年54岁了，我感到有点担心...

:-)

我太老了学习什么？


你永远不会老去学习一些东西。尤其不是作为程序员

随着新技术的出现总是需要学习更多。


[snip]

关键问题是我从未吞噬过面向对象的炒作。我认为面向对象编程在许多应用程序中都是可以的，这些应用程序可以通过分层模型很好地描述，但不能用于* all *应用程序。


我完全同意。我已经开发了，或者至少参与了很多项目，其中C ++是首选语言，特别是当

进入可重用性时，组件，GUI开发和

互操作性（跨平台的网络）。当然所有

这些都是某种程度的C（以及许多其他

语言）的某种内置功能，但对于那些同时看过两个世界的人来说， C ++

在这些问题上表现优越。


另一方面，当我们为嵌入式设备开发低级库时，其他限制在适当的位置和C是理想的这些任务。我们甚至没有想过使用C ++。


[snip]

我看到Bjarne从更好的C和
的想法开始陷入复杂的海洋中，吞噬了他和他勇敢的合作者。


复杂性并不总是坏事。你可以用很多不同的方式做很多事情，但是每个人都可以根据需要自由使用

复杂度来完成他或她的任务。使用你需要的东西

然后单独留下。


[snip]

也许，也许不是。在C ++之后还有很多其他更简单的语言（所有面向对象的）已经开始了。


确切地说，这是一件好事。这是语言的演变和

技术。

对象的创建/销毁是C ++创新之一。是的，但是：


这只是冰山一角。还有很多其他的b / b $ b改进使C ++成为一个有价值的工具。例如，我们高度支持
从我们项目中的模板机制中获利，仅提及

其中一项改进。

自动创建和销毁可以使用良好的GC获得对象。我指的是不是在C ++意义上但在C意义上的对象，即连续数量的存储单元，它们以程序员定义的方式构建相关信息。


当应用程序员为他/她提供语言功能时，为什么应该担心不正常的内存

管理。

制作一个难以理解的编译器的问题，即生成完全不可能用手跟踪的算法的代码（即用心）是没有人知道
更准确的软件是如何工作的。


我不认为一个优秀的程序员需要知道编译器的工作原理

能编写好的软件。它当然有用，但不是一个

要求，除非你在较低级别进行系统编程。

复杂性导致britle软件，修补
没有任何理解，因为要修补它，你必须了解其中的所有类层次结构。


这对于C程序也是如此。要修补C程序，你需要了解程序的工作原理。对于一个只有层次结构的逻辑结构的

C ++程序也是如此。

分析你自己没有写过的C程序可能会很烦人/>
分析一个C ++程序，它包含它所包含的所有层次结构。

与C ++相比，C软件是透明的。这种内在的简单性是巨大的力量和C.的巨大弱点。


真实。阅读上述陈述。

因为我不是C波旗帜或者。数据处理比这复杂得多。

C ++的积极方面是STL。


当然，我很高兴有一个。

STL可以在C中以更简单的方式完成。模板
是只是宏。唯一要做的就是建立一个可编程的宏设施，用C.


实施可能更简单，但我怀疑这会更简单

使用。副作用和宏怎么样？这就是为什么一些C函数

被实现为宏而其他函数根本就不能这样做。

我正在考虑一个开放的编译器接口，你在哪里编写宏而不是在模板C ++中编写宏。但是在C.

编译器会加载DLL /共享对象并在那里执行
程序，这将产生（最终）插入当前位置的文本。你在编译时编写C语言用C语言进行参数化。

一种递归语言。


是的，为什么不把一些新的概念带入C.这个想法值得更好地讨论
。

我没有成功到C ++有很多原因，我认为有效的原因。遗憾的是，关于数据处理中的真正问题，我们很少讨论，而且我们仍然处于我喜欢它的表面层面。或者我不喜欢它。

你提到了很多好处，虽然我不同意所有

他们。就像你说的那样，我希望讨论的结果是高水平的b
，交换关于为什么要C到C的好主意。


谢谢


Steve

Steve Graegert写道：

STL可以在C中以更简单的方式完成。模板
只是宏。唯一要做的就是创建一个可以用C编程的宏工具。

实现起来可能更简单，但我怀疑这会更简单
使用。副作用和宏怎么样？这就是为什么有些C函数被实现为宏而其他函数根本就不能实现的原因。

我正在考虑一个开放的编译器接口，你在哪里编写宏而不是在模板C ++中编写宏。但是在C.

编译器会加载DLL /共享对象并在那里执行
程序，这将产生（最终）插入当前位置的文本。你在编译时编写C语言用C语言进行参数化。

一种递归语言。

是的，为什么不把一些新的概念带入C.这个想法值得更详细地讨论。

有两个接口可以调用你的编译时功能。


1：当编译器通知您语法

事件时，您会被调用，这是您感兴趣的事件。


您表达您的兴趣对于特定事件使用：


#pragma事件（FunctionStart，MyFnCall，templates.dll）


当函数定义启动时，编译器加载

templates.dll共享库中的MyFnCall函数

并运行它。该函数可以生成文本，对于

实例，记录这个特定函数被

生成字符串的事实：

" fprintf（stdout，输入函数fn \ n）;"


编译器编译此字符串，因为它在程序中编写了

那一点。


或者该函数不会产生任何东西，只记录一些

变量私有的dll这个函数的事实

调用并查看它的局部变量，如果有任何需要特殊初始化的托管对象，那么

。

或其他东西，无论如何。 br />

编译时函数和

之间的接口编译器是C字符串。


编译器运行时提供你有功能和

方法来访问参数列表，获取当前函数

名称，以及您可能需要的许多其他信息。你得到一个带有大部分相关信息的

环境数据块。


你通过获取函数指针表调用编译器
$ b加载时来自编译器的$ b。这将自动完成

。


2：


你打电话是因为你打电话给你编译

时间函数自己在源文本中：


#pragma compiletime（list，listgen，templates.dll）


然后你这样做：


list< int> * intList;

然后你的列表函数生成代码

" typedef struct tag_int_list {"

" struct tag_int_list * Next;"

" int data;

} INTLIST;"

" INTLIST * intList;"


你可以生成一系列库函数来处理

整数列表。


这不再由编译器以预先设定的方式自动生成，而是由用户编程为
。模板扩展在

a函数中完成，如下所示：


char * listgen（类型T）

{

char * typeName = GetTypeName（T）;

static hascalled;


输出（NULL）; //将缓冲区初始化为空。

if（GetLexicalLevel（）== GLOBAL&&

hasledled == 0）{

输出（" typedef struct tag_％s_list {" typeName）;

输出（" struct tag_％s_list * Next;"，typeName（T））;

if（Sizeof（T）< = sizeof（void *））{

输出（"％s data;"，typeName）;

}

else {//大于int的类型被分配。

输出（"％s * data;"，typeName）;

}

已经被称为= 1;

}

else if（GetLexicalLevel（）> = LOCAL）{

/ /这个模板实现决定

//所有类型必须先通过在全球范围内编写

//来知道：

// list<例如，int> ;.其他模式

//当然可以。

如果（已经被称为== 0）{

//没有更难以理解的模板
//错误。只是正常的消息。

CompilerError（" template list<> called uninitialized"）;

return"" ;;

}

//我们在局部变量声明中。

//输出已定义的名称

//类型

输出（"％sLIST"）;

}

else {

//我们不在全球范围内，而不是在

//本地声明中。可能是参数传递，

//或在另一个结构定义中...

//调用错误，发出错误

CompilerError（"对列表的错误调用<>模板"）;

}

返回输出（""）;

}


请注意，这个模板的编程没有任何需要

的繁琐的IF。需要的模板宏

当编译扩展模板时。


这种灵活性的缺点是（一如既往）这个

需要更多的努力。


我有一个这样的原型并且正在运行，但它需要是

充实，编译时间程序必须写，

必须改进加载/卸载协议，更多事件和

必须定义精确含义等。


但基本的想法是这样的。


jacob

Dear friends:

In another thread, John Bode wrote:

2. Most of today''s senior programmers started out with C and feel
more comfortable using something they know well.
And in that same thread, Robert Tisdale wrote:
The only reason that C still exists is that
there are a large number of C programmers
that still aren''t comfortable with C++.
There is no reason now to expect them to ever learn C++.
We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.

I never understood why until I read that sentence.

But he is saying the same thing that Mr Bode.

In another language, yes, but the same thing.

By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?

In any case I hope that Mr Tisdale will have to wait
a long time, do not feel like leaving right now.

The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.

Surely not.

I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.

Is that because of his object oriented mind set?

Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++. There was already objective C when he started,
that has survived well in the Mac and in the later
incantations of the Next step OS.

The creation/destruction of objects was one of
the innovations of C++. Yes, but:

Automatic creation and destruction of objects can be
obtained with a good GC. And I mean objects not in the
C++ sense but in the C sense, i.e. a contiguous amount of
memory cells, that have related information structured
in a programmer defined way.

The problem of making an incomprehensible compiler, that
generates code with algorithms completely impossible to
follow by hand (i.e. by mind) is that nobody knows
any more exactly how the software works.

Complexity leads to britle software, that is patched
without any understanding because to patch it you
have to understand all the class hierarchy in it.

C software is transparent compared with C++. This
inherent simplicity is the great strength and the
great weakness of C.

Because I am not a "C wave the flag" person either.
Data processing is much more complicated than that.

The positive side of C++ is the STL.

The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.

I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.

I "didn''t make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

jacob

解决方案

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

I "didn''t make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

Neither "data-processing" nor "the real issues in data-processing"
are topical here. Nor are language comparisons, advocacy, etc.
The standard C language is the topic here.

-Mike

jacob navia wrote:

Dear friends:

In another thread, John Bode wrote:

> 2. Most of today''s senior programmers started out with C and feel
> more comfortable using something they know well.
And in that same thread, Robert Tisdale wrote:

> The only reason that C still exists is that
> there are a large number of C programmers
> that still aren''t comfortable with C++.
> There is no reason now to expect them to ever learn C++.
> We are just waiting for them to retire or die.

Mr Tisdale has often been called a troll here.
I never understood why until I read that sentence.
But he is saying the same thing that Mr Bode.
In another language, yes, but the same thing.

I merely believe they were actually talking about themselves.
By the way, I am 54, and I feel somehow concerned...

:-)

Am I too old to learn anything?
You''re never to old to learn something. Especially not as a programmer
who always needs to learn more as new technologies emerge.

[snip]
The crux of the matter is that I never swallowed the
object oriented hype. I think that "object oriented"
programming is OK in a number of applications that
are well described by hierarchical models, but not
for *all* applications.
I totally agree to that. I''ve developed, or at least been involved in a
lot of projects, where C++ was the language of choice, especially when
in comes to reusability, in terms of components, GUI development and
interoperability (in terms of networking across platforms). Sure all
these are some kind of built-in features of C (and a lot of other
languages) to some degree, but for those who have seen both worlds, C++
is superior on these issues.

On the other hand, when we were devloping low level libraries for
embedded devices, other constraints where in place and C was ideal for
these tasks. We didn''t even think about using C++.

[snip]
I saw Bjarne start with the idea of a better C and
get stuck in an ocean of complexity, that swallowed
him and his intrepid collaborators alive.
Complexity is not always a bad thing. You can do a lot of things in a
lot of different ways, but everybody is free to use as much of the
complexity as needed to accomplish his or her task. Use what you need
and leave the rest alone.

[snip]
Maybe, maybe not. There are many other simpler
languages (all object oriented) that have started
after C++.
Exactly, and it is a good thing. It''s the evolution of languages and
technologies.
The creation/destruction of objects was one of
the innovations of C++. Yes, but:
This is only the tip of the ice berg. There are lots of other
improvments that made C++ a valuable tool. For example, we highly
profited from the template mechanism in our projects, just to mention
one of the improvements.
Automatic creation and destruction of objects can be
obtained with a good GC. And I mean objects not in the
C++ sense but in the C sense, i.e. a contiguous amount of
memory cells, that have related information structured
in a programmer defined way.
Why should an application programmer worry about the undelying memory
management when there is a language feature that does it for him/her.
The problem of making an incomprehensible compiler, that
generates code with algorithms completely impossible to
follow by hand (i.e. by mind) is that nobody knows
any more exactly how the software works.
I don''t think a good programmeer needs to know how the compiler works to
be able to write good software. It''s helpful, of course, but not a
requirement, unless you are doing systems programming at a lower level.
Complexity leads to britle software, that is patched
without any understanding because to patch it you
have to understand all the class hierarchy in it.
This is partially true, also for C programs. To patch a C program you
should have a knowledge on how the program works. The same is true for a
C++ program that simply has it''s logic structured hierarchically.
Analyzing a C program you have not written yourself can be as annoying
as analyzing a C++ program with all the hierarchy it embodies.
C software is transparent compared with C++. This
inherent simplicity is the great strength and the
great weakness of C.
True. Read statements above.
Because I am not a "C wave the flag" person either.
Data processing is much more complicated than that.

The positive side of C++ is the STL.
Absolutely, and I''m glad there is one.
The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.
It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That''s why some C functions
are implemented as macros while other simply can''t, just because of that.
I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.
Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.
I "didn''t make it" to C++ for many reasons, reasons that I
consider valid. It is a pity there is so little disucssion
here about the real issues in data-processing and we stay
at the superficial level of "I like it" or "I do not like it".

You mentioned a lot of good points, although I do not agree to all of
them. Just as you said, I hope the discussion is being held at a high
level exchanging good ideas on why to C or not to C.

Thanks

Steve

Steve Graegert wrote:

The STL can be done in a simpler way in C. Templates
are just macros. The only thing to do is to make a macro
facility that can be programmed, in C.

It may be simpler to implement, but I doubt that this would be simpler
to use. What about side effects and macros? That''s why some C functions
are implemented as macros while other simply can''t, just because of that.

I am thinking about an open compiler interface, where you
write your macros not in "template C++" but in C.

The compiler would load a DLL/shared object and execute the
program in there, that will produce (eventually) text to be
inserted at the current position. You write C at compile time
parametizing it in C.

A recursive language.

Yes, why not bring some new concepts into C. This idea is worth being
discussed in more detail.

There are two interfaces to call your compile time functions.

1: You get called when the compiler informs you of a syntax
event, an event that you are interested in.

You express your interest for a specific event by using:

#pragma event(FunctionStart,MyFnCall,templates.dll)

When a function definition starts, the compiler loads
the MyFnCall function from the templates.dll shared library
and runs it. The function can produce text to, for
instance, record the fact that this particular function was called by
generating a string:
"fprintf(stdout,"entering function fn\n");"

The compiler compiles this string as it was written
in the program at that point.

Or the function will not produce anything but record in some
variables private to the dll the fact that this function is
called and look in the local variables of it if there is
any managed object that needs special initialization.

Or other stuff, whatever.

The interface between the compile time function and
the compiler are C strings.

The compiler run time provides you with functions and
methods to access the argument list, get the current function
name, and many other info that you may need. You get an
environment data block with most of the relevant info.

You call in the compiler by obtaining a function pointer table
from the compiler at load time. This will be done
automatically.

2:

You get called because you write a call to your compile
time function yourself in the source text:

#pragma compiletime(list,listgen, templates.dll)

Then you do:

list<int> *intList;
Then your list function generates code
"typedef struct tag_int_list {"
" struct tag_int_list*Next;"
" int data;"
"} INTLIST;"
" INTLIST *intList;"

And you can generate a series of library functions to handle
integer lists.

This is no longer generated automatically in a
preconceived way by the compiler but is programmed
by the user. The template expansion is done in
a function like this:

char *listgen(Type T)
{
char *typeName = GetTypeName(T);
static alreadycalled;

Output(NULL); // Initializes the buffer to empty.
if (GetLexicalLevel() == GLOBAL &&
alreadycalled == 0) {
Output("typedef struct tag_%s_list {",typeName);
Output("struct tag_%s_list *Next;",typeName(T));
if (Sizeof(T) <= sizeof(void *)) {
Output("%s data;",typeName);
}
else { // types bigger than ints are allocated.
Output("%s *data;",typeName);
}
alreadycalled = 1;
}
else if (GetLexicalLevel() >= LOCAL) {
// This template implementation decides that
// all types must be previously known by writing
// at the global level:
// list<int>, for instance. Other schemas
// are possible of course.
if (alreadycalled == 0) {
// No more incomprehensible template
// errors. Just normal messages.
CompilerError("template list<> called uninitialized");
return "";
}
// we are in a local variable declaration.
// Output just the name of the already defined
// type
Output("%sLIST");
}
else {
// We are not at the global level, and not in a
// local declaration. Probably parameter passing,
// or within another structure definition...
// Bad call, emit an error
CompilerError("Bad call to list<> template");
}
return Output("");
}

Note that this templates are programmed without any need
for the cumbersome "IF" template macros that are needed
when a compile expands the template.

The downside of this flexibility is (as always) that this
needs a bit of more effort.

I have a prototype of this up and running but it needs to be
fleshed out, the compile time procedures must be written,
the load/unload protocol must be refined, more events and
precise meanings must be defined, etc.

But the basic idea is this.

jacob

这篇关于为何选择C？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！