|
#Worldle #629 3/6 (100%)
🟩🟩🟩🟩⬜⬇️
🟩🟩🟩🟩🟨⬇️
🟩🟩🟩🟩🟩🎉
https://worldle.teuteuf.fr
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Four go in the furnace, but kiss and make up (7)
|
|
|
|
|
|
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Yes indeed. You're up tomorrow!
|
|
|
|
|
Oh dear, oh dear! What did I get myself into
Mircea
|
|
|
|
|
General context - nothing new but we get an assortment of rants on the Lounge about the latest debacle update from MS. For the life of me, I can't find the latest rant... I'm looking for the least pain to experience
I have to lift VC6++ code from 20 years ago to .. well today. I know from VC6++ to today we have compiler improvements as well as the IDE. I'm okay with the compiler enhancements, I'll pound through that. But I really don't want to go out to the tip of MS's latest release to help them debug.
Avoiding Visual Studio 2022 version 17.7.5 - the tip, is there any earlier version that would be more stable? I've worked with 2015 and 17 a little.
Advice?
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.
|
|
|
|
|
We have a number of products we still maintain using Visual Studio 2008. We have a new product being developed using VS2019, which we will probably move to VS2022 in the near future.
I do have a suggestion. Given the age of your code, I recommend using the New Project wizard in whatever version you decide to use to create the initial project(s) in the solution for your application. Import your current source one piece at a time, cleaning up issues as you go. As you move through the process this will go faster as you learn the patterns in the old code that need changed. This approach is a lot less painful than going through an upgrade process all at once (VC6 to VS2008 to VS2019 is one path I've tried).
Software Zen: delete this;
|
|
|
|
|
Suggestion noted. I've done this in the past, but mainly involving CE to wec7 which forced us to go from EVC++ (yeah THAT old) to VS2008. 2008 has been pretty good, but it still has some evil in it. I'll start with 2019 and see how it goes.
Thanks
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.
|
|
|
|
|
I think VS2022 is noticeably better than 2019, specially Intellisense. Compiler is the same or very similar. I went from VS2019 to 2022 last year and never looked back.
Mircea
|
|
|
|
|
Hmm, okay. Maybe I can find the rant about MS screwing up the latest then.
It's not a big issue, I make a snapshot of my VM and if it goes sideways I revert. Appreciate the feedback.
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.
|
|
|
|
|
when I used Visual Studio 2019 to open a VC++6.0 project, after convert the project I compiled it. most warnings are related with project parameters settings and macro definitions.
After fix these items, my projects are compiled successfully.
diligent hands rule....
|
|
|
|
|
Truth, and thank you
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.
|
|
|
|
|
I had much worse luck, but then my code made extensive use of The STL at the time.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
STL and Microsoft was always a bad idea....
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.
|
|
|
|
|
Frankly, C++ is kind of not C++ without the STL and I say that as someone who uses C++ without the STL on the regular (but for embedded)
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
well, I wish I had better news.... read the last post in the list....
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: I've worked with 2015 and 17 a little.
Probably not a good idea to even consider those. You are looking at end of life for both of those. So minimum would be 2019.
Although you are correct you might run into problems that originate from the IDE/compiler that is going to be true regardless. And the larger and more complex the code base the more likely that is.
Myself I would go with VS 2022 for the following reasons.
1. It has not just been released. So not like you are working on version 1.0
2. It is '2022'. And it is likely that MS will release a 2024 and probably definitely a 2025 otherwise. And you don't want to do a major upgrade and then be behind immediately after you are done.
|
|
|
|
|
I have ranted previously about their releases being buggy. The last several have been good and I have seen no issues. I have almost one hundred projects that I maintain and all built and ran well with newest release. I would not hesitate to install the 17.7.5 release.
The only issue I have had lately is some of my settings got messed up so it helpful to export your settings first so you can restore them later. This is only an issue with updates though - not new installations.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick - I think your latest rant was what triggered me.
I'll start with the latest and see where it goes from there. I am 75/25 overthinking it. If the compiler goes tits up, there will be more $itching than just UI issues.
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.
|
|
|
|
|
I tend to agree with you about your overthinking. It's been a while since I have run into an actual compiler bug. These days I run into mostly UI headaches.
I have been where you are and had to move forward several compiler revs and I went about porting all my stuff to be 64-bit programs and libraries. It was pretty easily actually - it almost exclusively involved changing data types. For example, standard windows procedures and timers changed to the INT_PTR type. If you go down that path I recommend using warning level 4 so it shows you all of the issues. It's a bit anal retentive about some things but they are easy enough to correct.
BTW - one other advantage to the latest generation is Visual Studio is now a real, live 64-bit program so that means it can handle really big programs and tons of data. Until late last year, I think it was, it was a 32-bit program so it had all of the standard limitations and they had to do some real hacks to make it overcome them.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Nothing to add, except to say that I value responsiveness and stability of the IDE over 'new and shiny'. That said, I have 5 different versions of VS on my current system:
0: VS6
1: VS 2008 (only for the migration tool)
2: VS 2010 (my favorite for so many years)
3: VS 2017 (now the one I use most often)
4: VS 2019 (hardly ever use this one)
Which one I use (apart from VS6) depends on the .NET Framework a project targets. I still prefer VS 2010 for projects <= 4.5 as it seems to have less bloat and does everything quicker than later version. (startup/compile/debug)
I haven't tried VS 2022 yet as I've got too many other versions hogging space and don't currently have the room for it. When people quit ranting about it, maybe I'll give it a go.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
I think most of your problem will come from porting your code TBH. MSVC 6 was not compliant. In fact, it was abysmal. Then at least as I recall, Herb Sutter joined them and straightened them out compiler-wise, but because of that, it breaks old code.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
YUP....
Last time I did that I started a new project from scratch using JetBrains CLion, then just ported the c/h/cpp files across one at a time with relatively few changes.
I now ONLY use VS these days for the few things that none of the JetBrains tools do very well (Mostly WinForms & the designer, or automated access to Azure)
I got utterly fed up of the changing versions, and the bugs and idiotic faults that came with them, 3 years ago now... changed to the JB toolset, never looked back, cheaper per year too and for far more tools than I got with VS.
VS as a paid subscription was useful back when you got things like an MSDN subscription with it, but now... sorry... I have better things to use my time on.
|
|
|
|
|
So, after dealing with multiple estate issues, hawks going after my chickens, staging VMs and moving them to the new laptop, late Sunday night east coast USA, I decided to give the old 2022 convert this old project a try.
Gave me a few warnings - no concern, seen this before. I now have a new project in 2022 format with 0 files in the solution. Hmmm.
Time to try one of the suggestions from before - create an empty project and move the files into it.
Fun times. Looking at the source code, lots of 'add item to the list" but zero high level comments as to what the general thought process it. Fun times.
<spelling correction.
<div="" class="signature">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.
modified 16-Oct-23 5:49am.
|
|
|
|