|
Google before you ask Q
|
|
|
|
|
im doing data mining project on association rules based on apriori algorithm...can anyone help me out with the souce code.
several errors occured..."ecline in line is not permited" in config.h file.
-fear is not the factor-
|
|
|
|
|
http://en.wikipedia.org/wiki/Apriori_algorithm
http://web.syr.edu/~dxing/Files/DataMining/WebMining.pdf#search=%22apriori%20algorithm%20source%20code%20in%20vc%2B%2B%22
may be it will help u
|
|
|
|
|
Hey All,
I am having a problem getting an app that was written with VC8 on XP SP2 to run on a W2K (Windows 2000 v5.0.2195 with SP4) machine. The app is a unicode build and uses MFC and STL.
Because of the SxS distribution rules used by VC8 I had to jump several hoops before it stopped complaining about not being able to find it's DLLs.
First I upgraded the windows installer to version 3.1 using WindowsInstaller-KB893803-v2-x86.exe version 3.1.0.0
Then I installed the VC and MFC dll's using vcredist_x86.exe version 2.0.50727.42
Now as soon as I try to run the app it crashes with an access violation. Using the map file generated by VC8 the nearest I could figure is that it is crashing somewhere in the std::vector::erase method.
The thing is that I have been using the same app on my XP SP2 machine (the one with VS2005) with live data running 24/7 for several months now without any problems.
Is there an installation step I am missing? From what I have been able to decipher from the docs is that upgrading the windows installer and running vcredist_x86 is all the prerequisites needed to run VC8 MFC apps on older OSes.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
hmmm...
I tried another MFC8 app without STL and it ran no problem. Looks like the problem lies with the STL.
Now I have to figure out how to update the STL files on the machine. Back to doc diving
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: Looks like the problem lies with the STL.
Interesting, I have used the STL in an app compiled with VS 2005. I never had any problems with it crashing or misbehaving. The only issues I had where the updated MFC & C runtime dlls. Please do post your findings.
Thanks
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
S Douglas wrote: Please do post your findings.
The problem was not the STL. I was using a Win XP window class style (CS_DROPSHADOW) the W2K did not like.
|
|
|
|
|
PJ Arends wrote: Using the map file generated by VC8 the nearest I could figure is that it is crashing somewhere in the std::vector::erase method.
I assume you're using a map file to find where an exception is occurring in the source code on a release build. Although I've noticed that lots of people use this technique, it is totally unnecessary and the hard way to do things. In a debug build the information that enables the debugger to map from an address to a source line is the debug info, typically a .PDB file. Map files provide similar (but less) information in a human readable form. Just like a map file can be enabled for a release build, so can the debug information. When this is done you just debug as normal in the release build and there is no need to dig through a map file. Here’s the alterations I make in MSVC6:
- Select “Project->Settings”
- Select “Release” configuration.
- Select “C/C++” tab.
- In the “Category” combo select “General”.
- In the “Debug info” combo select “Program Database”. Note that in a debug build you’d select “Program Database for Edit and Continue”.
- Select the “Link” tab.
- Select “Debug” in the “Category” combo.
- Tick/select “Debug info”, “Microsoft format” & “Separate types” (same as in debug builds).
This is the first change I make when setting up a new project. If I made the IDE these would be the default settings.
Debug information is just as important for release builds, in some ways more so. If you receive crash dumps and have to do postmortem analysis they are invaluable. It’s best to use the symbol server (comes with WinDBG) to keep all your symbols safe and easily accessible.
Steve
|
|
|
|
|
You *could* turn this handy information into an article ya know... 
|
|
|
|
|
I want to draw a string (from a variable) with GDI+ so I'm trying to do this:
m_graphics->DrawString(m_ac, -1, &font, PointF(8,8), NULL, &grnbrush);
but the member m_ac is a std::string. How can I get it into the const
WCHAR* format for this call?
|
|
|
|
|
Stick^ wrote: How can I get it into the const
WCHAR* format for this call?
At a minimum:
m_graphics->DrawString(m_ac.c_str(), -1, &font, PointF(8,8), NULL, &grnbrush);
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Does that only work if the string is of type std::wstring?
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
The c_str() method is a member of both string and wstring. Is that what you are asking?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
No, I am verifying that even though he is using std::string (ANSI) instead of std::wstring (Unicode/Wide), he can still expect to get a const WCHAR* returned by std::string::c_str()? I am under the impression that he will get a const char* from std::string::c_str(), and a const WCHAR* (or const wchar_t*) from std::wstring::c_str().
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Because string.c_str() returns a char* is why I indicated it would need to be a minimum. A typecast would still need to be applied (to make it wide). I don't use the STL, but a better solution would be to use wstring instead.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
The const char* returned by c_str() is not a wide string, while casting it to WCHAR* will allow the code to compile, it will not work correctly.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: while casting it to WCHAR* will allow the code to compile, it will not work correctly.
From the context, I think he meant casting the entire string, and not the pointer.
--
Mr. Bender's Wardrobe by ROBOTANY 500
|
|
|
|
|
You mean to create a temporary, as in wstring( sTheString.c_str() )? I do not think that will work, either... Unless I am missing the intent of your smiley, that is.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Naw, more likely using CA2CW or something along those lines. My bet's on that David's a bit too experienced to fall for the (wchar_t*)str.c_str() and similar newbie mistakes.
|
|
|
|
|
James R. Twine wrote: The const char* returned by c_str() is not a wide string,...
So what exactly does std::wstring::c_str() return?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
std::wstring::c_str() returns a const WCHAR* (const wchar_t*), but not std::string:c_str(), which is what the OP was asking about.
I think that we (I?) are just getting confused about what "width" of string object is in use here. The OP is dealing with having a std::string (ANSI) object and needs to get a (presumably valid) const WCHAR* (Unicode) out of it.
Since they cannot simply change the strings from std::string to std::wstring, they are stuck with ANSI string objects, and no amount of casting is going to create a valid wide string from the return of std::string:c_str(). They need to call a conversion function (either directly or indirectly) in order to translate the string correctly.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: std::wstring::c_str() returns a const WCHAR* (const wchar_t*)...
Which is why I suggested it as a better solution here.
James R. Twine wrote: ...no amount of casting is going to create a valid wide string from the return of std::string:c_str().
Agreed.  Blunder on my part.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
ummm seems that would do the reverse of what I want. I want to go to a wide string from a cstr.
|
|
|
|
|
As I do not use the STL, I did not want to commit to a definite solution. That's why I prefaced it with, "At a minimum." From there you could have just cast it to a WCHAR*. A better solution is to use a wstring instead.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
MultiByteToWideChar(...) is the de-facto way to convert from ANSI to Unicode (Wide) strings, so you can look into that.
For something a little more Q&D, look into the (ATL) Conversion Macros like A2WC(...), T2WC(...), etc. Note that on VC++ 6.0, these macros use the _alloc(...) function (if a conversion is required) so you have to be careful using them directly in loops.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
