I have a regular DLL that uses MFC statically linked.
When I try to export a function with a c-style unmangled name, the DLL ends up being built with a mangled name for the function.
The function I'm exporting is defined as follows:
_declspec(dllexport) _LaunchProcess __stdcall Start(LPCLIENT32STARTUPCONTEXT StartupContext)
// _LaunchProcess is a function pointer typedef, and LaunchProcess is a function definition.
When I build the DLL, the function ends up named "_Start@4" instead of just "Start". Does anyone know how I can force it to export the function as "Start"?
The difficult we do right away...
...the impossible takes slightly longer.
Here is the excerpt from the documentation - dllexport of a function exposes the function with its decorated name. For C++ functions, this includes name mangling. For C functions or functions that are declared as extern "C", this includes platform-specific decoration that's based on the calling convention. If you don't want name decoration, use a .def file (EXPORTS keyword).
Here is the result of what I tried with dllexport -
I need some quick help on how to make the tree control's background as transparent.
I could achieve similar for setting the dialogbox (CDialog) as transparent.
I have researched alot on this but could-not find a working solution.
Erasebackground,OnCtlColor but they have not worked for the tree control.
Attached is a sample project where this tree control is attached.Expect tree control and the button's I am able to set the transparent dialog as shown in attached snapshot.
I did a very lengthy evaluation of static analysis tools at my last job. In summary, cppcheck is pretty good and since it's free, why not. Of the paid tools, PVS-Studio was one of the best and very reasonably priced (not any more!) and rather expensive, but not as much as other tools (Unfortunately, instead of just listing a price, they play games with you, which means I really can't recommend them anymore--any company too chickenshit to put up plain prices doesn't deserve my business.) Of the super-expensive tools, the best, by a huge margin, was Coverity. It found almost all of the known issues, several critical issues none of the other tools found and almost three dozen minor issues. They are expensive, but worlds better than Klocwork and Parasoft.
Parasoft was pretty bad--their analysis tool did better than Klocwork, but missed several issues cppcheck caught and missed several known critical errors. Their product is excruciating slow and Parasoft's other tools were a disaster--several wouldn't even run. Klocwork was very buggy, missed several known bugs and their support was offensively useless (the evaluation went so badly that we terminated it early.)
One thing I concluded is that Parasoft and Klocwork specialize in selling to companies which must comply with weird rules for government work (for which there are hundreds of rules, like how switch statements must operate.) They do well at that, but not so well in finding actual bugs.
(Riverblade Software which makes Visual Lint, a tool which helps you deal with PC-Lint and Cppcheck--I don't much like it, but you may.)
Interesting you mentioned Parasoft: a couple of years ago (at a time when it was still relatively cheap) I chose it over lots of others based on a comparison report (which I unfortunately cannot locate any more). Back then it was indicated to be one of the best tools available for the Windows platform (the best affordable one at least), and indeed we got very good results.
That said, like what you stated about PVS, they don't openly state their prices, and now they're much more expensive than they used to be. Unfortunately this seems to be common practice for software tool makers nowadays Good thing there is open source! But still a pain when you really need to find the best tool for the job and end up wasting hours with inquiries only to find out the price tags are way beyond sanity!
Note however that Parasoft does instrument code for runtime analysis too, and we could uncover a number of very nasty memory leaks and bugs that we wouldn't have found in years without a tool, and not at all with static analysis alone! It's true they're not really great at static analysis, but that was never our main concern to start with!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Last Visit: 31-Dec-99 18:00 Last Update: 22-Sep-18 0:42