[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20010629: alloc.h

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20010629: alloc.h
  • Date: Thu, 05 Jul 2001 10:27:07 -0600
Paul Hamer wrote:
> > 
> Anne,
> 
> A few years ago, following conversations with Glenn Davis, I
> wrote a few classes to map to the ldm product queue directly.
> I was told at the time, and it's actually turned out to be
> true, that the various library calls in the ldmlib would
> not change. So I actually have classes that include ldm.h
> from /usr/local/ldm/include and link to the ldmlib.a to
> build executables. Since I have -I/usr/local/ldm/include
> in the include path I get alloc.h
> 
> Looking for includes from specific and not some general
> directories is done quite alot. ACE, for example, does the
> same thing. It certainly helps stop the sort of problem I
> described above. I would like to see only those header files
> that are really necessary for using ldmlib in include since
> they are all that's required for any application.
> 

Hi Paul,

From my searching, it looks like alloc.h doesn't need to be in
'include'.  In the next distribution I'll try removing it.  But, we
probably won't make another distribution for a while.

> BTW, using the preprocessor in LDM has also caused me a
> few problems. For example:
> 
> "#define ACARS 64"
> 
> in ldm.h has made me wonder what was going on for a few
> minutes with some build I was doing. I think a better practice
> is using:
> 
> "static const int ACARS = 64;"
> 
> but that's going to be abit of work.
> 

Yes, I agree that would be better.  But I have to prioritize my jobs to
fit my resources, which are limited.  I'll make a note of it, but I
probably won't go there.


> Thanks for looking into this.
> 
> Paul.
> 

You're welcome!

Anne
-- 
***************************************************
Anne Wilson                     UCAR Unidata Program            
address@hidden                 P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************