0

I am trying to create a very large array, to which, I then get the following error.

char largearray[1744830451];

warning LNK4084: total image size 1750372352 exceeds max (268435456); image may not run

I was told I could use a C-array and not C++ . I'm not sure I fully understood my friend's response. I am currently using Visual Studio 6.0 C++ . Do I need to get another compiler to do straight C or is it a method to how to declare the array that needs to change?

If I need to change compilers, does someone have suggestions?

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
iBoston
  • 69
  • 1
  • 9
  • 3
    Visual Studio 6.0 is *ancient*. Regardless you're exceeding the maximum image size for a 32 bit process. You need to compile for 64 bit. And probably re-think your algorithms and strategy! – Robinson Jul 04 '15 at 20:25
  • 1
    Why are running VC6? – Dai Jul 04 '15 at 20:26
  • 1
    There's no C++ involved here at all. You might have misunderstood your friend, or he/she is simply wrong. – Marcus Müller Jul 04 '15 at 20:27
  • 2
    FYI, stress **ancient**. That product was released 17 *years* ago (1998), succeeded four years later by Visual Studio.NET (2002). – WhozCraig Jul 04 '15 at 20:28
  • 1
    Also, there's even free IDEs from Microsoft that very probably include everything a fully blown VC6 with a lot of expensive add-on functionality could provide. Also, with buffers this large, you'll probably **need** 64 bit and thus VC6 is not even theoretically an option. – Marcus Müller Jul 04 '15 at 20:30
  • Well at least it's not Turbo C++ so you have that going for you. – Captain Obvlious Jul 04 '15 at 21:03
  • By the way, if you need so huge array perhaps you have to reconsider your algorithm... or to look for a new form of living. – Luis Colorado Jul 05 '15 at 17:57

2 Answers2

4

The char array[size] syntax means the array will be created in the data section of your compiled program and not allocated at runtime.

Win32 PE code cannot exceed 256MB (according to your linker's error message), but the array you're declaring is 1.6GB in length.

If you want a 1.6GB array, use malloc (and don't forget to call free!)

...but why on earth are you running VC6?

Dai
  • 141,631
  • 28
  • 261
  • 374
  • 3
    or `new[]`/`delete[]`. –  Jul 04 '15 at 20:27
  • 2
    Although correct that dynamic allocation is necessary, from my experience there's a good chance there won't be 1.6GB of contiguous space available within a 32bit process on Windows. – TheUndeadFish Jul 04 '15 at 20:30
  • @TheUndeadFish: I don't do much work on Windows, but it being a modern OS running something with at least as much of an MMU as the intel 386, that's not a problem; memory is generally not contiguous prior to being mapped to user land on x86. – Marcus Müller Jul 04 '15 at 20:31
  • I am using VC6 because that is what is here at the company, and what they have to compile their program. If it isn't broken, don't fix it.. I will look into malloc. – iBoston Jul 04 '15 at 20:33
  • 2
    **This is broken.** Talk to your manager. You can't use VC6 with this much data. It will break. Explanation: VC6 only supports 32 bit. 32 bit processes can only have an address space of 2GB. Your data buffer is 1.7GB large, but it can't be placed everywhere. If things compile fine, you're lucky, but extend that size by a few percent, or change something else in the source code, and you're doomed.Also,VC6 is old.It's end-of-life.Every product that can only be built with it is practically dead,as soon as microsoft doesn't care to support the old runtime environments in newer versions of Windows. – Marcus Müller Jul 04 '15 at 20:35
  • I've seen Dlls (from mouse drivers, shell extensions, etc) load themselves right into the middle of what would have been contiguous user-land address space. So you get a situation where maybe it works on one machine but not another due to a different environment. Or maybe it works until you invoke a File Open dialog. So my point is that within a 32bit process, having large amounts of contiguous space is unreliable. – TheUndeadFish Jul 04 '15 at 20:37
  • @TheUndeadFish this isn't MSDOS. Each process's memory is completely separate from all other processes, including OS memory. But you're right about this working unreliably under 32 bit -- see my reply. – Marcus Müller Jul 04 '15 at 20:38
  • What 64 bit free compiler would you recommend. I could do some research, and take it to the higher ups. – iBoston Jul 04 '15 at 20:47
  • Microsoft Visual Studio, if you're using Microsoft libraries. There's a free Express and Community Edition. Also have a look at Eclipse with the CDT. The debugging in there is really really impressive! Note that 64bit is no longer a feature -- it's generally the default. Oh god. VC6 is old. Myself, I'm a developer under linux, and I've used vim for most of my work -- this will hardly please you/your higher-ups. – Marcus Müller Jul 04 '15 at 20:54
0

If you predefine the size, then you are restricted to the stack size (stack has less size but faster), so it is better to define the size dynamically, which means your data is stored in heap (heap has bigger size but a little bit slower than stack).

Have a look at http://gribblelab.org/CBootcamp/7_Memory_Stack_vs_Heap.html which explains the difference of stack and heap.

crbah
  • 338
  • 4
  • 12