|
Lists don't have indexed access using int, as arrays do. Instead you can iterate and access elements through POSITIONs. Internally, a POSITION is just a pointer to one of the list nodes, which in turn points to the actual data, but it's better if you avoid considering the internal details and just use it as an abstract POSITION, regardless of implementation details.
Iterating lists, as in the code you showed, can be written like this:
POSITION pos = str.list.GetHeadPosition();
while (pos)
{
lst.AddTail(str.list.GetNext(pos));
}
However, if both are CStringLists, you can add one to the other like this:
lst.AddTail(str.list);
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks that did it.
Robins E
ebinaini@163.com
nothing
|
|
|
|
|
In addition, MFC containers are total crap. Try moving to the STL.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
...MFC containers are total crap.
How so?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
well, you realise they were written for use before the STL came online ?
Three things spring to mind:
1. They don't use common iterators, so it's not easy to move stuff from one to another, or work with two different types of container together
2. They don't support function objects
3. They don't have a library of prebuilt algorithms defining the majority of operations you're likely to want to do on items in a container.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
But the lack of those things does not explain why MFC is considered crap. If a person never has a need for common iterators, function objects, or prebuilt algorithms, are they therefore still considered crap?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Well, here are some points
1. If a person finds themselves suddenly in a non MFC app, they will be lost, because they've relied on MFC for things that it's not really good at, instead of using C++ itself
2. I can't see too many people NEVER needing the better support that the std library, which works everywhere, offers. So why learn a lesser library, that only works in MFC apps ?
Beyond that, I'm sure they do what they're supposed to, I just don't see the point in learning something that is limited in two ways, in how they can be used, and where you can use them.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
All valid points, but they still fail to explain why "MFC is crap." I've been using them since 1992 and they have served me quite well. The only classes that I still have no need for are ones beginning COlexxx. I recently found an error in CString::Delete() that has existed for several versions but is now fixed with VS 2005. That would hardly be fair of me to label the entire library as crap, however. Back in the mid 90s, I found a bug in one of the common controls (SysListView32). After proving that it could be reproduced in VB, C, and MFC, I was finally able to talk with level 2 support in the common controls group at Microsoft. I certainly did not consider any of the common controls, especially that one, to be crap. It was a very isolated problem.
Christian Graus wrote:
1. If a person finds themselves suddenly in a non MFC app, they will be lost, because they've relied on MFC for things that it's not really good at, instead of using C++ itself
Are you assuming that the non-MFC application is still GUI? If so, I'm not sure how the STL would be of any help to someone wanting to create a GUI application. If not, then the STL would certainly be of value.
Christian Graus wrote:
2. I can't see too many people NEVER needing the better support that the std library...
How is it better supported? Are you talking about support from Microsoft?
Christian Graus wrote:
I just don't see the point in learning something that is limited in two ways, in how they can be used, and where you can use them.
All tools have limitations. Those limitations, however, are not always relevant to the solution.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
All valid points, but they still fail to explain why "MFC is crap."
The MFC *containers* are crap. For the reasons I have stated.
DavidCrow wrote:
Are you assuming that the non-MFC application is still GUI? If
No, why would I ?
DavidCrow wrote:
If so, I'm not sure how the STL would be of any help to someone wanting to create a GUI application. If not, then the STL would certainly be of value.
You seem to have missed my point. If I am working on a nonMFC app, and I need containers, if I have learned the MFC ones instead of STL ( as many do ), I will be initially lost.
DavidCrow wrote:
How is it better supported? Are you talking about support from Microsoft?
No, I'm talking about compilers that support the STL, compared to compilers that support MFC.
DavidCrow wrote:
All tools have limitations. Those limitations, however, are not always relevant to the solution.
Yes, I agree. MFC in general has limitations, but I still regard it as a good library, certainly a good alternative to Win32. However, like I said, it does include stuff that IMO does not add to the library, and encourages bad programming practice. The MFC containers were written prior to the C++ standard, and exist for legacy support. I'm aware of shops that don't let programmers use STL because 'Microsoft has containers and we're a Microsoft shop'. That sort of idiocy, combined with general ignorance ( that is, people using MFC find the containers, and have no idea there is a standard alternative ), is the reason I remain a pariah, a lone preacher in the wilderness, defending the use of the standard library for containers.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
The MFC *containers* are crap.
My bad. I overlooked the 'containers' part.
Christian Graus wrote:
If I am working on a nonMFC app, and I need containers, if I have learned the MFC ones instead of STL ( as many do ), I will be initially lost.
Why? That implies that those who do not know/use STL are lost. Can such a generalization be made?
Christian Graus wrote:
No, I'm talking about compilers that support the STL, compared to compilers that support MFC.
Ok, but what if support for more than one compiler is not one of the requirements? Is that still a reason to use one over the other?
Christian Graus wrote:
However, like I said, it...encourages bad programming practice.
For example.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
Why? That implies that those who do not know/use STL are lost. Can such a generalization be made?
Because I'm sure a LOT of people who use the MFC containers don't even know they are part of MFC. If I am used to using a language, and suddenly the part I try to use goes AWOL, I will be confused, and I'll need to find/learn an alternative. That's all I meant by 'lost'.
DavidCrow wrote:
Ok, but what if support for more than one compiler is not one of the requirements? Is that still a reason to use one over the other?
Yes, for the reasons I stated. Apart from the STL containers being *better*, they are also cross platform, you lose NOTHING by learning how to use them, and if you find yourself on a project that is on another platform, you'll already know how to use the containers there.
DavidCrow wrote:
For example.
It is bad practice IMO to tie yourself to a specific platform, which is not even universal in the Windows world, let alone the programming world at large, when the standard alternative is actually better. Microsoft did not intend for people to do this, either. Just like it's bad practice to pass char * around instead of using a string class, or FILE handles instead of a stream class, but people do it, because it's what they are used to, and they never stop to think of alternatives.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Do not use indexers to locate item in the list..
You can use Position..
Use the following code
POSITION Pos = str.list.GetHeadPosition();
while (Pos != NULL)
{
this->lst.AddTail(str.list.GetNext(pos));
}
" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "
- Words from Nelson Mandela
Thanks & Regards,
Gopalakrishnan
|
|
|
|
|
Hello,
I am trying to build a small directshow application as follows:
video-capture-source --> MPEG2 demultiplexer --> MainConcept MPEG Decoder --> video renderer.
This I have done successfully. However, now I just want to tap the output of the MPEG decoder (frame by frame without saving into hard disk) and do some post processing on these frames. Can anyone suggest me how to do this. mind you, that i dont want to save it on a hard disk using file writer, i just want to capture the output frame by frame -process each frame and provide a score or something like that as output.
Thanks,
Sashi.
|
|
|
|
|
I am now trying to compile a DICOM toolkit ( public domain ) that comes with a VS2003 project, but does not compile. The errors are all in linking, stuff like
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
Now: if I go to the project settings, the command line generated is this :
/Od /I "../../config\include" /I "../../dcmjpeg\include" /I "../../ofstd\include" /I "../../dcmdata\include" /I "../../dcmimgle\include" /I "../../dcmimage\include" /I "../../dcmjpeg\libijg8" /I "../../dcmjpeg\libijg12" /I "../../dcmjpeg\libijg16" /I "../../../zlib-1.2.1\include" /I "../../../tiff-3.6.1\include" /I "../../../libpng-1.2.5\include" /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_REENTRANT" /D "WITH_LIBPNG" /D "WITH_LIBTIFF" /D "WITH_ZLIB" /D "dcmmkdir_EXPORTS" /D "CMAKE_INTDIR=\"Debug\"" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /FD /EHsc /RTC1 /MTd /Fp".\Debug/dcmmkdir.pch" /Fo".\Debug\\" /Fd".\Debug\\" /W3 /nologo /c /Z7 /TP /errorReport:prompt
I think this bit: /D "CMAKE_INTDIR=\"Debug\"" is the problem, but I can't see where it's set, there are places that set the directory to build to be debug, but none have the trailing quote. Can anyone suggest how I fix this ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
Now: if I go to the project settings, the command line generated is this :
/Od /I "../../config\include" /I "../../dcmjpeg\include"
That's the command line for the compiler, not the linker
Christian Graus wrote:
I think this bit: /D "CMAKE_INTDIR=\"Debug\"" is the problem, but I can't see where it's set
It should be under C/C++ / Preprocessor / Preprocessor Definitions.
Christian Graus wrote:
there are places that set the directory to build to be debug, but none have the trailing quote
If you look at the Preprocessor Definitions you should find one saying
CMAKE_INTDIR=\"Debug\"
That is, with escaped quotes. When the definition is passed to the command line, it's in turn surrounded by quotes and appended after a /D option. So, the quotes (both escaped and normal) are properly balanced. I don't think that would be a problem.
I'd look at the linker command line
Christian Graus wrote:
Error 1 fatal error LNK1117: syntax error in option '' dcmmkdir
That's what you see in the "Error List" or "Task List" tab, right? If I interpret it right, dcmmkdir is just the name of the project in which the error occurred and not part of the error message itself, which is in another column. If I got it right, then, the actual error is saying there is a syntax error in option '' (note it's not a quote, but actually an empty option surrounded by single quotes)... That's odd...
Look at the wording in the Output window, which will show the exact output from the linker. Maybe that would shed some light and point you in the right direction.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Doh !!! I didn't have the output window visible.
This is what I get for one of them:
LINK : fatal error LNK1117: syntax error in option ''
Project : warning PRJ0018 : The following environment variables were not found:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)
I'm finding that the link extra commands is perhaps too long, I'm replacing it with explicit paths to any lib files it reports it needs, that seems to be going OK, so far.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
$(INT /LIBPATH:../../dcmimgle\$(INTDIR)
That looks like an incomple $(INTDIR) macro, which stands for Intermediate Directory. That macro is used for "Debug" or "Release" depending on the configuration you are building. It seems like since the macro got truncated (i.e.: $(INT instead of $(INTDIR) ), the linker kept looking for the closing parenthesis and interpreted all that (including the next libpath) as a macro, which then of course couldn't find.
Look for $(INT followed by a blank space in Linker / Command line / Additional options or in Linker / General / Additional Library Directories, and complete the macro. That should work.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I don't think any of these are mangled, I've been looking at them all day. It seems more likely that they are being truncated, because the list is so long. At least, some info I found on the web suggests this to be the case. I'm abandoning this list, and adding paths to the additional include directories for each file, which has worked for 2 of the 5 projects so far ( I've been sidetracked from doing the rest ).
Thanks for your help.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I was curious so I downloaded and opened this project with VS2005 (don't have VS2003 in this machine) and the options are definitively mangled.
There are around 270 options, most of which are duplicated (each libpath is repeated around 7 or 8 times). Besides that, I found:
3 cases of a single slash with nothing else. That would explain that LNK1117 with an empty option in your first post.
One option saying:
/LIBPATH:../../../zlib-1.2.1\lib\$(INT
and followed by:
/LIBPATH:../../dcmimgle\$(INTDIR)
That's the last error you post.
One option saying:
/LIBP
which is probably an error too.
One option saying:
/LIBPATH:../../../ti
which is probably a truncated version of
/LIBPATH:../../../tiff-3.6.1\lib\
One option saying:
/LIBPATH:../../d
which is probably a truncated version of
/LIBPATH:../../dcmdata\
or any of the other paths starting with 'd'
And many others that seem similarly truncated.
All these problems may be related to errors in the conversion from a VC6 project to VS2003/2005.
Did you use the CMake utility as indicated by the instructions in the Install file? If I understood it right, that's the proper way to convert it to VS2003.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
No, I found the instructions about CMake, but initially I just saw a VS2003 project and expected it to work. Why would they have a broken project file in there, I don't get it ?
Anyhow, I've nearly got it building, if I have more trouble with it, I'll go back to CMake. The reason for this is that this library links into the project that I've moved to VC2005, and I get a lot of basic_ostream linking errors on this library, so I need to be able to compile it to figure out the problem and fix it.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I've got a list control that I'm using for different profiles in my app. When I add a profile to the control it lists it correctly. However when I delete a profile I cannot get the control to move up the icons so that they are taking up the space. Is there a way to move the icons up without reloading the list control?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Tom Wright wrote:
Is there a way to move the icons up
I'm not sure if I got your question right, but maybe you are looking for this method:
CListCtrl::Arrange[^]
Or you might use the LVS_AUTOARRANGE style.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks that did it.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Hey all, Im having a problem with passing a var to a function via AfxBeginThread. It appears the function is being called properly, but my data, which is in the form of a pointer to one of my ServerData classes, appears corrupted in the eyes of the thread function (debugger shows data as it should be before call, inside thread function, everything is chaotic).
This is the code the starts the thread (triggered by a CListView message):
<br />
LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]); <br />
ServerData* sdat = (ServerData*)ptr;
<br />
CWinThread* thread = AfxBeginThread(&queryServer, ptr);<br />
This is performed at the begining of my thread func:
<br />
UINT queryServer(LPVOID pParam ){<br />
ServerData* server = ((ServerData*)pParam);
<br />
...<br />
}<br />
ServerData's LPVOID cast operator is simply defined as:
<br />
return this;<br />
Any ideas?
|
|
|
|
|
Hi KnaveD,
I would like to interpret the following your statement..
LPVOID ptr = (LPVOID)((ServerData)m_serversList[pNMIA->iItem]);
I can assume that m_serversList[pNMIA->iItem] returns the ServerData object from an array of m_serversList. If you look at your typecasting, it seems to be, it is returning a temporary object, which you are typecasting to a void. That object is not at all a pointer!!!!
Solution
---------
If I am not wrong, you can modify your code like this..
LPVOID ptr = (LPVOID)((ServerData*) &m_serversList[pNMIA->iItem]);
ie to get the address of the array element..
" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "
- Words from Nelson Mandela
Thanks & Regards,
Gopalakrishnan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
