What is the best way to store data (eg arrays containing correlation matrices, other parameters) in a c++ dll? I am using Visual Studio.Do you have to manually initialise all the array elements within the main code, or is there some other way where data tables can be created and compiled as part of the dll?Any help you can provide would be great. Sorry if this has been asked already, but I couldn't find any references when I searched.

dlls are not really designed for storage. you might want to look at databases. May I ask without seeming too arrogant how much experience you have of programming ?

Thanks - I'd describe my experience as fairly limited - most of the stuff I've done has been using C# rather than C++ - and parameters have been imported from a spreadsheet as part of the C# code. I wanted to make the application independent of having to access a spreadsheet of parameters, and wondered whether there was a 'neat' way to package them up in the code itself. I'm not talking about massive amounts of storage, just say the values for a few 20 * 20 arrays.

It turns out that that DLLs were specifically designed to hold data, as are all Windows executables.Most of the pictures (button, icons, fonts) "in" a Windows application are stored in DLLs, or sometimes the EXE.As is the text for Menus, the structure of dialogs, and in particular strings....The easiest way for a newbie is to create a StringTable described at http://msdn.microsoft.com/en-us/library ... ).aspxThen simply have a loop that converts the strings to doubles.This is pathetically easy to maintain, especially once you realise that the StringTable can itself be generated in C++, but also in Excel VBAYou then need to read up on the Resource Compiler which shoves the compiled resource onto your DLL or EXE.But that's not the only way...DLLs are just files, so provided it is not "open" by an application, you can read and write to it.You have a simple app that opens the DLL, seeks to the end, and writes data.When run, the DLL opens itself for reading (a call for read/write will fail), seeks to the end - the known length of the array (sizeof(double) * rows * cols) then reads.Coerce the buffer you've just read into an array, and off you go.The advanced student will recognise that there is actually no reason why the whole spreadsheet cannot be encapsulated into the DLL (or an EXE), so you could have a program that writes the spreadsheet to a temporary file, fires up Excel to run it, and the workbook includes a VBA project that references the code that launched Excel in the first place.This can be used to deal with the "where the fuck is my DLL" problem that I regularly get asked.Since the EXE or DLL can ask Win32 where it is, you can alter the VBA code in the buffer that points to it. That's fiddly, and of more use to XLL developers because that interface is designed to allow the user to say where a XLL or DLL lives.

Thanks Dominic for your time - that's given me some great guidance for how to proceed. I think I'll start with the StringTable approach you mention and build a VBA routine to output these from my spreadsheet.Thanks once again for your help.

You can just export the data as if it was a function. MSDN Link

Thanks - that's good to know. My first stage is to get the data into the dll, for which Dominic has kindly provided a number of different methods. It's useful that I could subsequently access/export this directly, too.Thanks for your help