太大 [英] Too Big

查看:75
本文介绍了太大的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

几年前我换了C。我也一直在研究这个巨大而复杂的应用程序。它终于变得如此之大,以至于我有一个很难的时间将它全部保留在我脑海中,并且发现很难继续使用C / b
使用C因为它的发展。


我很喜欢C给我的性能,并且在中小型应用程序和DLL'上成功地使用了它。

的。但是对于这个巨大的项目来说,它使用起来很麻烦。我已经用其他语言重做了足够的

应用程序来进行压力测试,并且确定了

普通的旧VB6。它给了我大约一半的C性能,

面向对象和易用性。相比之下,C ++完全没有使用易用性(虽然它的速度很不错),并且Python比这个应用程序的C慢了15美元。


我以为我会在这里发帖,让你们知道。我可能会发布很多我写给Planet Source的支持模块,

供其他C程序员使用,所以我的写作时间那些

模块不会被完全浪费掉。感谢您在这个新闻组中给予我的所有帮助。


--Kamilche

解决方案

Kamilche写道:


几年前我改用C语言。我也一直在研究这个庞大而复杂的应用程序。它终于变得如此之大,以至于我很难将时间全部保留在脑海中,并且发现很难继续使用C进行开发。



.... snip ...


我认为这表示无法正确分区。 C $ / b $ b实际上具有非常好的功能来分离模块和限制

接口,它并不是特别擅长强制执行这样的。

一般来说你应该尝试应用七的规则,因为

是关于人类容易理解的极限。


IE一个函数应该处理不超过7项,包括

本地和参数。我相信它没有全局变量。


编译单元应该公开七种函数和类型。这个

经常会有点弯曲。


在C中,大量使用静态这个词是你的朋友。减去

.h文件到基本必需品,加上足够的评论

作为参考指南。


A编译单元可能不需要参考超过其他编译单元(除了标准库)。


你可以建立你的make文件考虑到这些想法。

切换到非结构化,不支持,不可移植和

专有语言(如VB)应该是倒退的重要一步。

唯一容易的是GUI用户界面。您可以使用它或类似的东西来调用结构良好的复杂应用程序并提供结果。


-

Chuck F(cb********@yahoo.com)(cb********@worldnet.att.net)

可用于咨询/临时嵌入式和系统。

< http://cbfalconer.home.att.net>使用worldnet地址!


kl ******* @ home .com (Kamilche)写道:

几年前我换了C。我也一直在研究这个庞大而复杂的应用程序。它终于变得如此之大,以至于我很难将时间全部保留在脑海中,并且发现很难继续使用C进行开发。




这通常(对我而言)是设计不佳的一个巨大迹象。你应该* * b $ b应该*永远不必保留你头脑中的任何程序:它只需要通过查看就可以看出它是b-b。我非常怀疑

只是改变你的表达媒介(编程

语言)将会有所改善。但是,嘿,祝你好运。


我的建议是,从您自己发现的模块开始

最常涉水,重新设计将使您<无需实际阅读

低级别详细信息即可轻松找到自己的方式。


-Micah


CBFalconer< cb ******** @ yahoo.com>在消息新闻中写道:< 3F *************** @ yahoo.com> ...

我认为这表明未能正确分区。 C
实际上具有非常好的功能来分离模块和限制接口,它只是不是特别擅长强制执行。




内存协助你使用VB(和C ++)很棒。我b / b
厌倦了必须记住每个数据的每个函数调用

类型...在VB中,我只输入变量名,然后是一个点,所有的

方法和变量会弹出一个方便的列表,等待我的选择。

''Intellisense''。


但它不止于此。有更好的封装可用于

OOP语言。我一直在'伪装''自己在C,但我最近

偶然发现了一个如此微妙且隐藏得很好的bug,它是一个

奇迹我发现了它。我知道这种情况发生在VB和其他语言中很好,但是对于C来说,一切都需要大约10倍的代码。那些

错误会更快地出现,当你的应用程序的核心在一个月内完成,而不是10个月。你知道吗?


也许我只是吮吸C.可能是。也许我是VB时代的孩子,

无法学习如何有效地使用其他语言。我不认为

。在互联网出现之前,我已经开始编程了,并用几种语言进行了编程 - COBOL,

HyperCard,VB,更多。


如果我有人编程可能会更好。也许它好吧b $ b看起来并不那么艰难。但我不是,并且希望不会成功

所以。这些具有intellisense的OOP语言弥补了一些

度。


我真的很喜欢Python的很多方面,不过它如何处理

全局变量很糟糕。我希望它在同一个球场,速度方面,

因为如果是的话,我会使用它,即使有它的怪癖。


- -Kamilche


I switched to C a couple years ago. I''ve also been working on this
huge, complex app. It''s finally gotten so big, that I''m having a hard
time keeping it all in my head, and find it difficult to continue to
use C for its development.

I have loved the performance C has given me, and have used it quite
successfully on small to medium sized apps, and DLL''s. But with this
huge project, it''s proving troublesome to use. I''ve redone enough of
the app in other languages to do stress testing, and have settled on
plain old VB6. It gives me about half the performance of C, with
object orientation and great ease-of-use. For comparison, C++ totally
lacks ease-of-use (though its speed is decent), and Python is slower
than C for this app by a factor of 15.

I just thought I''d post here, and let you guys know. I''ll probably
post a lot of the supporting modules I''ve written to Planet Source,
for use by other C programmers, just so my time in writing those
modules won''t have been totally wasted. Thanks for all the help you
have given me in this newsgroup.

--Kamilche

解决方案

Kamilche wrote:


I switched to C a couple years ago. I''ve also been working on this
huge, complex app. It''s finally gotten so big, that I''m having a hard
time keeping it all in my head, and find it difficult to continue to
use C for its development.


.... snip ...

I think that indicates a failure to partition correctly. C
actually has very good capabilities to separate modules and limit
interfaces, it just isn''t especially good at enforcing such.
Generally you should try to apply the rule of seven, because that
is about the limit of easy human comprehension.

I.E. a function should deal with no more than 7 items, including
locals and parameters. I trust it has no globals.

A compilation unit should expose seven functions and types. This
often gets bent a bit.

In C, heavy use of the word ''static'' is your friend. Pare down
the .h files to the bare essentials, plus enough commentary to
serve as a reference guide.

A compilation unit should probably not need to refer to more than
7 other compilation units (apart from the standard library).

You can build up your make files with these ideas in mind.
Switching to an unstructured, unsupported, non-portable and
proprietary language such as VB should be a major step backwards.
The only thing that makes easier is a GUI user interface. You can
always use it, or something like it, to call your well structured
complex application and deliver its results.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


kl*******@home.com (Kamilche) writes:

I switched to C a couple years ago. I''ve also been working on this
huge, complex app. It''s finally gotten so big, that I''m having a hard
time keeping it all in my head, and find it difficult to continue to
use C for its development.



This is usually (to me) a huge indication of poor design. You
should *never* have to keep much of any program in your head: it
should be plain-as-day just by looking at it. I''m very skeptical
that simply changing your medium of expression (programming
language) is going to improve that much. But hey, good luck.

My advice would be, starting with the modules you find yourself
wading through most frequently, a redesign which will enable you
to find your way comfortably without having to actually read the
low-level details.

-Micah


CBFalconer <cb********@yahoo.com> wrote in message news:<3F***************@yahoo.com>...

I think that indicates a failure to partition correctly. C
actually has very good capabilities to separate modules and limit
interfaces, it just isn''t especially good at enforcing such.



The memory assists you get working with VB (and C++) are awesome. I
grow weary of having to remember every function call for every data
type... in VB, I just type the variable name, then a dot, and all the
methods and variables pop up in a handy list, awaiting my selection.
''Intellisense''.

But it''s more than that. There''s better encapsulation available for
OOP languages. I''ve been ''faking it'' myself in C, but I recently
stumbled across a bug that was so subtle and well-hidden, it''s a
miracle I found it. I know that happens in VB and other languages as
well, but with C, everything is taking about 10x longer to code. Those
bugs pop up a lot sooner, when you have the core of your app done in a
month, as opposed to 10 months. Ya know?

Maybe I just suck at C. It could be. Maybe I''m a child of the VB age,
unable to learn how to use other languages effectively. I don''t think
so though. I cut my teeth on programming back before the Internet was
around, and have programmed in quite a few languages - COBOL,
HyperCard, VB, more.

It would probably be better if I had someone to program with. Maybe it
wouldn''t seem so tough then. But I don''t, and wishing won''t make it
so. These OOP languages with intellisense make up for it to some
degree.

I really like a lot of aspects about Python, though how it handles
global variables suck. I wish it was in the same ballpark, speed-wise,
because I''d use it if it was, even with its quirks.

--Kamilche


这篇关于太大的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆