|
The only error I've found so far in VS2022 is to do with text transformation on build. It works in VS2019, but crashes in VS2022... I've asked about this on StackOverflow but if I don't get an answer will also ask Microsoft.
Of course, I use several extensions and one minor annoyance is that either CodeMaid or Resharper (haven't tried to identify which yet) keeps wanting to change some of my namespaces to file scoped when I try to clean it up.
namespape xxx
{
....
}becomes
namespace xxx;
.... which, of course, breaks the code for VS2019!
There's probably a switch to turn it off if I had time to find it...
|
|
|
|
|
I am waiting for a few updates to by before I upgrade form VS 2019...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I like to obsessively check if there is any windows update...
And you know what? I got new Windows update 3 times since yesterday (when I installed Windows 11)! 
|
|
|
|
|
Did any of those updates restore the 'start' button? I am in the 'dark humor' mood.
Nick Polyak
|
|
|
|
|
What do you think?
You are right!
(I am a precog mind reader)
modified 16-Dec-21 8:46am.
|
|
|
|
|
So, I have this ancient VC6++ project. A very simple application that someone else wrote long ago. I want to convert it to VS2019. True to form, VS2019 alerts me that "this project is in an older format, it will need to be converted." I press okay. It converts. And it won't compile.
Enter precompiler directive hell...
As I'm plowing through all of my google searches, it occurs to me that I have *never* had a project convert and then compile. I would think that the clowns in Redmond would have figured this out by now. But noooo, this apparently has not occurred to them.
I have other rants for the west coast clowns, but I'll get my coat.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
You will be lucky if it fully complies to a version of the standard. If it is written in one of those "pre-alpha maybe it will be part of the standard" versions, adding to your "precompiler directive hell" comment, you have a potential nightmare project on your hands
And if you are running low on luck, it is written using a GUI library that is no longer maintained for ages 
Good luck and remember "it can not rain forever" 
|
|
|
|
|
It's very plain C++ and mfc, hence my rant.
I'm about to do a test. I'm going to create a Hello Clowns app - simple dialog nothing else but default clown code. I'll do it in VS2008, as VS6 is just asking too much. I'll pull it into 2019.
Anyone want to give me odds this isn't going to go well?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: Anyone want to give me odds
I don't even know how to guess those. I never used MFC. The only time (some 20 years ago) I had to do an application for Windows with a GUI, I used Borland C++ builder and their framework (can not recall the name).
Pardon my sarcasm but, I am sure Microsoft never released a version of MFC that was half baked and would brake functionality, turning a "plain" code into something not so simple.
So, how did the clowns behaved? Did they laughed with  or at  ?
|
|
|
|
|
I've done MFC twice in my life. Once as a student in VS6. And once professionally when to burn money left at the end of a contract - the (govt) customer didn't want the money back because it'd screw up their accounting - where I put a ribbon of lipstick on a pig so old it's port from C/Solaris to C with MFC gui (no actual C++ features were used) was done in VS97. I don't recall any issues getting the project running in VS2013.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
|
But it did stop... didn't it?! I don't go outside much these days 
Thank you for the interesting video. It made me smile the way he said it lasted a small period... of 2 million years.
|
|
|
|
|
Glad I could help.
I am sure you go out more than once in 2 million years!
|
|
|
|
|
I wouldn't know. I don't have enough fingers to count that high 
|
|
|
|
|
Fingers n toes. Then all you need is something to serve as bit 21.. 
|
|
|
|
|
Probably part of the reason is their compiler has gone through quite an evolution since then. I don't even think it's the same codebase - as in it has been rewritten at least once.
It used to be their compiler wasn't standard enough to implement the STL properly. That was in the bad old days of 6.
So bet on having to change your code in places. It's no so easy for an automagic tool to rewrite C++.
Real programmers use butterflies
|
|
|
|
|
That's because you're trying to convert a project written by a 1998 tool with a 2018 one. Precompiled headers management changed (luckily, as it was plain dumb in VC6) and mostly the standard changed, I had to add many casts when using floor and ceil because they are handled differently, otherwise it faild compilation.
Who knows if a project written for GCC 2.8.1 compiles with GCC 11.2 (and the accompanying libc versions).
Converting code is never, ever a click-boom task.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: Converting code is never, ever a click-boom task.
Good choice of words here. It probably does go "boom" in this case...
|
|
|
|
|
Having been on both sides of the fence multiple times my choice was not random at all.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I understand that compilers change. I know how to handle the source code issues.
My argument is that if Microsoft converts the project, there should be sufficient intelligence in the conversion process to ascertain what SDKs are on the machine, what tool is being used, and make some sort of attempt at setting up Microsoft's own definitions. What I get is some cryptic compiler error that seems to be obvious but difficult to resolve.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: there should be sufficient intelligence in the conversion process to ascertain what SDKs are on the machine, what tool is being used, and make some sort of attempt at setting up Microsoft's own definitions.
Whenever you translate code you don't change the original code, ever, this includes setting definitions that opaquely modify the code itself. This is a golden rule of each, any and every transcompiler. Jumping 20 years in technology cannot be automated, and that's true in all fields.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
charlieg wrote: My argument is that if Microsoft converts the project, there should be sufficient intelligence in the conversion process to ascertain what SDKs are on the machine, what tool is being used,
I'd love to see that working.
I've seen projects that were poorly documented, and new hires couldn't figure out how to build them. I don't see how any such thing could ever be automated.
Personally I think whenever a new project is started, there should be some sort of formal documentation that describes the system used, the tools used, their version number, any command that was run from a command prompt (if involved the configuration) and heck, even a copy of each tool's own installer, since you can't rely on a URL to remain valid across time.
|
|
|
|
|
charlieg wrote: I have *never* had a project convert and then compile
That just might be a step too far. I think there have been 9 major releases of Visual Studio since VC6: Visual Studio .NET 2003, and then Visual Studio 2005, 2008, 2010, 2013, 2015, 2017, 2019, and now 2022. Considering the phenomenal changes in the languages, runtimes, and operating system in that time, this devolves down to the dancing bear: you don't compliment him on the grace of his en pointe.
We just converted a large-ish code base (8 solutions, 30+ projects, C++/MFC and C#/WPF, several hundred source files totalling 3 million lines of code or so) from building with Visual Studio 2008 to Visual Studio 2019. Everything compiled and more-or-less ran. Two of us spent about a week cleaning up new warnings produced by improved compiler diagnostics, only one of which was genuinely annoying.
Software Zen: delete this;
|
|
|
|
|
Probably. I'd be okay with basic issues. But *Microsoft* is the one releasing this stuff, and it's like there is zero coordination going on. Hmmm, maybe instead of bitching I'll figure it all out and write an article. 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Well to wrap this issue up, I still am willing to call Microsoft clowns. This issue is just too easy to avoid. I'm sure I missed it in the documentation somewhere....
My original premise is that this was a VC6 application. Apparently, someone ported it years back to VS2015. So, not too old.
Anyway, MFC from the beginning (I'm going a long ways back, so I might be wrong), Microsoft's approach was to generate a stdafx.h and .cpp file that pulled in the MFC and Win32 definitions and what have you. If you were using something special for your application, you typically added it to stdafx.h.
Fast forward to sometime later (I don't know when MS decided to change the approach, I'd have to start downloading each VS to see how it behaved). Creating the dummy mfc app and staring at it for a while, I noticed there is no stdafx.* files. Instead, the newer versions of VS use a framework.h including a targetver.h - framework.h seems (I have a small test set admittedly) to be included in all of my application files. Within targetver.h, we include SDKDDKVer.h which is the magic file that fixes everything.
I would argue that the conversion report should include some sort of message about this.
Documented for posterity.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
