It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.
A visual history of Visual C++ (2017)
11–20 of 53 posts
Re: A visual history of Visual C++ (2017)
#12Earlier quoted context omitted.
After Visual C++ 6. They broke a lot of the C++ IDE features and they weren’t as good as the prior versions (dialog editor etc) so for a long time we preferred staying on 6. I think if we could have the newer compilers but the snappiness of that UI many developers would be happy. It’s also a product of the segmentation of the developer tools in Microsoft. The Windows team was responsible for the compiler rather than…
No, that's not really true. I was on the C++ compiler team from 1991 to 2006. When I first started, the DevTools team reported up through the Windows team, but never really felt a well-integrated part. We were never in the same building as the Windows team, for instance. I remember, probably 1992 or 1993, driving from building 4 where the compiler team lived to the Windows building (forget which one that was, maybe i…
Did you ever work on the cross edition that would compile Windows apps for the Mac? I think that was a version 4 fork that never got another version.
Re: A visual history of Visual C++ (2017)
#13One thing not mentioned is that Visual C++ and Visual Basic historically were separate IDEs with separate codebases. When the time came to unify them, only one of them could continue on. My understanding is that Visual Basic won, and that today's Visual Studio IDE (devenv.exe, msenv.dll, etc.) is the continuation of that VB codebase. I don't actually know in which release that transition happened. But since there's a…
After Visual C++ 6. They broke a lot of the C++ IDE features and they weren’t as good as the prior versions (dialog editor etc) so for a long time we preferred staying on 6. I think if we could have the newer compilers but the snappiness of that UI many developers would be happy. 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 big thing I missed was their macro editor, it was really good for automating things.
Re: A visual history of Visual C++ (2017)
#14Earlier quoted context omitted.
No, that's not really true. I was on the C++ compiler team from 1991 to 2006. When I first started, the DevTools team reported up through the Windows team, but never really felt a well-integrated part. We were never in the same building as the Windows team, for instance. I remember, probably 1992 or 1993, driving from building 4 where the compiler team lived to the Windows building (forget which one that was, maybe i…
Did you ever work on the cross edition that would compile Windows apps for the Mac? I think that was a version 4 fork that never got another version.
No, there were two devs working on the 68k Mac compiler, with ~10 devs on the x86 side (though both targets shared a lot of code and differed mainly in the late codegen and peephole optimization phases). I never worked on the 16-bit code; the 32-bit and later 64-bit x86 backend was a different codebase from the 16-bit stuff.
Re: A visual history of Visual C++ (2017)
#15It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.
I worked on that! I was a dev on the team that built the first IntelliSense engine for C++. It’s a miracle it worked at all. It was based on a hacked-up version of the C++ front-end, but when it inevitably hit errors attempting a single-pass parse of the current source, it would silently bull its way through and try not to get too screwed up. Doing that in the presence of templates was not a good time. But with the RAM and processing speeds available then, I’m still kind of shocked it worked at all, 28 years ago.
Re: A visual history of Visual C++ (2017)
#16The Windows 2000 era was really peak computing.
Re: A visual history of Visual C++ (2017)
#17Binders full of MSDN CD-ROMs...IYKYK
Re: A visual history of Visual C++ (2017)
#18You know what this doesn't show? 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. :-/
I remember a bug in an old Visual C++ that would fill your RAM and swap (therefore hard drive) if you forgot a semicolon at the end of a class, like:
class A { int a }
int main(...)
Re: A visual history of Visual C++ (2017)
#19It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.
I worked on that! I was a dev on the team that built the first IntelliSense engine for C++. It’s a miracle it worked at all. It was based on a hacked-up version of the C++ front-end, but when it inevitably hit errors attempting a single-pass parse of the current source, it would silently bull its way through and try not to get too screwed up. Doing that in the presence of templates was not a good time. But with the R…
nice documentation
Re: A visual history of Visual C++ (2017)
#20When / How did versioning enter versioning the awkward state we have today? There is cl.exe, MSBuild and build chain at the very least (now at work computer at the moment, pretty sure I am wrong with the making here) with versioning that is close enough to each other to be confusing and related to each other in word ways. Naming itself also feels confusing to me. Documentation also only helps when you already have a good idea what's going on.