I would neither store nor return the bitmap data in that way. What you are creating here is a so-called "ragged" array, in which each row can have a different length. In a bitmap this luxury is not needed, all rows are of equal length by definition. Therefore a one-dimensional array is good enough and in some regards even superior.
a) A one-dimensional array can be allocated in one chunk (whereas your ragged array needs N allocations, N being the number of rows)
b) A one-dimensional array does not incur the overhead that comes with a ragged array, which is easily 3 x 64bits per row.
To access the members of the one-dimensional array in a 2D fashion, simply use the algorithm:
index of pixel (x, y) = x + y*pixelsPerRow
As a return value for your access function I would suggest you use a simple pointer (const COLORREF*).
For the caller to know how to access that 1D array you should provide addition access functions for the number or rows and number of columns.
Ohh, I would love to get rif of 2D array ... I had taken the class from here[^], could you assit me how to give up vector> BitmapData ? If I am not asking too much ... I will start working, to see what is happen ... See you.
DLLs also help reduce memory overhead when several applications use the same functionality at the same time, because although each application receives its own copy of the DLL data, the applications share the DLL code.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
Thank you for answer. But if two dlls(having same signature) in two different directories and linked by tw different executable. Then what will happened? Is the design same across different OS.
There's an order by which exe's look for libraries. It will use the first one it finds, I believe CPallini gave you a link that specifies the search order. You can use tools such as Dependency Walker[^] to see what dll specifically is getting loaded by an exe if you're not sure which one it's loading. It is customary that shared dll's are placed in a location where any program that wants to use it has access to it, of course, this will require admin privilidges for your installer (assuming you place the dll copy in a system folder).
As far as object data (memory), that's not shared at all.... it's just the code that is shared. For example, if you have two exe's using an IO dll, the state of one will not affect the other, they're still independent while running. If you want them to share something, you have to set that up using other means (IPC).
I have Visual studio 2005 on WIn7 system. Project dependencies and Buildorder everything is in place and correct.
But it is not Building according to build order correctly when doing clean and Rebuild.
I checked with other win7 sytem it is doing properly there.
It could be because parallel compilation is used on a multi core machine. If two projects are not strictly dependent, they can be built in parallel.
If you wanted to enforce the build order (including single thread compilation), you could set the dependencies in a single row even though theprojects don't really depend on each other. But why would you want to do this?
The good thing about pessimism is, that you are always either right or pleasently surprised.
If build order is important, then specify project dependencies. That should make the build order exactly the same every time.
If memory serves right, in a multi-project solution, you can right click on a project and set dependencies within the menus there. When you make one project dependent on the others, Studio will build the dependencies first.