visual assist x worked better.
But with a focus more on C++ features.
I started with Visual C++ 1.0. There were no templates.
Visual C++ 2.0 had templates.
There was by Visual C++ 3.0. They went to 4.0 to sync the MFC (Microsoft Foundation Classes) versions.
IIRC, you could use a bit of STL with 4.0
Visual C++ 5.0 was mainly optimizer differences.
Visual C++ 6.0 was actually pretty good. However it lacked partial template specialization. I was a Boost author at the time and lots of Boost code had specific workarounds for Visual C++ 6.
Visual C++ 2002 also had no partial template specialization.
Visual C++ 2003 was the first version with partial template specialization and that could compile all of Boost.
Visual C++ 2005 and 2008 did not have much changes.
Visual C++ 2010 tried to get back to 6 in the IDE (there was a deliberate marketing as such). It also had some C++11 features. But no variadic templates.
Visual C++ 2012 had no variadic templates.
Visual C++ 2013 was the first with variadic templates.
Nowadays, Visual C++’is doing much better tracking the C++ standard and often has compiler and library features before clang and GCC.
C++/CLI could have been it (after the Managed C++ reboot), but its integration with Windows Forms has always been clunky, nevermind WPF.
Then C++/CX could have been it, but then there was this rebellion replacing it with C++/WinRT, nowadays in maintenance, only getting bug fixes, being good enough for WinUI 2.0 and WinAppSDK low level stuff and that is about it.
I was big into Borland from their early MS-DOS compilers, all the way into 1999.
Embarcadero might not be Borland, but still manages to put out great GUI RAD tooling, whereas Microsoft lost sight of what means a great developer experience for native applications.
I don't actually know in which release that transition happened. But since there's a screenshot of each version in the article, presumably that transition is visually documented...
This transition was not great for Visual Basic developers either since their language was transitioned from generating native code (VB6) to becoming dependent upon the .NET Framework (VB.NET), supported secondarily to C#.
Quite awkward for what is such a key technology on Windows.
n.b. I worked on the Visual Studio Core team, which maintained devenv.exe, among other things, from 2003-2007'ish.
It’s also a product of the segmentation of the developer tools in Microsoft. The Windows team was responsible for the compiler rather than the Developer Tools team.
Don't remember when DevTools was re-orged out from under Windows, but I'm pretty sure it was by '95, and well before VC++ 6.
Visual C++ v4.2b generating an assignment operator which invoked the destructor of a returned object before assigning it to the lval.
That was fun to figure out. :-/
class A { int a }
int main(...)
Hard reboot left it doa. With today’s tools it could have been recovered but I lacked gparted and a kali thumb stick to bring it back. So thankful for Linux.
I had dabbled in both QuickBASIC and Quick C on MS-DOS building very simple text games and such. When Visual Basic for Windows came out, I was ten years old. It was a revelation because it let me build something that felt like real software. Place controls on a canvas and start wiring them up with event handlers — so easy!
When Visual C++ was announced, I figured it would be the next step up. I had already learned some simple C, so probably it’s just like Visual Basic but you use an improved C for your event handlers? I harangued my dad to “borrow” a copy from his work, and sat down with the Hello World… Which was an incomprehensible 300 lines of Win32 message handlers and Hungarian notation variable names. Nothing “Visual” about it.
It did give me an appreciation for just how much work the Visual Basic team had done to hide the ugly guts of GUI programming.
- -
[1] I had a very easy childhood by most standards.
It was a revelation for me on the power of OOD/OOP in practice and a defining educational moment on Software Design, Frameworks and Libraries.
Lets also add MFC was born as Application Framework, and dumbed down because hardcore Win16/Win32 C folks at Microsoft were against its original design.
The multiple confusing version numbers are caused by each software component (e.g. "cl.exe" vs "msbuild.exe" vs IDE "devenv.exe" vs platform toolkit SDK) evolving separately over decades. (https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Inter...)
E.g. Today's "cl.exe" at version 19.x goes all the way back to 1983 with Microsoft C 1.0 for MS-DOS. Just a text-based command line compiler with no C++, no GUI, no "Studio", etc. 43 years of the core compiler going from 1.x to 19.x. The Visual IDE component of VC++ version 17.x has a different version history going back to 1993 with 1.0. Microsoft C# also has different version numbers of C# language version vs .NET version vs CLR version, etc.
It's analogous to Linux world of different tools with different version numbers. GCC is 15.x, glibc is 2.4, make is 4.4, etc. If you include a "visual GUI IDE" like Jetbrains CLion, that's yet another different version (252.x) that doesn't match any of the others.
Microsoft could hypothetically "synchronize/unify" all version numbers for all disparate products to be a single number ... akin to Apple using version "26" to synchronize Xcode with iOS, etc by introducing large numerical gaps like v18 --> v26. That's probably not going to happen. Likewise, different groups at GNU are not going to agree to synchronize all version numbers such that next release will be GCC 20.0, glibc 20.0, and make 20.0.
To this day, I experience a very brief spasm of regret when I just exit Visual Studio without closing the solution first.