× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Tue, 15 Jan 2002, Simon Coulter wrote:

> >This is the "dynamic array" issue.  As I've said before, handling
> >undetermined quantities of data is probably better handled in the
> >database, and not within program code.
>
> Ahh, but you might not writing a database program.  In my case I need this
> sort of dynamic array support when I can not afford the cost of the I/O.
> It is much quicker to scan main storage than DASD and a based array is
> faster than any sort of messing with SETOBJACC.  Who among you uses based
> arrays, dynamic storage, qsort() and bsearch()?  They certainly don't
> feature in all my programs but sometimes they are a godsend and we
> couldn't do it without pointers.

Good points.  I'll add that often I need to store some data in an
array-type structure but I don't know how many elements I need.  So
compile time array is out.  Use a file you say?  Ick.  My data may only be
a very few variables.  I don't want to create a file - even a temporary
file - just as a workspace.  It is too much work.  Externally described or
program described?  In QTEMP or elsewhere?  What about creating/deleting
the file?  F specs and I specs?  Overrides?  What about adding a variable
or changing variables easily?  Files are too much work.  Use files for
*storing* data, not as a work space.  With typedef and pointers I can do:

        structure = malloc ((sizeof(structure_type) * number_of_elements))

Only one line of code to get what I need.  And this is useful in RPG
application programming, not just system programming.  I think this is
basically what subfiles do, and we use those all the time.

> >Function pointers are a different issue from the current
> >discussion that involves basing pointers.  If you're looking
> >at a lot of "call-back" functions in your application, you
> >probably should be using an object-oriented language instead.
>
> Yes, but since true OO requires a significant investment on the part of
> the programmer, callbacks are a useful mechanism to "embrace and extend".
> They are also language independent which OO is most certainly not.  Again
> they are not commonly required but very useful none-the-less.  Who among
> you have implemented callbacks for some of your procedures?  Who among you
> have written the callbacks required by qsort() and bsearch()?

I have only used callbacks in event-driven programming like GTK or Motif
(with a possible exception or two - don't really remember).  Event-driven
programming is loosely modelled at our shop by doing stuff like:

C       1       doweq   1
C               exfmt   screen
C               select
C       *inkc   wheneq  *on
C               eval    err = exit_function(args)
C       *inkl   wheneq  *on
C               eval    err = cancel_function(args)
C       etc...
C               enddo

which doesn't really require call back functions.  I'm interested to know
what uses you have used callbacks in?  What exactly was the scenario?

> Much of this falls into the serious pointyhead programmer arena but it
> would be interesting to know how many of us:
>
>       a) Understand and use this stuff when required
>       b) Have heard of it and would like to try it out
>       c) Have heard of it and wouldn't go anywhere near it
>       d) Have no idea what I'm talking about :)

I guess depending on who you ask I could fall into any of these :)

James Rich
james@eaerich.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.