Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A visual history of Visual C++ (2017)

malsmith.net

Post reply on HN
Print view View original

31–40 of 53 posts

Re: A visual history of Visual C++ (2017)

#31

Post by pavlov »

The “Visual” in this product’s name was one of the greatest disappointments of my childhood. [1]

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.

Re: A visual history of Visual C++ (2017)

#33

Post by reactordev »

Disposal8433 wrote: post #18
AdieuToLogic wrote: post #9

You 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(...) To fix that, you had to kill the compiler process.

I lost a game prototype to that bug as it crashed my HDD at the same time by writing swap over swap. Screwing up the S.M.A.R.T. page.

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.

Re: A visual history of Visual C++ (2017)

#34

Post by keithnz »

philiplu wrote: post #15
keithnz wrote: post #11

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.

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…

Oh, very cool! It was like magic when we got that!

Re: A visual history of Visual C++ (2017)

#35

Post by pjmlp »

zerr wrote: post #26

(Not so) funny that there was nothing "visual" in Visual C++. The dialog resource editor was a joke. I remember how I was relieved when I discovered Borland C++Builder, so I didn't have to switch to Delphi for Windows software development.

Even worse, to this day, Microsoft has completely failed to produce anything comparable to C++ Builder due to the internal feuds around C++ and COM.

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.

Re: A visual history of Visual C++ (2017)

#37

Post by jbandela1 »

Brings back memories.

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.

Re: A visual history of Visual C++ (2017)

#38

Post by rramadass »

pavlov wrote: post #31

The “Visual” in this product’s name was one of the greatest disappointments of my childhood. [1] 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…

Nobody who had not done Win16/32 SDK C programming ala Charles Petzold can ever understand what a paradigm shift in programming that Visual C++ with MFC was. I still remember having my boss get the Visual C++ software (around 1995/1996 ?) along with David Kruglinski's two-volume books on programming it, following the tutorial clicking through wizards and being gobsmacked at getting a full-blown ready-to-go app with much of the hard-work done for you in seconds. We rewrote our Win16/32 C app in VC++/MFC and it took us only a few months rather than years.

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.

Re: A visual history of Visual C++ (2017)

#39

Post by twen_ty »

zerr wrote: post #25
philiplu wrote: post #15

Earlier quoted context omitted.

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…

No offense but the first thing I used to do after MSVC installation was the installation of Visual Assist :)

Oh man Visual Assist. Was it whole tomato software or something like that? It was amazing back in the day!

Re: A visual history of Visual C++ (2017)

#40

Post by ack_complete »

zerr wrote: post #27
ack_complete wrote: post #8

Earlier quoted context omitted.

The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still brok…

Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.

No, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it:

> The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows.

https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...

The WS_CLIPSIBLINGS window style is also explicitly for controlling cross-clipping of child windows during painting:

> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.

https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...

Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.

Post reply on HN