'new'ing >64K Objects in BC++ 
Author Message
 'new'ing >64K Objects in BC++

Is there an equivalent of farmalloc() in BC++ for 'new'?  It seems
that the BC++ uses size_t to calculate the size of the memory chunk
it's getting with 'new', thus limiting it to 64K-1 in size.  (size_t,
I believe, is unsigned int in BC++)

Given the fact that BC++ uses a signed int for an array index, and
you'll find maintaining a large array is difficult.  Perhaps I should
switch to djgpp :(

Stephen

P.S.  What's the difference between djgpp and g++ other than that
they're maintained by different people?  The g++ source have files
like something.com in it so is it possible to compile g++ under DOS?
--
Stephen Lee



Fri, 28 Apr 1995 02:18:52 GMT  
 'new'ing >64K Objects in BC++
Followups have been directed to comp.os.msdos.programmer only (hint,hint).


Quote:
>Is there an equivalent of farmalloc() in BC++ for 'new'?  It seems
>that the BC++ uses size_t to calculate the size of the memory chunk
>it's getting with 'new', thus limiting it to 64K-1 in size.  (size_t,
>I believe, is unsigned int in BC++)

Right, and BC++ defines an int as 16 bits.  If you want to work with
arrays over 64K in BC++ you must use the non-standard 'huge' keyword.
When allocating an array >64K you must use farmalloc() which takes an
'unsigned long' or 'new huge' which calls
        void* operator new(unsigned long);
instead of
        void* operator new(size_t);

        // for arrays
        extern char huge array[];  // in header file
        char huge array[80000];    // in .c or .cpp file

        // for pointers to arrays
        extern char huge* p;       // in header file
        char huge* p = new huge char[80000];  // in .cpp file

Be careful when using 'huge' pointers.  Turn on and pay attention to
all compiler warnings; don't blindly cast to shut the compiler up.

Quote:
>Given the fact that BC++ uses a signed int for an array index, and
>you'll find maintaining a large array is difficult.

Well, you can index an array with any integral type, signed or
unsigned, with BC++ or with any other working C compiler.  As long as
the arithmetic results[1] in reference to a valid element of the
array, you're fine.

Quote:
>Perhaps I should switch to djgpp :(

Maybe.  At least then you can write real C code without relying on
compiler extensions.  Btw, PharLap sells a DOS Extender that works
with BC++ or MSC.  I believe that a 16-bit Extender allows you to
access all your machine's memory (up to 16MB), but size_t and int are
still 16-bits, so each object is limited to 64K.  A 32-bit Extender
(like the one in DJGPP) makes them 32-bits so there are no 64K limits.

Currently I just don't use single arrays larger than 64K.  I do most
of my programming under MS Windows (which is why I don't use DJGPP),
so at least I have access to all my machines memory (Windows functions
as a 16-bit DOS Extender).  A 16-bit Extender requires a 286 or
better; a 32-bit extender requires a 386 or better.  Let me know if
I'm wrong about any of this.

Quote:
>P.S.  What's the difference between djgpp and g++ other than that
>they're maintained by different people?  The g++ source have files
>like something.com in it so is it possible to compile g++ under DOS?

DJGPP is the port by DJ Delorie of GNU gcc 2.x (gcc 2.x includes the
C++ compiler) to MS-DOS.  It uses a DOS Extender which DJ Delorie also
wrote.  He recently posted in c.o.m.p that 1.09 has been released.
See its readme and faq for more info.

[1] Not only must the result point into the array (or at most one element
    off the end), but each subexpression must result in a valid pointer.
    For example array[-1+1] is not correct because it might be evaluated
    as *((array-1)+1), and (array-1) might cause an addressing exception.

Jamshid Afshar



Sun, 30 Apr 1995 12:57:11 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Q:Frequent malloc'ing and free'ing

2. C DLL Can't Find VB3Array>64K

3. Malloc'ing > 64kb

4. Malloc'ing > 64kb

5. DAO code samples - found some but having problems with Release'ing objects

6. HELP with BC qsort and aray >64k

7. problems with reading blocks >64k under bc++3.1

8. BC 3.1 arrays >64k.... CAN BE DONE

9. adding new .lib's to BC 3.0

10. adding new .lib's to BC 3.0

11. how to prevent 'free'-ing memory twice

12. read()'ing from a child's piped stdout

 

 
Powered by phpBB® Forum Software