|
It is the same if you already have a pointer. But that class is usually created as
CMemDC pDC(dc); where you don't have a pointer.
The reason for the overload is that the class is used instead of the CDC* which is passed to the drawing functions. So you can modify existing code for the CDC* by just replacing the variable name without changing the access operator from -> to ..
Using such is bad practice but has been used by MFC too. It makes sense for this special class but should be generally avoided.
|
|
|
|
|
|
I think I can help but I am struggling with the grammar and intent of your question. -> operator gives you access to the class. It is much like operator .
|
|
|
|
|
I was reading this article, and I'm trying to understand a point that the author is trying to make.
Bartek's coding blog: Smart pointers gotchas[^]
class Test
{
public:
Test():m_value(0) { std::cout << "Test::Test" << std::endl; }
~Test() { std::cout << "Test::~Test destructor" << std::endl; }
int m_value;
};
typedef std::auto_ptr<test> TestAutoPtr;
typedef std::unique_ptr<test> TestUniquePtr;
typedef std::shared_ptr<test> TestSharedPtr;
void doSomethig(TestAutoPtr myPtr) {
myPtr->m_value = 11;
}
void AutoPtrTest() {
TestAutoPtr myTest(new Test());
doSomethig(myTest);
myTest->m_value = 10;
}
The author says this will crash. It seems that when myTest is instantiated, there is an auto_ptr object that now exists as a member of myTest, pointing to a heap instantiation of Test. Then when doSomethig() is called the *value* of the pointer is passed (i.e., the address of that heap Test object), and a new auto_ptr object, myPtr, is created, with its value set to the address of that Test object. And then after doSomethig() finishes, myPtr is destroyed, but since it is an auto_ptr, that destruction will delete the object that has the address of its value (i.e., the Test object). So, when a dereference of the myTest object (i.e., an auto_ptr object) is attempted, the Test object is no longer there, and hence an error that is as per trying to dereference an uninitialized (or perhaps null?) pointer.
Is my explanation accurate?
|
|
|
|
|
Close but not quite the actual rule goes
An auto_ptr owns the thing/object that it holds a pointer to, and only one auto_ptr may own an object at a time. When you copy an auto_ptr, you automatically transfer ownership from the source auto_ptr to the target auto_ptr. After the copy, only the target auto_ptr owns the pointer and will delete it in due time, while the source is set back to a null state and can no longer be used to refer to the owned object.
The line
doSomething(myTest);
has an implicit copy because you passed in myTest so the ownership goes into doSomething (passing like that is called an auto_ptr sink operation) and myTest gets the null state as per the description. You can't use it afterwards because it got nulled so it's a guaranteed crash if you try to use the pointer.
If you want the auto-pointer back again you should have made doSomething a function returning an auto_ptr and passed it back out, try something like
TestAutoPtr doSomethig(TestAutoPtr myPtr) {
myPtr->m_value = 11;
return myPtr;
}
The higher level code becomes
void AutoPtrTest() {
TestAutoPtr myTest(new Test());
myTest = doSomethig(myTest);
myTest->m_value = 10;
}
It's just an ownership thing .. only one scope of code can own an autoptr. If you want it back again you need to pass it back otherwise it is assumed it is no longer in use and cleaned up.
The actual crash has nothing to do with the cleanup the null of the auto_ptr is automatic when it copied and it's that which causes the crash. You are attributing the crash to the cleanup which isn't the case. If you could somehow keep the autoptr inside doSomething alive say with multitask code you still couldn't use the original pointer because it's value will be null.
Just use the debugger put a breakpoint on doSomething and single step into it and look at what happens to the original pointer .. your toast from that point on with the original code because it will go to null 
In vino veritas
modified 6-Jun-17 16:10pm.
|
|
|
|
|
|
Hi
I have been trying to build the assimp library (a open source library to load 3d models) using my visual c++ 2008 compiler and cmake. I read a number of websites, tried various methods, but nothing seems to work. I managed to get cmake to generate a workspace but compiling gives hundreds of errors. Anybody know how to build assimp under visual studio? Any help appriciated.
|
|
|
|
|
You first need to look at the compiler errors and figure out what is wrong in the build. Or go back to the source and see if there is any documentation that will help.
|
|
|
|
|
This'll probably do it:
https://github.com/assimp/assimp-net
Go there and download the AssimpNet.sln container called "assimp-net-master.zip". I looked at the assimp GITHUB project just now and noted a whole cockpit full of nonsensical info about CMAKE .. and roughly recall confusing CMAKE with some MS utility of a by-gone era using the suffix "MAKE" but I don't think this is a star in anybody's forest so don't bother reading further there.
Hope this helps.
|
|
|
|
|
Resolution: In the environment variables for include and lib there were three copies of one directory. That lead to the deletion of some other items. I suspect those three copies were the results of multiple upgrades and installs beginning with VS 2005.
Windows 7, visual Studio 2010, C++, MFC
I posted this on MDSD a week ago and have no replies. The essence is that definitions from within Visual Studio are showing up as being redefined. I do not have direct control over these and cannot find the indirect control / problem / defect that I have managed to insert in the code.
Here is the first of a long list of errors in the Output window
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinition
First, I cannot copy/paste from my working computer to my internet computer so please excuse any typos. If you see one, feel free to mention it as there may be an error, but please do not reject everything out of hand due to typos.
I searched for this problem and found several results, including an unanswered question from 2008 here:
https://social.msdn.microsoft.com/Forums/en-US/fb887af6-45dc-42b9-94bb-ab4d08a16dd8/64bit-compiler-error?forum=Vsexpressvc
It included advice to clean and rebuild. Following said advice I did a “Clean.” Then I closed Visual Studio entirely and ran a batch file I have named clean.bat that deletes 14 types of files in the solution directory and all subdirectories followed by a rebuild. A restart of VS and a build produces the same problem.
The titular error and similar errors are repeated numerous times.
Edit: to complete the title the entire error is (with a couple of CRs added for readibility:
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinition
Much further down in the error list is found:
… message_constants.h(50): error C2370: ‘NO_NAME_SPECIFIED’ : redefinition; different storage class
That particular file begins with
#pragma once
The constant is referenced one time only in the entire project, and that reference is within the same file.
So,…, I surmise that the #pragma once is not working. Maybe I did something to defeat it, I don’t know.
So, …, I added these lines to the start of the file, just below the pragma once
#ifndef MESSAGE_CONSTANTS
#define MESSAGE_CONSTANTS
… entire file contents …
#end if
Then, just to be certain, in every file that references this file I added these lines just above and below the include
#ifndef MESSAGE_CONSTANTS
#include message_constants.h
#endif
Question: What have I done wrong to incur such wrath upon myself?
Edit 2 hours after initial post
While trying to chase down this problem I discovered that the file name is really Message_Constants.h. When I chase down the error the file name at the top of the edit windows shows the name "message_constants.h" It also shows "Message_Constants.h" What is with the all lower case versus the leading caps?
I execute a Save As to ascertain the actual location and it is as expected. Open Windows explorer and it finds "Message_Constants.h and it does not find "message_constants.h" Now I have changed all occurrences to use the leading caps version but this problem remains.
Edit Again
I looked at file sourceannotations.h and found #pragma once. So I added the standard guard macros as presented earlier and they made no difference.
Monday, 22 May Edit
I added the /showIncludes options. Below is the lead in to the first error message. Again, I cannot cut paste so a few typos may be present. And just in case it might be significant: Where I wrote (indented here) means that that line was indented in my output window but this system is not showing an indentation.
Each line is prefixed with the two characters: 1>. None progress to 2>
Quote:
C1compile
All outputs are up-to-date.
stdafx.cpp
winocc.cpp
Note: including file: C:\Program Files Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\occimpl.h
Note: including file: C:\Program Files Microsoft Visual Studio 10.0\VC\atlmfc\include\atldbcli.h
Note: including file: C:\Program Files Microsoft Visual Studio v7.0A\include\oledberr.h
Note: including file: C:\Program Files Microsoft Visual Studio v7.0A\include\msdaguid.h
Note: including file: C:\Program Files Microsoft Visual Studio v7.0A\include\msdasc.h
Note: including file: C:\Program Files Microsoft Visual Studio 9.0\VC\include\sal.h
Note: including file: C:\Program Files Microsoft Visual Studio 9.0\VC\include\codeanalysis\sourceannotations.h
c:\program files\Microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(57): error c2011: 'vc_attributes::YesNoMaybe' : 'enum' type redefinition
(indented here) c:\program files\Microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(57) " see declaration of 'vc_attributes:: YesNoMaybe'
Thank you for your time
modified 22-May-17 17:55pm.
|
|
|
|
|
bkelly13 wrote: Question: What have I done wrong to incur such wrath upon myself?
You have been editing the compiler's files and altering the file names. If you don't understand the problem (and even if you do) then modifying these files is just crazy. You need to go backwards from the error message to try and find out where this enum is defined to cause the conflict. And the chances of it being some setting in the VC installation, rather than in your project, are extremely low.
|
|
|
|
|
1> winnocc.cpp
1>c:\program files\microsoft visual studio 9.0\vc\include\codeanalysis\
sourceannotations.h(57) error c2011:
'vc_attributes::YesNoMaybe' : 'enum' type redefinition Are you compiling the file winocc.cpp? That is a MFC source file that must not be compiled by applications (it is part of the MFC DLLs).
Regarding the file name cases:
Windows file names are not case sensitive. While the case is preserved by the file system, it is ignored when opening files.
As already mentioned by Richard:
Never change any of the system include files.
|
|
|
|
|
Hmmmm,
bkelly13 wrote: While trying to chase down this problem I discovered that the file name is really Message_Constants.h. When I chase down the error the file name at the top of the edit windows shows the name "message_constants.h" It also shows "Message_Constants.h" What is with the all lower case versus the leading caps?
I execute a Save As to ascertain the actual location and it is as expected. Open Windows explorer and it finds "Message_Constants.h and it does not find "message_constants.h" Now I have changed all occurrences to use the leading caps version but this problem remains.
Why on earth are you editing those header files? It technically should not matter if headers use "message_constants.h" or "Message_Constants.h" unless you have modified the OS group policy that enforces case sensitivity[^]. File a bug if this is an issue for your organization.
Learn to use the tools you are given. You should be using the /showIncludes (List Include Files)[^] option for debugging nested include bugs.
How to: View, Save, and Configure Build Log Files[^]
Enable 'Diagnostic' verbose logging. Search that log for message_constants.h and you should quickly find the offending file.
Career Advice: You should always avoid #including headers from headers... from other nested headers.
Yes, this means you may need to add #include "your_header.h" in 50 different CPP files.
Best Wishes,
-David Delaune
|
|
|
|
|
Three people have posted and chewed me out for editing the Visual Studio files.
Still, as I perceived this thread, the core problem has been ignored.
I had a project that compiled an ran and started getting errors where it should not. Why might I get YesNoMaybe redefined?
If the code that has that is prefixed with #pragma once, why might Visual Studio re-read that file that is knows is has already read, then declare the item redefined. The error appears, from my perspective, to be a failure of #pragma once to not do fulfill its intended purpose.
I will be adding option /showIncludes and see if I can derive any information from that.
Just as a side comment, these kinds of problems would probably be much easier to deal with if I could find anyone else around here that uses Visual Studio.
Edit: I edited more information into my original post at the bottom.
Thank you for your time
modified 22-May-17 10:23am.
|
|
|
|
|
Hi,
Aren't you an experienced C/C++ software engineer? I have seen you on this forum for many years... how can you get this wrong? The answer you are looking for is located in your edited original message above:
bkelly13 wrote:
c:\program files\Microsoft visual studio 9.0\vc\include\codeanalysis\sourceannotations.h(57): error c2011: 'vc_attributes::YesNoMaybe' : 'enum' type redefinition
(indented here) c:\program files\Microsoft visual studio 10.0\vc\include\codeanalysis\sourceannotations.h(57) " see declaration of 'vc_attributes:: YesNoMaybe'
Your project is pulling in the sourceannotations.h header from both VS2008 and VS2010.
Fix your project #include paths.
Best Wishes,
-David Delaune
|
|
|
|
|
David,
Yes, I have been here for maybe 15 years. I have never had a good opportunity to work with anyone that knows Visual Studio itself well. I have written some rather good code, but have not and do not know how to use VS to its best advantage.
Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
On to this problem.
Now that you guys have egged me on a bit, a very good thing, I discovered:
Click on start, computer, properties, Advanced system settings, Environment Variables.
Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib"
I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
I do thank each of you for the time you took to reply.
Thank you for your time
|
|
|
|
|
bkelly13 wrote: Side question: Do you have a good reference I can read or purchase about using Visual Studio itself. Maybe something to help me make a little progress in being a "Visual Studio power user" (for lack of a better term.
I have no idea... I have not read a Visual Studio manual since ~1994 back when I was using Visual C++ 1.0. Here is a screenshot[^]. I keep it installed in a VM running Windows XP for nostalgic reasons.
Unfortunately my technique for becoming a "Visual Studio Power User" is to spend 20+ years of my life in the IDE almost daily.. including many weekends.
bkelly13 wrote: Now that you guys have egged me on a bit, a very good thing, I discovered:
Click on start, computer, properties, Advanced system settings, Environment Variables.
Under System variables there is an entry for include and lib. Both of them had three copies of the line that goes something like: C:\Program Files\...\v7.0A\... All three exactly the same. Three in "include" and three in "lib"
I have never messed around here and I surmise (careful choice of words here) that this is an artifact of installing multiple versions of VS, one after another, since VS 2005. As of just now, I have messed around here and I deleted two versions of the line and some of my problems were resolved.
I believe the older versions of Visual Studio had an option in the Installation Wizard to "Set Environment variables for LIB, INCLUDE and PATH" so that you could compile code from a command prompt. I would recommend removing them... you can always use the Visual Studio command prompt and allow \VC\bin\vcvars[*].bat to set the environment variables.
bkelly13 wrote: Now I am back to an older problem where it cannot find occimpl.h. Having learned this,I might be able to fix that problem tomorrow. For local reasons, Must call it a day for today.
That one is located in the MFC source folder.
\VC\atlmfc\src\mfc
It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE.
Best Wishes,
-David Delaune
|
|
|
|
|
David,
Re: Quote: It is somewhat unusual that you need to pull this file into your project... it means that your project may be extending MFC functionality relating to OLE.
I am not intentionally doing anything with OLE. I can google and see that it means Object Linking and Embedding but in this app I barely use the user dialog. I did get rid of something and now when I capture the Output windows that file is no longer there. I now get a successful build.
We are working on moving up to VS 2015 and having similar problems with it on another computer. Now is a good time to perform a bunch of searches and get rid of any detritus that has accumulated over the years.
Thank you for your time
|
|
|
|
|
There is no point going to VS2015 it's obsolete you need to go straight to VS2017. It will import and adjust most solution files automatically and is fairly reliable at it. It also has all the MFC code source files because MFC is no longer sold or directly supported by Microsoft as it has been replaced.
VS2017 is also free for individual or small companies under it's community edition which is identical to the full product save it excludes direct support and the team workspace and code share options are disabled.
The only time you now need earlier versions of VS is if you need to have code for Windows O/S earlier than XP. Every Windows O/S from XP onwards can be targetted by VS2017 as well as Android, iOS Mac, Unity3D, Linux Command line and some new ARM mobile phone stuff.
I have uninstalled all my earlier versions of Visual Studio there is no situation I have found they are ever required.
In vino veritas
modified 23-May-17 2:05am.
|
|
|
|
|
leon de boer wrote: MFC is no longer sold or directly supported by Microsoft as it has been replaced.
When did that happen?! 
What replaced it?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
.NET is Microsoft replacement framework if you open VS2015 or VS2017 it's everywhere in the templates at the top of the project settings.
I quote from May Wang at Microsoft in 2015: "MFC is limited to Windows desktop apps, and you cannot currently develop "Modern" or "Universal" apps that target the Windows Store, phone devices (including Windows, Android, and iPhone), MFC is not slated for any investment at this time."
They then went on to release the sourcecode even in the free community edition of Visual Studio which was there equivalent of saying up to you to support it yourself going forward if you want to use it. The code itself no longer has any commercial value to MS.
That is pretty much by the book end of life cycle for software development 
In vino veritas
|
|
|
|
|
Thanks. I agree with what you've said, but what replaced it as far as building native desktop applications?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: I agree with what you've said, but what replaced it as far as building native desktop applications?
MFC is actively maintained for Desktop development. The latest version MFC 14.10.25008.0 was released back in March 2017.
Of course everyone is encouraged to move towards adopting the modern Universal Windows Platform.
Best Wishes,
-David Delaune
|
|
|
|
|
MFC14 is from VS2015 it only supports .Net 4.6 and later .NET 4.6.1
They patched a few dropdeads in it for the release of VS2017 so it supports .NET 4.6.2.
The history is clearly covered in Wikipedia if you need to reference:
Microsoft Foundation Class Library - Wikipedia[^]
You will note the major revision revision number has not changed from VS2015 to VS2017 on those releases unlike earlier situation and that is a direct consequence of no further development.
As we speak right now MFC is currently broken again under .NET 4.6.2 on Windows 10 after the anniversary update is applied and now .NET 4.7 has been released. It's been like that for months so lets see how long it takes them to fix and support 4.7 as an indication of the support for MFC. Note VS2017 auto updated and downloaded WPF changes so it was compatible with .4.7 basically two days after .NET 4.7 update was released and it made it into the advertising blurb (Announcing the .NET Framework 4.7 | .NET Blog[^])
In vino veritas
modified 30-May-17 0:41am.
|
|
|
|
|
If you mean what does Microsoft marketing want you to use to program desktop apps then the answer is C# with .Net that was the whole push with VS2017 you actually have to select to install C++ as an option with VS2017. I don't know how successful they were with it, there was considerable pushback at them over the C++ issue.
As a fulltime commercial programmer I have always programmed on the Windows API so it all means little to me because I would never waste my time supporting any of the frameworks they all come and go. Once you have you own library sets there is little attraction in any of the framework groups. So I really want nothing more than a functional C++ compiler with a good IDE and debugger which VS2017 has in spades.
I probably represent the problem for MS compiler marketing that they need to sell me something and there is very little I need from them
Anyhow here is the Desktop Marketing blurb for C++ from VS2017 make of it what you will (but notice it's an option not the default install as is MFC within that)
Windows desktop development with C++ in Visual Studio | Visual C++ Team Blog[^]
I suspect somewhere down the track customers like me will end up using just the IDE with a linked compiler module. MS has an interesting community IDE called confusingly Visual Studio Code
Visual Studio Code - Code Editing. Redefined[^]
MS finally added C++ to Visual Studio Code compiling options late last year but it has several drawbacks to VS2017. The intellisense on it is not as developed as VS2017 and the compiler technology is very different and the code produced is not as efficient as VS2017.
It's also worth looking at the backdrop to the c++ compiler at MS which now stands apart from Visual Studio itself
Rejuvenating the Microsoft C/C++ Compiler | Visual C++ Team Blog[^]
In vino veritas
modified 30-May-17 1:32am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
