Best approach to learn C++ coming from VB .net

[Bicurico]

Hi,

I use VB .net for quite some time. Before that I used Qbasic, BASIC on the C64 and Amiga, etc. On the C64 I did learn how to program assembly on the 6510.

Over the years I glanced at TurboPascal and Turbo C, but never really got to use them, as they were essentially compilers for DOS and Windows95 was already a thing.

I tried a few times to learn C++, but the truth is that I always failed in doing so. The books I tried to follow only focus on console applications and try to explain concepts with databases examples, which do not interest me that much.

C# never motivated me, as I can get the same end-result using VB .net.

One of the problems I always had with C++ is that C++ as a language is one thing, VC++ including GUI and Windows API is another!

It seems quite overwhealming for the occasional programmer to get into Windows API and building a simple form with a button that shows a "Hello World!" message box is much less trivial than doing the same with VB .net.

However, I have come to a point, where the development of scripts/applets/macros/post-processor for CAD/CAM software is not done in some internal language and/or .net, but rather in Python or C++ (for example Fusion 360).

I think that I must learn C++ at this point, so my question is: what would be the best approach?

Should I first learn C on a console and then learn C++ on top of it?
Should I immediatly go for C++ on a console?
Since I am going to learn C++, why not learn VC++ and be able to develop complete stand-alone applications, too?

Another frustration I have is that I would like to use given DLL's. Under VB .net I was never able to include them in my projects, as you can only do that with DLL's which were build with .net themselfes. Otherwise you need a wrapper, but that never worked with the DLL's I wanted to use.

Finally, coming from the CAD/CAM world, I would like to learn how to do OpenGL and DirectX, but I fear I am not smart enough to handle these.

So, here is the question again: how should I start the learning process?

Ideally I want to be able to develop VC++ applications in the end.

Thanks,
Vitor

[bd139]

I'm going to answer a slightly different question. At this point in time, I would not consider looking at VC++. It's pretty much dying at the moment. There's a lot of churn between Windows APIs and there's no one true path. The Win32 API itself is mostly useless at the moment as a lot of the advanced features are in higher level abstractions such as the unholy mess of MFC, ATL and now UWP. Microsoft have spent the last 15 years pissing off their desktop developers pretty hard with this thus literally everyone I have seen in the last 5 years is bailing out of the platform and heading in the direction of Qt/Wx and portable stuff at the moment. Even big fintechs, the slowest to move, are levering themselves off it and going that way.

C++ yes, but not in context to windows specific UI platforms.

Now having built some moderate sized stuff in VC++ on MFC and ATL I would have carnal relations with a cactus than go there again.

I will say another dead end is appearing here for you. VB.Net is disappearing too. With the migration of the entire Microsoft.Net ecosystem to .Net Core, they binned VB.Net.

It's a total nightmare and there are lots of worried people trying to work out what the hell is going on inside Microsoft. The only "one true way forwards" appears to be C# on .Net Core. That looks like it might have some legs.

[Bicurico]

Thank you for your valued response.

I never felt compelled to go to C#, as the compiled output is the same as the one from VB.net - there are even online translators to converted between C# and VB-net back and forth.

Let's say I do learn C# and start using this instead of VB.net.

Could I benefit on the C/C++ side, too? I mean when I do need to develop add-ons for CAD software that expects scripts/plugins/macros to be written in C++. How similar would C# be to C/C++?

You are right: it is a big mess!

Regards,
Vitor

[bd139]

While VB.Net and C# run on the same virtual machine, C# is orders of magnitude more powerful. This is mostly only because it has had a lot more active development over the last decade or so than VB.Net. It allows you to do a lot more with a lot less code.

C# and C++ are totally different. Think two languages.

I would concentrate on learning "vanilla C++" first before doing anything windows specific. Not sure what the best approach for that is if I'm honest. Someone else may want to chip in here. I generally avoid C++ where possible and stick to C / C# / Python here.

[Bicurico]

Let me explain my "pain":

I can do whatever I need in VB.net. Speedwise, it is fast enough for my applications and I can "think" in VB.net, so when I want to develop an application, I don't need to plan too much: I start writing the code almost directly.

However, the number one limitation I have with VB .net is this: sometimes I need to be able to use hardware. I can do so, if there is for instance a RS232 interface and I program the protocol myself.

But sometimes, all I get is a DLL. And this is the deal breaker: I cannot communicate with the DLL through VB .net. It either is not possible or I don't know how to do it. Believe me I tried.

Example: there are 3D digitizing arms called "Microscribe". You can get a DLL to incorporate their use in your own programs. But that won't work if using VB .net.

Add to this the fact that modern CAD/CAM packages tend to use C++ as scripting language.

Regards,
Vitor

[bd139]

You can talk to things that ship as a standard DLL with VB.net without too much difficulty. Main problem is type conversion. Have a look at the following tutorial:

https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/com-interop/walkthrough-calling-windows-apis

I haven't used any "proper" CAD packages other than Kicad/Eagle for the last few years. Prior to that was Cadence and LISP (SKILL) which I used which was a long time ago!

[sokoloff]

I completely agree with bd139 not to learn C++ or use C++ to create Windows UI programs. Use whatever the established Microsoft platform du jour is. (The last one I used was WinForms, which was fairly easily accessible from VB.Net as well as C#.)

As for calling the same DLLs from VB.Net that you can call from C#, as far as I know that's generally (99+% of cases) possible. It's been ages since we switched from VB.Net to C# (around 2005 I think), but I don't recall there being any substantive differences in the "power" of the two languages at that time. Maybe have a look at ?

Now, as for other reasons to learn C/C++; I believe that C is the best "portable assembly language" that we have in the field. There is a close mental analog between your unoptimized C program and what happens on a simple CPU. That's very, very different from VB.Net where you couldn't begin to tell me what the computer is doing to actually run your code. I tell you this because that change means that there's a fair gap between your current mental model of programming and that which is used by C (and to a fair degree, by C++ as well). Expect it to be a learning journey.

As to whether to learn C or C++ "first", I don't think there's a difference between the basics of C++ and C in the learning process. C++ was originally implemented as a textual translation process from C++ source code and fed into a straight C compiler. The languages really are that close.

I'd consider learning C/C++ on the Arduino platform to be honest. It's cheap and simple, you can get some immediate feedback on whether things work or not, there's a ton of example code out there and most of it you can wrap your head around in 15-90 minutes. (Arduino is programmed in C++, but slightly tweaked and hidden to make it a little easier. Once you get a moderate level of mastery of that, you'll be fine on any other C++ platform with some googling.)

Recommendations:
1. Learn C++ on some simple examples. Console programs or Arduino here, not KiCAD or the Linux kernel.
2. Realize it's going to be very different mentally (not harder per-se, just different). You developed a lot of expertise on VB.Net such that you can just fire up the editor and start banging away at a new idea and get somewhere. Those days are over for a while when you're in C++ land. (They'll come back eventually.)
3. On complex programs, sitting down and thinking before banging away at the code is probably a good thing anyway.
4. Please, configure your C++ compiler to emit all possible warnings and make it a habit to eliminate every warning in your code. (Some go so far as to set "treat warnings as errors" which I think is a reasonably good practice, but if you started with a codebase where warnings are tolerated, that can be a painful cleanup.) If you don't do this, there will be a time when you waste more than a day troubleshooting a problem where the compiler was telling you what was wrong but you ignored it because "it was just a warning". I can probably find threads here on EEVBlog from the last month where someone did that (and this isn't really a high-volume programming forum).
5. Find a way to get help when you're stuck. If you can post the code openly, you can get help. If you need help getting something to work and can't post any code, it's a much harder process. Use StackOverflow for general programming questions. You can use EEVBlog FPGA/Micro forum for Arduino questions (even if code related) and get decent help.

[vtwin@cox.net]

I've attempted to self-teach Windows C++ on several occasions, with miserable failure each time. Not so much that I do not understand the language, but more that the underlying development environment is so complex to accomplish something that I would spend hours to build a very simple, basic "hello world" windows application.

I mainly learn when I have an application which needs me to write it in a particular language. Years (15+) ago that was VB and VB.NET. About 12 years ago I switched to C#, and .net Winforms apps. Then, about 9 years ago, C# ASP.NET apps as my customers didn't want their applications built on a desktop platform but on a browser platform so they could access them from an iPad. I'm still in this mode for the most part.

I've recently made the move to C# .NetCore console applications for a few utilities I've had to development (rather than a .net framework console app.)

I started to delve into an ASP.NET Core application, but again found the environment starting to get overly complex for a small project I needed to push out in a couple of days (a web-based active directory password change program so remote users can change their ad passwords, a requirement as the result of a recent IT audit), so I reverted back to .net framework ASP.NET and I pushed it out in a few hours.

I have to write an ASP.NET Core Web API application to integrate a client's CRM into SAP Concur later this month. The Visual studio template generated enough code to get me started but the whole MVC thing seems to add so much complexity to a simple project. I do not really understand what's going on under the covers and how all the pieces fit together.

I guess I need to invest in some new reading material to "learn" this whole MVC thing w/ ASP.NET core... although the days of going into a Borders or Barnes & Noble and visiting the computer section with row after row of "Teach yourself" et al books appears to be long gone -- last time I was at a Barnes & Noble, they barely had 1 bookshelf w/ books.

Other than for self-flagellation, I'm not sure what I would get out of trying to self-teach C++ with qt or wxWidgets at this point.

[bd139]

ASP.Net Core reference tutorials are here: https://docs.microsoft.com/en-us/aspnet/core/getting-started/?view=aspnetcore-2.1&tabs=macos

No need to buy $100 books that are 4 inches thick and tell you what to click now

I've built some rather complex stuff on ASP.Net Core and it's worth having a look at it in depth. It's far simpler than web forms.

It's really a problem with Microsoft this one. The ASP.Net Core stuff is pretty much the same as the rest of the industry works but WebForms wasn't. You have to spend some time unprogramming it from the brain. I've been doing ASP.Net MVC since about 2008 and it took a while to get over that hill but WebForms can die in a fire now.

Although for some other reasons I'm mostly switching my web focused stuff over to Go now. It's a lot less of a pain in my arse.

[NivagSwerdna]

IMHO you need to separate out the language from the libraries that you will use. 
Embarking on C++ for Windows UI development is rather passé and in that domain C# is a better fit.
If you are interested in GPU programming then C will do.
If you are interested in numerical programming then perhaps C++ with Boost libraries etc.
But don't underestimate how far JavaScript has come... Accelerated 3D graphics is perfectly feasible in .js
Share & Enjoy

[bd139]

But don't underestimate how far JavaScript has come... Accelerated 3D graphics is perfectly feasible in .js

[Bicurico]

Very good feedback!

Thanks to all.

So, right now I think this:

1) I need to keep trying to get the stupid DLL to work in VB.net. This would open many doors to projects in my head with almost immediate results.
2) I need to take the next step and move ton to C#. That is a tough one, since there will be many obstacles in the beginning with next to no new results compared to what I am doing in VB .net.
3) I should look at Arduino again and learn more about C/C++ on this platform (I did some small projects, but nothing really exciting).
4) I should learn C/C++ from a compiler point of view - perhaps doing some console applications, leaving the GUI to .net.

Does this make sense?

Regards,
Vitor

[sokoloff]

Yes.

The move to C# may (probably will) be less painful than you think. It’s overwhelmingly “just” syntax changes and not conceptual changes from VB.Net. You already know the frameworks and patterns; those are basically the same. (Expect for some edge cases, the languages are equivalent in expressive power.) You can also mix/match in a project if you need to. (I say this as someone with a C/C++ (and limited VB6) background who was forced by inane company policy to code in VB.Net for a while. I found switching between them to be quite natural.)