|
Thank you for all the above replies... this it totally new so it would take some time for me to ...
Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
I am trying to write a triple vector to a file and then read the file back into the triple vector. When I try to read the file back after its been saved the first fifty values come out correct but the rest of the values are garbage. I'd be really appreciative if someone could help me out here. Thanks a lot!
File declaration:
fstream memory_file("C:\\Users\\Amichai\\Pictures\\output.txt", ios::in | ios::out);
The write function:
void save_training_data(fstream &memory_file, vector<vector<vector<long double> > > &training_data)
{
int sizeI = training_data.size();
memory_file.write((const char *)&sizeI, sizeof(int));
for (int i=0; i < sizeI; i++)
{
int sizeJ = training_data[i].size();
memory_file.write((const char *)&sizeJ, sizeof(int));
for (int j=0; j < sizeJ; j++)
{
int sizeK = training_data[i][j].size();
memory_file.write((const char *)&sizeK, sizeof(int));
for (int k = 0; k < sizeK; k++)
{
int temp;
temp = (int)training_data[i][j][k];
memory_file.write((const char *)&temp, sizeof(int));
}
}
}
}
The read function:
void upload_memory(fstream &memory_file, vector<vector<vector<long double> > > &training_data)
{
memory_file.seekg(ios::beg);
int temp=0;
int sizeK, sizeJ, sizeI;
memory_file.read((char*)&sizeI, sizeof(int));
training_data.resize(sizeI);
for (int i=0; i < sizeI; i++)
{
memory_file.read((char*)&sizeJ, sizeof(int));
training_data[i].resize(sizeJ);
for (int j=0; j < sizeJ; j++)
{
memory_file.read((char*)&sizeK, sizeof(int));
training_data[i][j].resize(sizeK);
for (int k = 0; k < sizeK; k++)
{
memory_file.read((char*)&temp, sizeof(int));
training_data[i][j][k]=temp;
}
}
}
}
Thanks again,
Amichai
|
|
|
|
|
Just solved the problem.
The file declaration needs the ios::binary specification.
|
|
|
|
|
5 for self-solved and posting the solution 
Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Hi
I need declare a wchar_t array which should looks like:
strarray[1] = "ddgfdgd";
strarray[2] = "ddgfdgd ... sada";
...
strarray[n] = "ddgfdgd";
The "n" is variable.
wchar_t** strarray= new wchar_t[n][];
is not correct.
Any suggestion?
|
|
|
|
|
You need to allocate pointers to wchar_t like so:
wchar_t** strarray = new wchar_t*[n];
I tend to use the Windows types for character pointers like so:
LPWSTR* strarray = new LPWSTR[n];
[edit]Add ref to LPWSTR[/edit]
|
|
|
|
|
While Richard has answered your query, you'll be much better off using an array of std::string objects (that is - if you don't want to use something like a vector). This means no hand crafted memory allocation or management, plus no dangling pointers or other pointer related failure modes waiting to crash your application.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
A std::wstring in his case
|
|
|
|
|
Ah, the joys of being a nitpick.
OT: How's married life? Probably too early to comment?
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: Ah, the joys of being a nitpick.
Rajesh R Subramanian wrote: OT: How's married life? Probably too early to comment?
Honnestly, there's not much differences... We were already living together for 3 years so, not much of a change.
|
|
|
|
|
Cedric Moonen wrote: Honnestly, there's not much differences
Don't tell her that...
|
|
|
|
|
Richard MacCutchan wrote: Cedric Moonen wrote:
Honnestly, there's not much differences
Don't tell her that...
Ouch, I already told her! 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Will be there any problems with static libs linkage and what function will be linked and executed?
There are 2 lib files generated from the same project:
1) somelib.lib
2) somelib_updated.lib
Both contain the same function names, but updated has some enhanced functionality, but all the function names are the same.
3) oneimplementation.lib has static linkage with somelib.lib
4) otherimplementation.lib has static linkage with somelib_updated.lib
In 3) it provides myfunction() which uses somelib.lib code
In 4) it provides myfunction_updated() which uses somelib_updated.lib.
Thus is it targeted that due to the fact that we can not change naming in 1) and 2) we are trying to provide wrappers for them for a final exe.
The final exe build scheme is:
1) -> 3)
---------------->final exe app
2) -> 4)
Final exe linkes only to 3) and 4)
Which functions will be linked to final exe? How to make sure 1) and 2) code will be different?
Чесноков
|
|
|
|
|
From your explainations, it will depend on your link command line.
in fact if you link 1 with 3 without providing 2 in the path, you library will have the code from 1.
It's because your are in static, so the library will copy the code during the link operation.
Otherwise you will have an error : duplicate symbols detected
My two cents
|
|
|
|
|
The code is copied. I checked 3) and 4) it does contain message strings from 1) and 2) correspondingly.
But once you compile exe calling both 3) and 4) only function from 1) is called. If you compile it calling only 4) then 2) is called
Чесноков
|
|
|
|
|
Is it possible to make oneimplementation.lib and otherimplementation.lib as DLL's?
-Saurabh
|
|
|
|
|
I need them all to be in static libs
Чесноков
|
|
|
|
|
There are function to convert int and short in to network oder but not for float.
Can any one tell that how can we convert float in to network byte order?
Regards,
Vishal Soni
|
|
|
|
|
Vishal Kumar Soni wrote: There are function to convert int and short in to network oder but not for float.
They have never been standardised. Floats and doubles need to be serialised as described in Beej's guide to network programing: Serialization—How to Pack Data[^], e.g. simply by using sprintf() and atof(). A more elaborate variation, also described in the linked document, would be converting into a portable binary form of the IEEE 754 standard format[^].
Hope this helps.
/M
|
|
|
|
|
Moak,
Thanks very much!!
Regards,
Vishal Soni
|
|
|
|
|
The following will work:
float htonf(float value)
{
float result;
char* pSource = reinterpret_cast<char*>(&value);
char* pDest = reinterpret_cast<char*>(&result);
pDest[0] = pSource[3];
pDest[1] = pSource[2];
pDest[2] = pSource[1];
pDest[3] = pSource[0];
return result;
}
Warning: once a value has been converted to network order do not try to use it on the host, since it is almost certainly an invalid IEEE 754 format number.
Note that the above function also converts from network to host format.
Converting doubles is similar:
double htonf(double value)
{
double result;
char* pSource = reinterpret_cast<char*>(&value);
char* pDest = reinterpret_cast<char*>(&result);
pDest[0] = pSource[7];
pDest[1] = pSource[6];
pDest[2] = pSource[5];
pDest[3] = pSource[4];
pDest[4] = pSource[3];
pDest[5] = pSource[2];
pDest[6] = pSource[1];
pDest[7] = pSource[0];
return result;
}
Graham
Librarians rule, Ook!
|
|
|
|
|
Graham, will this code work between platforms with different memory layouts, since you:
1/ always change the float regardless of the endianess of the source platform (it assumes running on little-Endian)?
2/ is the float memory layout guaranteed to look like this on other platforms (Intel, ARM, PowerPC, etc)?
Cheers, M
|
|
|
|
|
1. You are correct that this always changes the float. The original version is suitable for use on Intel platforms. A portable version is as follows:
bool IsBigEndian()
{
int i = 1;
char* p = reinterpret_cast<char*>(&i);
return *p == 0;
}
float htonf(float value)
{
if(IsBigEndian())
return value;
float result;
char* pSource = reinterpret_cast<char*>(&value);
char* pDest = reinterpret_cast<char*>(&result);
pDest[0] = pSource[3];
pDest[1] = pSource[2];
pDest[2] = pSource[1];
pDest[3] = pSource[0];
return result;
}
2. The assumption here is that float is a single precision IEEE 754 binary floating point and double is a double precision IEEE 754 binary floating point. Whereas early in my career there were a number of different types of floating point support, IEEE 754 is now ubiquitous. So Intel/AMD, Sparc, PowerPC all support IEEE 754. I'm not familiar with the ARM platform, but it looks like this also support IEEE 754
Graham
Librarians rule, Ook!
|
|
|
|
|
Graham Shanks wrote: The assumption here is that float is a single precision IEEE 754 binary floating point and double is a double precision IEEE 754 binary floating point
Ok thanks! I didn't know the binary representation is the same (apart from the memory layout) and directly suitable as interchange format.
|
|
|
|
|
Graham,
Thanks very much!!
Regards,
Vishal Soni
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
(![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
(