Re: Library Design, f0dder's nightmare.

I am pleased to see that you have fixed another mistake after the first
demo mistake but I suggest to you that a sequence of blunders on this
scale while using your example as a model of how other people should
design their code hasn't sold the case you wish to flog over time.

Now rather than trying to use flawed examples to criticise other
people's work, if you bothered to properly develop the algo you could
get something like reasonable results for a very old architecture like
argv - argc that would be popular with people who ant to use an old
architecture like this.

Using the stack may be easy in this context but its not good design as
the application that uses the algo needs to compensate for the unknown
stack offset. You can do a lot better with just a little simple
arithmetic.

A 32k command line can at the most have 16k of arguments, (1 character
and one delimiter so you dynamically allocate a 64k array to store
pointers. Feed it through your parser to get the offset of each
argument and overwrite the trailing delimiter with a zero. Write each
offset to its appropriate place in the array of pointers and when you
have finished the scan of the buffer, either original or a copy, you
reallocate the buffer size back down to the last member written to it
so you are not wasting memory.

You need to pass back 2 pieces of information, the argument count and
the pointer array offset. In assembler you would use two (2) registers
but if you need to use it from a high level language, you would
probably pass the address of a structure and write the two values to
it.

You can do it even smarter by testing the command line length, and
dividing the byte count by two to determine the maximum pointer array
size array so it uses even less memory.

This is not a particularly hard algo to code and if you bothered to put
it together in a reliable manner, it would be fast, safe and convenient
to use without offsetting the stack by an unpredictable amount.

Regards,

hutch at movsd dot com

.

Relevant Pages

  • Re: question on reference to array slice
    ... array by looking it up in this pointer array. ... AREF => $aref, ... OFFSET => $offset, ...
    (comp.lang.perl.misc)
  • Re: Array descriptors
    ... There seem to be two ways of implementing the array descriptors ("dope ... where the base_address plus the offset defines the first memory ... Sun Fortran uses a third option. ... origin, your base address, and a virtual origin, the address ...
    (comp.lang.fortran)
  • Re: Offset/match returns #value error
    ... Yes the formula in the original post works fine using INDEX instead of ... OFFSET. ... The other formulas come from elsewhere in the workbook and were ... What I was doing in my last post was building an array using INDEX as follows: ...
    (microsoft.public.excel.worksheet.functions)
  • Re: A taxonomy of types
    ... array semantics, ...) ... you mean "following correct offset operator semantics"... ... What does exist is based exclusively on pointer type. ... "int an integer, typically reflecting the natural size of integers on ...
    (comp.lang.misc)
  • Re: fast dictionary search algorithm
    ... >> requested word's meaning in the shortest time possible. ... >Im no expert but I would have thought a binary search for a hash from ... using it as an array offset. ...
    (comp.programming)