Subject | Re: [ib-support] gpre and VisualC++ |
---|---|
Author | Eric Boyajian |
Post date | 2001-06-01T21:27:49Z |
Paul Schmidt <paul@...> wrote in message
They can be renamed/changed -- as long as gpre is modified appropriately at
the same time, end-users of gpre would not be affected the change. Those of
us who thought we were clever enough to have deciphered the usage of these
functions (and proceeded to use them outside of gpre) would be faced with
possibly painful code revisions in the event of a change. Fortunately, I
not that clever!
The only reason I brought the subject up was that I seem to remember an
occasion where understanding the format (expected arguments, return type) of
one of these functions would have eased the debugging of my code.
Eric
> Usually when a function is not documented, it's because it's intendedI agree. Strictly speaking, those functions are *not* part of the API.
> life span is fairly short. We don't want to spend a lot of time,
> investigating and documenting functions, that could potentially
> disappear in the near future. If gpre is the only one that uses a
> function, that's okay, because gpre could easily be fixed to replace
> that function. The C code produced by gpre is transitory anyway,
> and the first thing you do building an app, for a new version is a
> clean build.
They can be renamed/changed -- as long as gpre is modified appropriately at
the same time, end-users of gpre would not be affected the change. Those of
us who thought we were clever enough to have deciphered the usage of these
functions (and proceeded to use them outside of gpre) would be faced with
possibly painful code revisions in the event of a change. Fortunately, I
not that clever!
The only reason I brought the subject up was that I seem to remember an
occasion where understanding the format (expected arguments, return type) of
one of these functions would have eased the debugging of my code.
Eric