Re: [OT:] FTP clients

From: Active8 (reply2group_at_ndbbm.net)
Date: 03/01/05 

Date: Tue, 1 Mar 2005 08:02:10 -0500

On 01 Mar 2005 11:04:16 GMT,
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote:

> Active8 <reply2group@ndbbm.net> wrote:
>>On 01 Mar 2005 05:49:30 GMT,
>>pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote:
>
>>>>Opening output.fft and loading it into a std::vector<float> screws
>>>>up, but input1.dat doesn't. It does load the vector, too. It just
>>>>craps out when you return to the console, or in the [wx]winders app,
>>>>the message loop. I think it has something to do with the
>>>>vector<float> going out of scope. The fft file is 512 floats and I
>>>>converted the actual values to test.txt. They didn't look right
>>>>plotted either, but I can deal with that later.
>>>
>>>>I did it in VC++ which might not have it's STL sh*t together. I bet
>>>>it runs on a linux box. I might try that.
>>>
>>>>Anyone want some c++ classes that operate on s, y, and z params? It
>>>>stores them as complex numbers with accessor functions, operator
>>>
>>> Storeing numbers as binary data is something that unix os avoided quite early
>>> due that it easily cause problems with different formats. Ofcourse it's
>>> slightly slower.. ;)
>
>>You can still store binary data. It's built in to the c++ language.
>>Betcha sizeof(float) is 4.
>
> Format of numbers may change between compiler and architecture.
> There is a reason for htonl() etc..

Those are macros and they just change the byte ordering for
networking.

Just because unices use text files to configure everything doesn't
mean they *have* to - as if their machine would wake up one day and
decide to treat ints as 2 bytes. I suppose unix coders store images
and audio as text, too. You still have to know how to read the
format.

What's your point, anyway? It's irrelevant to anything I've said.
And BTW, those classes, when I say "stores them as complex numbers
with accessor functions," that clearly indicates that I'm speaking
about something internal to the class and doesn't even begin to
suggest whether I store them as text either in memory or on disk. In
fact, the original program read the s-params in from a text file.

Since I can't expect my ADC to give me ints in text... I don't know
why I'd want to slow things down storing a signal as text on a disk.

Does the program in the first link compile on your Sun OS? 

-- 
Best Regards,
Mike

Relevant Pages

  • Re: vm02 update
    ... Instant Pascal was a misguided attempt at creating an IDE with automatic formatting and almost instant feedback. ... Editing the source in a tokenized format would keep the memory constraints lower and ease the first pass of the compiler. ... compiled to machine code at all. ...
    (comp.sys.apple2.programmer)
  • Re: OT: ASCII files and Intel P4 MMX instructions
    ... ASCII ... The file format is clean, one number per line, no fuzz. ... While I have played a bit with the settings in the compiler, ... are often dominated by the conversion from and to the external character ...
    (comp.dsp)
  • Re: Strange error in CLISP
    ... I removed the last parameter to #'format by mistake, ... Didn't expect the compiler to be ... the very flexible nature of format string directives, ... (defun test (flag) ...
    (comp.lang.lisp)
  • Re: GENERATING AUTOMATIC NUMBERS
    ... I suggest you store two fields: ... > Date-auto increment format. ... Year in NN format, Julian Date in NNN format, ... I would like this feature to key off when the the preceding field, ...
    (microsoft.public.access.formscoding)
  • Re: replace statement and free format
    ... doesn't) that a vendor PRODUCE a compile-time listing of the source code. ... Free form reference format allows for each source line to have 255 characters ... - Depending on how many "passes" your compiler does of source code, ...
    (comp.lang.cobol)