|
|
Can anyone tell me how to create a huge 2d array without affecting the processing time too much?
I used double pointer to create an array 2d array[27000][27000] as following:
BYTE **array;
array = (BYTE**)calloc(sizeof(BYTE*), 27000);
for (unsigned int index = 0; index < 27000; index)
array[index] = (BYTE*)calloc(sizeof(BYTE), 27000);
Right now, I need to increase the array size to 54000X54000 or even more. However, the compiler seems to have little problem to compile along with other codes. Even it compiles, the processing time is so slow.
Does anyone have a better way to profrom this task?
Thanks!
|
|
|
|
|
An array with nearly 3 billion elements? You need a 64 bit system to cope with that!
The tigress is here 
|
|
|
|
|
How much memory does your pc have? Your first array takes over 730MB so if you have less than 1GB of ram it will have to do some swapping which is 10 times slower than memory. Also the second array (54,000 X 54,000) is impossible on a 32 bit windows system as it is almost 3 GB.
Also Note:
There is a limit (because of the way dlls load) in a 32 bit windows program that is somewhere near 1.2GB. You may extend that if you create compile your program with the largeaddressaware switch turned on (google for details) and boot a capable operating system with the /3GB switch in your boot.ini file.
John
-- modified at 8:51 Tuesday 4th October, 2005
|
|
|
|
|
You probably dont need that big an array, depends on the kind of data that you will be working on.
May be you need to redesign your implementation so that it works on a small section of the array at a time and rest of the data goes in the array or maybe you need a database.
-prakash
|
|
|
|
|
Look into CreateFileMapping/MapViewOfFile - it might allow you create big "arrays".
|
|
|
|
|
Thanks for all your inputs. The reason for such huge array is storing image information. In other words, 1 array cell equals to 1 pixel and also equals to 1 mil size (may go down to 0.5 mil per pixel). For a size of 54"X54" image, it requires 54000X54000 size of array.
With your expertises, there may be another way to work this out. In MFC, there is a CDC class in which have nice functions to draw on a bitmap. Creating such huge bitmap; however, is not possible. Is there a way to make this work? All I need is drawing some figures on a roster, and then retrieving cell by cell whether being occupied with a color or not.
I may ask too much but please help if you have some possible solutions.
Thanks
|
|
|
|
|
Raymond C wrote:
I used double pointer to create an array 2d array[27000][27000] as following:
For such big array i would suggest doublly linked list. may be it complecates the stuffs but its worth. This will cosiderably improve performance.
If you can tell what for you r using this big array i can suggest.
Take it cool and just finish it.
|
|
|
|
|
Raymond C wrote:
I used double pointer to create an array 2d array[27000][27000] as following:
For such big array i would suggest linked list. may be it complecates the stuffs but its worth. This will cosiderably improve performance.
If you can tell what for you r using this big array i can suggest.
Take it cool and just finish it.
|
|
|
|
|
Hi Karmendra_js,
Thanks for your input. The reason for such huge array is storing image information. In other words, 1 array cell equals to 1 pixel and also equals to 1 mil size (may go down to 0.5 mil per pixel). For a size of 54"X54" image, it requires 54000X54000 size of array.
With your expertises, there may be another way to work this out. In MFC, there is a CDC class in which have nice functions to draw on a bitmap. Creating such huge bitmap; however, is not possible. Is there a way to make this work? All I need is drawing some figures on a roster, and then retrieving cell by cell whether being occupied with a color or not.
I may ask too much but please help if you have some possible solutions.
Thanks in many
|
|
|
|
|
How to retrive the tables from Database (.mdb) file
Plz .Urgent
Rondla
|
|
|
|
|
I was Including Shlwapi.h file in my ctAppRuleParser.cpp.. but i stuck up with the following error
i am using #define _WIN32_WINNT 0x0500 in my application.
ctAppRuleParser.cpp
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : error C2146: syntax error : missing ';' before identifier 'DECLSPEC_IMPORT'
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : error C2501: 'EXTERN_C' : missing storage-class or type specifiers
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : fatal error C1004: unexpected end of file found
ctcapsule.cpp
How can i solve this compilation problem.
Sunil Virmani
|
|
|
|
|
Are you defining _WIN32_WINNT before you are including shlwapi.h? Do both of these exist in your project's stdafx.h file? If so, what does the rest of that file look like?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hi again
When I copy my new application that I have been slaving over to my target PC, I come up with the above error when it is run. Of course, I can go through and copy all the required DLLs over manually as the application tells me they are missing, but there must be a better way!
Is there a method of finding out what resourses have been used by an application? I am using VC++6.0, Windows XP (and 98 sometimes)
Thanks for any help
Mike
|
|
|
|
|
You can use the depency walker tool that is provided with Visual Studio. It will show you all the dll that your application uses.
|
|
|
|
|
Thanks for this. I have just fired up dependency walker and it looks like it does exactly what I want!
Thanks again
Mike
|
|
|
|
|
Mike Winter wrote:
but there must be a better way
Well Mike, firstly - if you are using MFC, then you will have to provide those dlls(mfc*.dll) whereever you ship your application. Secondly - there are better ways, but not THAT better as you are expecting. As of now, I only know two ways:
1. Make an installer, using Installshield or similar software, and include ur dlls with the installer.This is better option as once these dlls are installed, there is no need ship those dlls again on that machine.
2. Statically link the MFC dlls in your application. This will make ur application very heavy. I guess size increase is about 2 Mb and thats the reason enough why this is a bad idea.
so choose ur way...
"Do first things first, and second things not at all."
— Peter Drucker.
|
|
|
|
|
You don't happen to be trying to run the debug version, are you? I had that problem too, saying such and such dll was not found, when I realized I was compiling in debug. If you compile in release (if this is your problem) that problem should go away.
Hope this helps!
Danny
The stupidity of others amazes me!
|
|
|
|
|
I'd like to create a program that has a VB interface but the functionalities came from VC, I think it means using dll files to link the two. The VC will create the server dll and the VB will call them. I came across ATL and COM and found them useful but I'm still a beginner with regards to them so I'd like to ask where do I have to focus to? ATL or COM? I'm a bit on a hurry for a school machine problem and I can't afford to study both of them thoroughly.
I'd like to know their pros and cons and limitations?
Which of them can support MFC functions, can open a file, supports CString, etc, in short, with less limitations?
Please help, any articles will do. Especially regarding an overview of ATL vs COM will do for me to be able to decide which of these 2 should I use. Thanx 
|
|
|
|
|
Hi !
If you need only to call some function that will do some specific tasks (like you said, opening a file, CString, ...) then I suggest you to make a regular dll (so, no COM and no ATL). I don't know ATL so maybe I'm wrong for this part but COM is more oriented to deploy controls and components (and so, if you want just some 'simple' functions, that will be more difficult to implement). I think ATL is more or less the same (with other librairies).
You can create a MFC dll so that you don't have to deal with the 'internals' of the dll. You can just then export the functions you need.
I think there are some articles on this website about dll creation. Anyway, if you have some specific questions, don't hesitate to ask again.
|
|
|
|
|
cedric moonen wrote:
You can create a MFC dll so that you don't have to deal with the 'internals' of the dll. You can just then export the functions you need.
Will MFC dll be able to do what a console app can do? Because, since it will be on the background it will work just like a console process but the display or GUI will thrown out to the calling VB function. What are the limitations of MFC dll over com/atl that made you say that when I'm just going to create simple MFC functions, I'd better use this one?
Thanx for your time
|
|
|
|
|
The MFC dll won't show any window or else... The MFC will just help you to get rid of the development of some specific functions you need to implement in your dll (it will be done for you).
benjnp wrote:
Will MFC dll be able to do what a console app can do?
This doesn't mean a lot. You want your dll to display a console ? If not, then your sentence doesn't mean anything because the dll won't display you the console.
Ok, let's take an exemple. You will be able to do things like that:
int Sum(int a, int b)<br />
{<br />
return (a +b);<br />
}
I thinkm this is what you want to say by 'console application'. So, yes, you can simply export functions that will be called in your VB app.
benjnp wrote:
What are the limitations of MFC dll over com/atl that made you say that when I'm just going to create simple MFC functions, I'd better use this one?
It's not really a matter of limitation but rather trying to use the best tool suited to your needs. The problem with COM is that it has been designed to share components or controls. So there, you will have the problem that it will be used in VB like a control (and then here, you will have to do some things not really clean to avoid this behavior). If we take my previous example (the sum of two numbers), you will need to 'embedd' this function in a component and then access this component through an interface,... So you see, it is deploying a bazooka to kill a bee
I hope this is clear enough.
|
|
|
|
|
cedric moonen wrote:
Ok, let's take an exemple. You will be able to do things like that:
// In your dll:
int Sum(int a, int b)
{
return (a +b);
}
I thinkm this is what you want to say by 'console application'. So, yes, you can simply export functions that will be called in your VB app.
yup, you're right.
I tried to use ATL but I found more complicated for beginners who just want to call VC functions. Does it support CString parameter? because, I'm quite surprised that ATL-based function parameters are not allowed to use them.
Thanx for your help
|
|
|
|
|
Do you know how to use the methods created in MFC dll into the VB prog? does it looks just like any other dll (ATL or COM)?
|
|
|
|
|
ATL and COM doesn't work the same. You cannot compare them, they are used for different purpose. So in COM you don't 'call' functions directly. Instead you use a control (like for example a chart control, a grid control, ...).
It is too long to explain in detail how to work with dll's. Better look here[^], you will find some article that will be very usefull.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
