1 Current issues and bugs
2 -----------------------
7 wxDebugContext and global memory operators doesn't work correctly,
8 for different (unresolved) reasons on different compilers.
10 1) In VC++ 5.0, if you use wxDebugAlloc for new and wxDebugFree
11 for delete, you get a crash to do with deallocating the debug
12 buffer in wxDebugContext. So although the global operators are
13 defined, they are #ifdefed to just call malloc and free to avoid
14 the problem. This means that non-object memory checking doesn't work.
15 The problem does seem to be something to do with a pointer
16 mysteriously changing its address, very similar to 2).
18 2) In BC++ 4.5, there isn't a crash, but instead the ofstream
19 pointer passed to SetStream from SetFile (which is called in
20 memcheck.cpp) gets mysteriously changed as it's passed to SetStream.
21 This means that when counting the number of outstanding memory
22 blocks, we can't compare the allocated block with m_debugStream
23 to say 'ignore this block because we can't free it before the
24 very end of the application'. Therefore it always looks like
25 there's a memory leak of one object, in memory.cpp, unless you
26 don't call wxDebugContext::SetFile.
28 The fact that pointers appear to change in both cases must
29 indicate a common problem and solution. If we could use the
30 standard global memory operators for ofstream and
31 wxDebugStreamBuf it might help, but I don't know how to do that -
32 I've redefined 'new' throughout as WXDEBUG_NEW (which is itself
33 defined as the 3-argument operator).
35 Config/registry classes
36 -----------------------
38 Problems with Karsten's/Vadim's existing AppConfig classes:
40 - use char* a lot instead of wxString
41 - rather hard to understand
42 - will need fairly substantial rewrite
43 - no native .ini functions (?) for guaranteed Windows
45 - new wxWin docs required
50 - FileConfig independent of OS
51 - specifying a base class that will meet nearly all needs for
55 Other features we should probably have:
57 - ability to specify vendor name/app name in constructor
58 - under Windows, ability to read/write all areas of registry
64 - start from own CRegistry class
65 - take elements from both
66 - do the Windows stuff, let someone else write/adapt the