包裹思想 [英] Wrap thoughts

问题描述

嗯，我已经达到了一个里程碑：在这里我有一个功能齐全的

应用程序，如果没有一些初步的东西，我就无法使用。如果我要给b $ b分配动态内存，我需要知道文件长度，或者进行一些猜测例程的
。还有其他的事情。现在很明显，

必须编写一些非便携式代码才能使其有用。


怎么办？


目前，我倾向于将''wrap''代码（嘿......）包装在一个shell

脚本中，它可以方便地提供所有参数。当然，这样的脚本可以为任何操作系统编写，这样就可以保留代码

。另一种方法是使用

GUI例程（我喜欢GTK +），并将所有非可移植代码放在该级别。


最后一种选择是给系统调用代码加注，以便提供

添加的功能，或者我认为。


我想重点是保持便携式代码分离和完整。它很容易在命令行中为脚本提供所有必要的参数

来解决，这样，如果<本身可以手动使用br />
所需信息即将到来。此外，

代码本身的任何附加功能都可以像CL参数一样处理，并且相应地修改了包装器

脚本。

我想我的问题是：你们做了什么*做了这个，并给出了

期权，最常见的优惠顺序是什么？

感谢您阅读！

-

电子邮件是olypen dot com的wtallman

解决方案

"名称" <我们** @ host.domain>写了

好吧，我已经达到了一个里程碑：在这里，我有一个功能齐全的应用程序，如果没有一些初步的东西我就无法使用。如果我要分配动态内存，我需要知道文件长度，或者接受一些
类型的猜测程序。还有其他的事情。现在很明显，必须编写一些非便携式代码才能使其有用。

怎么办？

通常情况下你可以使用足够便携。码。如果你想知道一个文件的长度

，打开它，fseek（）到最后，ftell（）的位置，并添加一些

百字节为运气。在严格的ANSI术语中，这可能会失败，但实际上很可能是你的代码不可能在病态的

平台上运行。

2004-08-28，Malcolm< ma ***** @ 55bank.freeserve.co.uk>写道：

" name" <我们** @ host.domain>写了

好吧，我已经达到了一个里程碑：在这里，我有一个功能齐全的应用程序，如果没有一些初步的东西我就无法使用。如果我要分配动态内存，我需要知道文件长度，或者进行一些

sort

的例程。还有其他的事情。现在很明显，必须编写一些非便携式代码才能使其有用。

怎么办？

通常你可以使用 ;足够便携码。如果你想知道文件的长度，打开它，fseek（）到最后，ftell（）的位置，并添加一些
百字节的运气。在严格的ANSI术语中，这可能会失败，但实际上，您的代码不太可能必须在病态平台上运行。

啊哈。我曾在其他地方聚集过，这实际上并没有奏效，但现在不能确切地记住原因。我确实记得它不被认为是可移植的（我想是......）但是你提出了一个有趣而且看似实用的方法。

有很好的理论依据当然，一般的足够好

方法;问题可能在于确定在任何特定情况下结果是什么。在我看来，真正的问题是技能和程序员的知识。但是它并不总是如此！


通常情况下，我甚至不会提出这个问题，并且可能不会在这里首先发布

。我通常可以通过一些努力获得一些工作，但这不是这个特定项目的意义所在。我想要了解一般的编程方式，从

C程序员的角度来看。所以这些问题就变得相关了。


所以我会接受你的建议并看看我能做些什么。我还要

对足够好

方法的一般意见感兴趣。


感谢您的回复！

-

电子邮件是wtlyman at olypen dot com

2004年8月28日星期六，Malcolm写道：

" name" <我们** @ host.domain>写了

好吧，我已经达到了一个里程碑：这里有一个功能齐全的应用程序，如果没有一些初步的东西，我就无法使用。如果我要分配动态内存，我需要知道文件长度，或者进行一些猜测例程。还有其他的事情。现在很明显，必须编写一些非便携式代码才能使其有用。

怎么办？

通常情况下你可以使用足够便携。码。如果你想知道文件的长度，打开它，fseek（）到最后，ftell（）的位置，并添加一些
百字节的运气。在严格的ANSI术语中，这可能会失败，但实际上，您的代码不太可能必须在病态平台上运行。

确实如此 - 有时你真的需要写非便携式的b $ b或足够便携。码。但是为了避免OP得到错误的想法：

他的程序执行/不执行实现定义的行为。

除非他再次更改了规范，否则需要O （k）内存

k是在命令行输入的数字。这就是

你可以在不知道文件长度的情况下得到的东西。


今晚我会写这个程序，也许会发布一些更多想法

然后。与此同时，我鼓励OP检查''usenetify''，

''usenetify2''和Leor Zolman''''pf''，链接到所有这些都可以<在Google网上论坛存档中找到了
;搜索usenetify wrapping，

我想。所有这三个程序都是以便携性写的，并且考虑到了b $ b，他们所做的基本上与OP正在尝试做的事情相同，尽管有更多的铃声和口哨声。 />

-Arthur

Well, I''ve reached a milestone: Here I have an adequately functional
application I can''t use without some preliminary stuff. If I''m going to
assign dynamic memory, I need to know the file length, or undergo some sort
of guess routine. And other things as well. It''s now immediately evident
that some non-portable code must be written to make this useful.

What to do?

At the moment, I''m inclined to wrap the ''wrap'' code (heh...) in a shell
script which can supply all the parameters handily. Such a script can be
written for any operating system, of course, and that would leave the code
portable in its own right. Another approach would be to do the same with a
GUI routine (I like GTK+), and put all the non-portable code in at that level.

The last choice would be to lard the code with system calls to supply the
added functionality, or so I think.

I guess the point is to keep the portable code separate and intact. It''s
easy to provide all the necessary arguments at command line for the script
to address, and that way, the app itself could be used manually if the
required information were at hand. Also, any added functionality to the
code itself could be handled the same way, as CL arguments, and the wrapper
script modified accordingly.

I guess my question here is: What *do* you guys do about this, and given
options, what order of preference thereof is most common?

Thanks for reading!
--
Email is wtallman at olypen dot com

解决方案

"name" <us**@host.domain> wrote

Well, I''ve reached a milestone: Here I have an adequately functional
application I can''t use without some preliminary stuff. If I''m going to
assign dynamic memory, I need to know the file length, or undergo some sort of guess routine. And other things as well. It''s now immediately evident
that some non-portable code must be written to make this useful.

What to do?

Normally you can use "portable enough" code. If you want to know the length
of a file, open it, fseek() to the end, ftell() the location, and add a few
hundred bytes for luck. In strict ANSI terms this can fail, but practically
it is unlikely that your code will ever have to run on a pathological
platform.

On 2004-08-28, Malcolm <ma*****@55bank.freeserve.co.uk> wrote:

"name" <us**@host.domain> wrote

Well, I''ve reached a milestone: Here I have an adequately functional
application I can''t use without some preliminary stuff. If I''m going to
assign dynamic memory, I need to know the file length, or undergo some

sort

of guess routine. And other things as well. It''s now immediately evident
that some non-portable code must be written to make this useful.

What to do?

Normally you can use "portable enough" code. If you want to know the length
of a file, open it, fseek() to the end, ftell() the location, and add a few
hundred bytes for luck. In strict ANSI terms this can fail, but practically
it is unlikely that your code will ever have to run on a pathological
platform.

Aha. I had gathered elsewhere that this actually didn''t work, but can''t now
remember exactly why. I do recall it wasn''t considered portably (I
think...), but you raise an interesting and apparently practical approach.
There is excellent theoretical justification for the general "good enough"
approach, of course; the problem might be in identifying what that turns out
to be in any particular case. Seems to me the real issue is the skill and
knowledge of the programmer. But is it not always thus!

Normally, I wouldn''t even raise this issue, and probably would not have
posted here in the first place. I can generally get something to work with
a bit of effort, but that''s not what this particular project is about. I
want to understand what I can about programming in general, as seen from the
C programmer''s point of view. And so these issues thus become relevant.

So I''ll take your recommendation and see what I can make of it. I''ll also
be interested in the general range of opinions regarding the "good enough"
approach.

Thanks for your response!
--
Email is wtallman at olypen dot com

On Sat, 28 Aug 2004, Malcolm wrote:

"name" <us**@host.domain> wrote

Well, I''ve reached a milestone: Here I have an adequately functional
application I can''t use without some preliminary stuff. If I''m going to
assign dynamic memory, I need to know the file length, or undergo some
sort of guess routine. And other things as well. It''s now immediately
evident that some non-portable code must be written to make this useful.

What to do?

Normally you can use "portable enough" code. If you want to know the length
of a file, open it, fseek() to the end, ftell() the location, and add a few
hundred bytes for luck. In strict ANSI terms this can fail, but practically
it is unlikely that your code will ever have to run on a pathological
platform.

True enough---sometimes you do really need to write non-portable
or "portable enough" code. But lest the OP get the wrong idea:
His program does /not/ require implementation-defined behavior.
Unless he''s changed the specs again, it requires O(k) memory where
k is the number entered at the command line. And that''s something
you can get without knowing anything about file lengths.

I''ll write the program tonight, and maybe post some more thoughts
then. In the meantime, I encourage the OP to examine ''usenetify'',
''usenetify2'', and Leor Zolman''s ''pf'', links to all of which can be
found in the Google Groups archive; search for "usenetify wrapping",
I would think. All three programs were written with portability
in mind, and they all do basically the same thing the OP is trying
to do, albeit with more bells and whistles.

-Arthur

这篇关于包裹思想的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！