.NET programmers, what should I use in 2017 for a Visual C++ application?

[ChuckMaurice]

I have to develop a Visual C++ application (that mostly do OCR and picture analysis) based on a SDK. I don't know much about the .NET platform, I mostly do web dev and the closest I got to C++ are Qt multiplatform apps. 

 

I use Visual Studio 2015 and the Visual C++ package, but I'm prompted with multiple libraries and project types to choose: ATL, CLR, MFC, WTL, Win32...

The SDK is provided as a CLI app that I have to adapt, and I also have examples in C++ MFC (but also in multiple languages like Java, C, C#...). But I have to use C++ for the project and it has to be a Windows/.NET app.

 

I started using CLR to test, as I read the other libraries were very old, but I also read that ATL was heavy and quite far from the C++ base language. But most of the info I got was old (similar questions but answered in 2010 or before).

 

The software will run on Windows environments (mostly 7, but other versions must be possible), sometimes with low specs or industry-specific versions (Windows Embedded...). I will need advanced picture manipulation tools, folder management, SGBD connection, but UI don't really matters as long as it's usable.

 

What is the best library to use for my project?

[Unimportant]

Perhaps relevant: http://stackoverflow.com/questions/821676/how-do-i-decide-whether-to-use-atl-mfc-win32-or-clr-for-a-new-c-project

[ChuckMaurice]

1 minute ago, Unimportant said:

Perhaps relevant: http://stackoverflow.com/questions/821676/how-do-i-decide-whether-to-use-atl-mfc-win32-or-clr-for-a-new-c-project

Yes I read this one, this is what decided me to go for CLR. But two things bothers me:
- The post is 7 years old
- The last comment mentions: 

Quote

It may be worth mentioning that if you're using C++/CLR then you're not really using C++ at all. C++/CLR compiles to CIL just like C#

 

[stmfd sp!, {lr}]

I'd stick to Qt if you're looking for the things you mentioned. 

I tend to avoid Visual C++ since I can't stand managed C++ in any context. It's true that the previous comment regarding C++/CLI was oversimplifying the various compilation methods you can use with C++/CLI. Either way, it's a rather grotesque way to go about a project. 

 

I personally see no benefit in sticking with managed C++. If I wanted .NET GUI, I'd be using C# (if there were a few things that needed native operation, I'd get away with using a few DllImports w/ PInvoke but, if lots of my application rely on native components, I'm just gonna write it native).

 

Qt should help do a lot of the heavy lifting for you but I'm not sure to what extent Qt's framework provides facilities for "advanced picture manipulation tools". I'm trying to draw a blurred line between "Windows embedded" and "advanced picture manipulation" and struggling. The other GUI suggestions you made are all really quite out of date and limited in the sense that you'd probably have to implement a lot of the stuff you've mentioned here on your own or link against some library that does it already. I also can't give any solid metrics regarding the overhead of running the various suggestions you made on the various platforms you also mentioned.

 

If you were talking specifically about modern Windows versions, I'd have assumed you were talking about C++/CX which is something I've not put a lot of interest in. If it has to be a .NET app, consider the performance aspects of using a native language compared to doing it in C# (to be honest, I've never bought into Visual C++ and not many of my friends have either. C# tends to be the language Microsoft pushes when it comes to modern .NET development - and with good reason). 

 

tl;dr - if you require native, go native but don't go for these old, limited, libraries that will work against you. My primary suggestion would be Qt but I'd still hinder when it comes to the specifics of your photo manipulation and how well this will port to "Windows embedded". 

[ChuckMaurice]

1 hour ago, stmfd sp!, {lr} said:

tl;dr - if you require native, go native but don't go for these old, limited, libraries that will work against you. My primary suggestion would be Qt but I'd still hinder when it comes to the specifics of your photo manipulation and how well this will port to "Windows embedded". 

After talking to my boss, Windows Embedded is a wrong spec for the project, decided at first for maximum compatibility (client told us he had Windows Embedded machines, but the cameras can't work on those anyway so we're just gonna ignore that).

 

I'm gonna try to sum up the specs in a more comprehensive way:
- the app must be Windows 7 compatible (and next Windows versions if they update the OS). But "standard" Windows only.

- it will run on decent Windows PCs so performance is not a big issue (I have a 1 second analysis time on an old Dell Latitude from 8 years ago, I think I'll be fine).
- I can use either 32 or 64 bits, I think I'm gonna go with 64 because the OCR SDK works a little faster on x86_64. If I have time I'll do both versions just in case.

- SGBD specs haven't been decided yet but we're probably gonna end up using either MySQL or SQL Server depending on budget.

- I don't know C# a lot and I have a short window for developing, but the main reason for C++ over C# is that the SDK comes in with C++ headers (.h) but the C# equivalent is compiled into uneditable .dll files or other unreadable files (also we struggle having support in C#). I already had to modify some .h files to adapt the SDK so I can't use C#, really.
- I'll try to sell Qt on next meeting but my boss was clear he wanted .NET (because some other related projects are done in VB.net or C#). Also, the commercial license of Qt is pretty expensive.
I wouldn't say I'm fluent in Qt either, I haven't done desktop app programming for a long time. I just remember it was the go-to solution for GUI and C++ back in the days. But I hopes Microsoft has a good answer to that, even in C++.

With that in mind, what library would you use for VisualC++ to be as much native as it gets?

[stmfd sp!, {lr}]

Just now, jldjul said:

After talking to my boss, Windows Embedded is a wrong spec for the project, decided at first for maximum compatibility (client told us he had Windows Embedded machines, but the cameras can't work on those anyway so we're just gonna ignore that).

 

I'm gonna try to sum up the specs in a more comprehensive way:
- the app must be Windows 7 compatible (and next Windows versions if they update the OS). But "standard" Windows only.

- it will run on decent Windows PCs so performance is not a big issue (I have a 1 second analysis time on an old Dell Latitude from 8 years ago, I think I'll be fine).
- I can use either 32 or 64 bits, I think I'm gonna go with 64 because the OCR SDK works a little faster on x86_64. If I have time I'll do both versions just in case.

- SGBD specs haven't been decided yet but we're probably gonna end up using either MySQL or SQL Server depending on budget.

- I don't know C# a lot and I have a short window for developing, but the main reason for C++ over C# is that the SDK comes in with C++ headers (.h) but the C# equivalent is compiled into uneditable .dll files or other unreadable files (also we struggle having support in C#). I already had to modify some .h files to adapt the SDK so I can't use C#, really.
- I'll try to sell Qt on next meeting but my boss was clear he wanted .NET (because some other related projects are done in VB.net or C#). I wouldn't say I'm fluent in Qt either, I haven't done desktop app programming for a long time. I just remember it was the go-to solution for GUI and C++ back in the days. But I hopes Microsoft has a good answer to that, even in C++.

With that in mind, what library would you use for VisualC++ to be as much native as it gets?

I overlooked your mention of the native SDK you are using for OCR. If that's the case, I'd definitely be using a native solution (unless it was some native library that I'm only using a few functions of - then, as I said, I'd just use DllImport w/ C#). You should maybe look into Visual C++ if you think it would tie together GUI and native lib usage nicer than DllImport. I'd always go for Qt since I can't stand any form of managed C++. 

[ChuckMaurice]

The other thing I forgot to mention about Qt is the commercial license : the price is pretty high and my company (who are not developers) don't want to invest in that just for one project. Also, as I said other related projects are written in VB.NET or C#.
 

34 minutes ago, stmfd sp!, {lr} said:

I overlooked your mention of the native SDK you are using for OCR. If that's the case, I'd definitely be using a native solution (unless it was some native library that I'm only using a few functions of - then, as I said, I'd just use DllImport w/ C#). You should maybe look into Visual C++ if you think it would tie together GUI and native lib usage nicer than DllImport. I'd always go for Qt since I can't stand any form of managed C++. 

 

What do you call a native solution? C#/WPF ?

I saw a comment here, maybe that's the way to go:

Quote

 

You may want to consider C# and WPF for the GUI part, and C++ for the "core" part of your desktop application.
You can then write a simple C++/CLI bridging layer, to connect the C#/WPF GUI to the C++ core.

I think I'll try this for now, with the CLR/Windows Forms backup plan if I loose too much time.

[stmfd sp!, {lr}]

Just now, jldjul said:

The other thing I forgot to mention about Qt is the commercial license : the price is pretty high and my company (who are not developers) don't want to invest in that just for one project. Also, as I said other related projects are written in VB.NET or C#.
 

 

What do you call a native solution? C#/WPF ?

I saw a comment here, maybe that's the way to go.

I think I'll try this for now, with the CRL backup plan if I loose too much time.

Native solution would be using a language that has the classical definition of native. E.g. compiles to instructions that run directly on the processor. So, C++ without the managed stuff that .NET can give you, such as Qt, would be a native solution. As for the "C++/CLI bridging layer" I suppose that would work and is kinda what I meant when I mentioned DllImport from C#. I just assume it would be a cleaner solution using managed C++ to bridge to unmanaged C++ but I really don't know since I don't use managed C++ at all. It's something I totally avoid.