[Developers] Modification to input of -cbs and -gbs

[Allan.Hicks at noaa.gov]

Thanks Dave,

I believe that you are right, but I have never used size_t. There are
quite a few discussions of the advantages and disadvantages of size_t,
but it is seems to be implemented as a way to improve portability,
especially between systems. Here is one interesting article:

http://www.eetimes.com/discussion/programming-pointers/4026076/Why-size-t-matters

When compiled with MS 2008 32-bit compiler, size_t is 4 bytes (same as
int and long), but when compiled with MS 2008 64-bit, size_t is 8 bytes
(same as long long).  

My questions are, would this require substantial recoding of the
gradstack and cmpdiff code to properly incorporate size_t? And, in the
interim, is my suggestion of the quick fix (int to long) a useful
change to incorporate since it doesn't appear to break the code and
appears to allow for more memory allocation in Linux?

Allan

----- Original Message -----
From: dave fournier <davef at otter-rsch.com>
Date: Thursday, August 19, 2010 11:03 am
Subject: Re: [Developers] Modification to input of -cbs and -gbs

> Allan Hicks wrote:
> 
> I think the right way to do this is to find the correct type for 
> file 
> lengths and use it. Don't recall what it is but there are types 
> like  
> size_t and pos_t etc.
> They will automatically be defined to be the right type so you 
> avoid 
> using the wrong int type and having to worry about it.
> > Ian Taylor and I just posted a document discussing the results of 
> > testing different values of cbs and gbs for a large ADMB model 
> (SS3).  
> > One thing that we learned is that when using the command line to 
> set 
> > -gbs and -cbs (and -ams) it uses an integer data type. However, 
> it 
> > seems that the code for the calculations associated with the 
> buffers 
> > (excuse my ignorance) uses a long data type.  This limits the 
> inputs 
> > to values less than 2^31 and a total memory allocation around 
> 2Gb.  
> > Linux uses 64-bits to store long integers, thus we made a simple 
> > change to how the command line inputs are read in (used long) and 
> were 
> > able to allocate 12Gb to an ADMB program.  However, Windows uses 
> > 32-bits for a long integer, thus this change makes no difference 
> in 
> > Windows (I have no clue about macs).
> >
> > I made these changes to the xmodel3m.cpp file and attempted to 
> add 
> > some Doxygen comments. I did not attempt to change any of the 
> memory 
> > allocation warnings in gs_set.cpp that still reference 16-bit 
> > systems.  I do not feel I understand the gradstack or cmpdiff 
> buffers 
> > enough to do this intelligently.
> > I am wondering if this change would be useful to add to the 
> source 
> > code, and I am curious of the process to make changes to the 
> source 
> > code and how these changes are verified or moderated.
> >
> > Thanks,
> > Allan
> >
> > ------------------------------------------------------------------
> ------
> >
> > _______________________________________________
> > Developers mailing list
> > Developers at admb-project.org
> > http://lists.admb-project.org/mailman/listinfo/developers
> 
>