Re: VS2005 major development bug

Andre Kaufmann wrote:
Edward Diener wrote:
Andre Kaufmann wrote:
Edward Diener wrote:
After spending more than a day reducing a complicated compiler bug to a simple case I reported it to the MSDN Product Feedback Center as a bug just now.

Which Bug, haven't found one in your example only an access exception ?

When and where ? Did you follow the instructions I gave in my bug report

I simply compiled your sample you've attached to a post in this thread and it crashed.

If you had used the project which was in the .zip file you would have seen that it was compiled with Managed C++ and not C++/CLI, and that it compiles fine.


? If you follow my bug report, when you step into the debugger and try to trace into "pimpl -> InitializeValidator();", which is line number 46 of ValidationEdit.cpp, you will see in the Disassembly window that it does not go to that routine but somewhere off of the WndProc routine instead. This od course causes an exception which is shown in the design window of the TestValidation project.

Exactly. I haven't debugged the sample into depth, but as I would interpret it the .NET runtime checks if the embedded class has access to the outer class, ValidationEdit and as it's forbidden to access private members from another class (friend declaration don't work also), it simply throws a security exception.

No in Managed C++.



[...]
----->>>>>>> System.FieldAccessException

No other exception is thrown when I run my code in the debugger except

Your application (attached to your newsgroup post) crashs, with a failure report stating that an uncaught system access exception has been thrown. It won't throw that exception if you make the class




To get detailed information by the compiler define your "pimpl" class outside the form. As I interpret the pimpl idiom, I would implement it in a CPP.

Please do not tell me how to program. The pimpl class is a nested class of my ref class so that it can access all of the members of my ref class
>

I only mentioned that IMHO a nested class is not the pimpl idiom I read about in Lakos book, but may be that there are different "pimpl" idioms. You may name the variable so, but may be somewhat confusing.

In normal C++ programming a pimpl class does not have to be a nested class because one can use the 'friend' declaration to allow the pimpl class to access all of the members of the other class if necessary. Because C++ .NET does not allow 'friend', the solution to this in Managed C++ was to make the pimpl class a nested class of the ref class and pass a pointer of the ref class to the pimpl class. However even the ability to have a pimpl nested native class of a ref class has been taken away in C++/CLI. That is not progress but regress. See my other post and the only solution I have found for this.



I notice that in C++/CLI it is no longer allowed for a native C++ class

It seems that this is also true (now ?) for managed cpp. Don't know if the compiler should rather throw a compile time error instead of runtime error.

The sample will also run if you don't access the member variable initializing directly, but use a public member method:

rClass->IsInitializing()

While I appreciate your workarounds, my actual code is far more complicated than my simple sample and the point of posting my bug was to have someone else ascertain that the bug actually exists on their machine also. This you did not do because you did not use the solutions/projects in my zip file. Instead you created your own solutions/projects, added my source file, then told me what you found. That is not the way to test someone else's bug.



to be a nested class of a ref class. Oh brother !!! How does a native C++ class which contains a good part of the actual functionality of a ref class now get to call and access protected and private members of its corresponding ref class in C++/CLI ?


> [...]


I hope I haven't again misinterpreted your posts again ......... you remember ...... ? Or done something wrong ?

I am not getting the exception you mentioned. Your line number is incorrect.

Sorry, must have been moved downwards, because I edited the code somewhat, checking the access restrictions.

the lines are:

32 private:
33 /// <summary>
34 /// Required designer variable.
35 /// </summary>

If you temporarily change line 32 into public the sample doesn't crash, at least on my computer / my IDE.

I know how to program and don't need to be told how to use the pimpl idiom. Other than that I do very much appreciate your help.

You have blamed me not knowing C++ very well too, some months ago.
I'll forget about that from now on, but I couldn't resist to make some notes about pimpl in my previous post.

And you are using still managed CPP, although you have made such a bad experience about it, regarding the loader lock. It hasn't directly something to do with managed CPP itself, but wouldn't it be better to port to C++/CLI ? Regarding the crash in your sample, C++/CLI seems to throw a compile time error, while managed cpp silently compiles, but seems to have the same restrictions (at runtime), as C++/CLI.

I am using Managed C++ because I had a ton of mixed-mode code I developed for VS2003 in C++, but never ran because of the loader-lock bug, and I first wanted to move that code to VS2005 and try to build and run it.

However because of this bug, and the assumption that MS will not be too interested in fixing bugs in Managed C++ code generation, I am forced to change my code to use C++/CLI immediately. Changing my sample to use C++/CLI I see that everything works perfectly.

For me this bug is the final chapter of the Managed C++ fiasco, including the destructive loader-lock bug in VS2003, other bugs I reported to MS regarding Managed C++ and VS2003, and now this horrendous bug with Managed C++ and VS2005. All in all a hideous example of computer programming by the VC++ team.

I am moving to C++/CLI and hopefully my efforts to use .NET programming with C++ will now be much better. It could not be worse than it is has been with Managed C++. I am truly sorry for Microsoft having put out such bad technology as Managed C++. They are usually a company that does not make such mistakes.
.

Relevant Pages

  • Re: top-level const-ness inhibits override
    ... compatibility switches for the EDG front end, since I'd be quite surprised if EDG had this bug in their ISO compliant mode. ... Comeau C++ compiles it fine. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Speed advantage of language written in itself?
    ... Bug source reduction: Once the implementation runs or compiles ... causing problems in yours. ... component of its own test suite. ...
    (comp.lang.lisp)
  • Re: VS2005 major development bug
    ... Which Bug, haven't found one in your example only an access exception? ... If you follow my bug report, when you step into the debugger and try to trace into "pimpl -> InitializeValidator;", which is line number 46 of ValidationEdit.cpp, you will see in the Disassembly window that it does not go to that routine but somewhere off of the WndProc routine instead. ... This od course causes an exception which is shown in the design window of the TestValidation project. ... The pimpl class is a nested class of my ref class so that it can access all of the members of my ref class when it is passed a ref class pointer. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: What makes a good C/C++ programmer?
    ... > it compiles and runs without complaint. ... > and the candidate is familiar with smart pointers, ... > because the programmer cannot depend upon the compiler or testing ... > we would expect that this bug would manifest itself eventually. ...
    (comp.lang.cpp)
  • Re: What makes a good C/C++ programmer?
    ... > it compiles and runs without complaint. ... > and the candidate is familiar with smart pointers, ... > because the programmer cannot depend upon the compiler or testing ... > we would expect that this bug would manifest itself eventually. ...
    (comp.lang.c)
Quantcast