|
I have a structure, suppose USER_INFO. When my program starts it serializes this structure from an archive file. My program uses these values, modifies few of them and when my program exists it serializes all values to that file again which it can read again on next start up. This way I stores the state of the application.
Now the problem is that when I add a new field (or structure member variable) to structure. It can not read the old values from the file because structure size is now changed. I want a solution to overcome this problem. Currently an alternative way which I am using is introducing a new structure, read the old data in old structure, copy old data from old structure to new structure and write the new structure to the file. But it is not a good solution. Can Sqlite db give a better solution because adding a new filed in db is not a big problem?
|
|
|
|
|
Are you using MFC?
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
|
|
Looks like it can be helpful. I can specify schema version in that and at them time of reading I can check for the schema version. However I was storing whole cmap<cstring, structure=""> into file. I am not using << or >> operators to read and write each element one by one. So using schema version I can detect version but still I need to create another structure to load new schema version data while old schema data can be loaded into old structure. I want a solution in which I can read old schema data into new structures. So that I don't have to keep both structure versions in code. It should eliminate copying from one structure(old structure) to another structure(new structure).
|
|
|
|
|
My cmap is like
cmap<CString, LPCTSTR, STRUCT_USER_INFO, STRUCT_USER_INFO&>
writing to file like this
CFile file;
file.Open(pApp->AppFolderPath + "\\my_archive_file", CFile::modeCreate|CFile::modeWrite|CFile::modeNoTruncate);
CArchive ar(&file, CArchive::store);
pApp->cmap_st_user_info.Serialize(ar);
ar.Close();
file.Close();
|
|
|
|
|
The only problem I see is the non-portability of writing the structure to the file instead of individual items. That is compiler structure [type] alignment dependent and may change from one compiler to the next or one version of the compiler to the next.
Your solution sounds like a simple application of the KISS principle and avoids the problems of more complex solutions. Just add a header of some kind to the file. The header should contain an identifier, marking the file as the correct type, and a version number indicating the format type (a.k.a. data type [structure type]). This also has the advantage of being cross-language and cross-platform supportable.
It sounds like all the data is read into memory at start up. In that case you only need one method (function) to read the file and convert it to the internal data structure at start up and one for writing it (if it has changed) out when shutting down.
I used the above method in a commercial application (originally written in C) that supports file formats going back over 20 years. This is comparable to reading and writing Word or other document types that contain version specific format support.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
Hi, I have been looking for the answer to this for a long time using google and everything.
I may have found some postings, but those didn't fully help me to understand this.
So I checked CStringT and CSimpleStringT, and what I found is that there is only this, "operator PCXSTR()"
This seems to say that CString, which is simply CSTringT<TCHAR>, can be converted ONLY to PCXSTR.
However, this code below works fine.
----------------------------------------------
CString m_str = TEXT("abcd");
LPCTSTR m_lpctstr = _str; // success
----------------------------------------------
Based on the fact that there is one operator method, which is operator PCXSTR(), I guess the complier just casts PCXSTR into LPCTSTR automatically, because this code below again works also fine.
----------------------------------------------
CString m_str = TEXT("abcd");
LPCTSTR m_lpctstr = (LPCTSTR)_str; // success
----------------------------------------------
Is this correct? Type PCXSTR is just converted to type LPCTSTR, which makes it seems that CString is also converted to LPCTSTR as if CString has LPCTSTR operator?
(I am, of course, talking about this in UNICODE circumstance by the way)
I think I know that I misunderstand something that could be critical, but I don't even know
where to start to solve this.
Thanks in advance.
|
|
|
|
|
Dean Seo wrote: as if CString has LPCTSTR operator
Actually, it does have one: CString::operator LPCTSTR[^]
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Rajesh R Subramanian wrote: Actually, it does have one
In Visual Studio 6 
This changed when CString was split off from MFC...
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
You're correct. However, CSimpleStringT does have a PCXSTR operator defined (which when compiling for Unicode should be LPCWSTR).
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks for answering my question.
This helps me a lot.
So consequently, in UNICODE circumstance, the complier automatically casts PCXSTR to LPCWSTR, or LPCTSTR?
Also, that is why CSimpleStringT only needs operator PCXSTR()?
Thank you.
|
|
|
|
|
Yes, Dean. You're correct. Excerpt from the header atlsimpstr.h
template< typename BaseType = char >
class ChTraitsBase
{
public:
typedef char XCHAR;
typedef LPSTR PXSTR;
typedef LPCSTR PCXSTR;
typedef wchar_t YCHAR;
typedef LPWSTR PYSTR;
typedef LPCWSTR PCYSTR;
};
template<>
class ChTraitsBase< wchar_t >
{
public:
typedef wchar_t XCHAR;
typedef LPWSTR PXSTR;
typedef LPCWSTR PCXSTR;
typedef char YCHAR;
typedef LPSTR PYSTR;
typedef LPCSTR PCYSTR;
};
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Thanks.
This helps me a lot and I now feel that I understand MFC more than before.
|
|
|
|
|
Is AfxGetMainWnd a function pointer to method "AfxGetMainWnd"?
I use "(CMainFrame*)AfxGetMainWnd;" to get CMainFrame pointer, but no Exception show.
|
|
|
|
|
yu-jian wrote: Is AfxGetMainWnd a function pointer to method "AfxGetMainWnd"?
No. Why would you think that and why do you expect an exception?
By the way, you have the source code - you can look at the function
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Because I use the AfxGetMainWnd but AfxGetMainWnd() to get CMainFrame, when compiling no error show. When running, I found that that m_hwnd of (CMainFrame*)AfxGetMainWnd is 0x00000000, I think that if the compiler can give a exception when compiling, it can save much time for me .
|
|
|
|
|
As you can see here[^] AfxGetMainWnd() returns a CWnd* i.e. a pointer to a CWnd object. In your call you actually want a pointer to your CMainFrame object, so you have to use the cast to let the compiler know that the return value will actually be a pointer to a different object type than described in the function definition. Remember also that you can only cast to an object that derives from the original, and since CMainFrame derives from CWnd this will work OK.
The best things in life are not things.
|
|
|
|
|
You are using a C style typecast here. By doing so you tell the compiler taht YOU know that the variable you're casting is in truth of the type you are casting to. The compiler will therefore ignore any other information and believe you.
The compiler is simply doing what you tell it: ignore the stupidity of the cast.
Maybe you can take one lesson from this: never use C-Style type casts. They are almost always an error!
Check out GotW # 17 to learn more about type casts and how (not) to use them.
|
|
|
|
|
If you want an exception, you should try calling any of the CMainFrame methods using the returned pointer. 
|
|
|
|
|
Why would that happen? As far as I recall from MFC CMainFrame derives from CFrameWnd which derives from CWnd, so it should be OK. I must admit I don't use MFC these days so I may well be wrong.
The best things in life are not things.
|
|
|
|
|
Here is what I meant.
This code will work fine -
CMainFrame* pFrame = (CMainFrame*)AfxGetMainWnd();
pFrame->BringWindowToTop(); But this one -
CMainFrame* pFrame = (CMainFrame*)AfxGetMainWnd;
pFrame->BringWindowToTop(); Because AfxGetMainWnd without the () is a function pointer and not a CWnd derived class pointer.
|
|
|
|
|
Very true, but I would not expect the second sample to compile.
The best things in life are not things.
|
|
|
|
|
I just did. 
|
|
|
|
|
Me too; fascinating, you learn something new every day.
The best things in life are not things.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
