I am just looking at the options for now but I have a large number of C libraries that were written in Visual Studio 6 as statically linked .lib. Newer development needs to be done in Visual Studio 2010 that will call these libraries and it has been decided that although there are possible solutions to calling these old libraries, that they should be updated to Visual Studio 2010. As part of that conversion, it is looking likely that we might as well convert them to an OO language. Whether that be C++, C++/CLR or C# is up for discussion.
New applications may be written in C# that will call these libraries.
What would be best to convert the libraries to? It also needs to be a fairly straightforward (i.e. not too time consuming) option. I think converting them to C# will be too much work. Unmanaged C++ would be the easiest but would C++/CLR be a good middle ground? I am thinking here that it is easier to call C++/CLR from C# than unmanaged C++ and therefore would be worth the little more work here
Rewriting from scratch is not an option. There are over 100 libraries
and a lot of code.
If rewritting them is not an option I don't understand this statement.
As part of that conversion, it is looking likely that we might as well
convert them to an OO language. Whether that be C++, C++/CLR or C# is
up for discussion.
You cannot "convert" C code to C# and/or C++/CLR code. The only correct term would be a total and complete rewrite. It sounds like your better of just loading the project in the newest visual studio and compiling it as is.
If it already works there is no reason to change the language the dll is written in.
By the sounds of it...You don't seem to be familar with any of the languages your suggesting considering you had a question about the term unmanaged C++.
We have already gone down the route of leaving these libraries as C
written in VS 6 and trying to call them from C# written in VS 2010. It
got a little messy and it was decided that this was not a good long
term direction.
This means your only real choice is to rewrite the libraries so they are easier to work with. Just switching to C++ will not solve the problems you ran into. You can use C style conventions within C++ without an issue.
Related
I have around 5 C++ DLLs which have thousands of functions and so on. So the thing is, I kind of fell in love with WPF which is in C#(as I understand). But this is another language, so after doing a bit of research I found out that I could create a wrapper, and so I did(The wrapper was created in C++/CLI). The wrapper has some few conversions, and it worked fine. I also heard about Pinvoke, but my problem with all of these is that what if I don't have time to convert thousands of functions and variables? What do i then do? Is there some kind of fast way?
PS. Im using Visual Studio 2012
Thank You
You may want to check out SWIG.
SWIG is a software development tool that connects programs written in
C and C++ with a variety of high-level programming languages.
I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?
Any insight into this is greatly appreciated.
EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.
C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.
I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.
I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.
If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.
I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...
So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.
The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...
Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.
I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.
I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.
/pissedof
From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).
A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).
There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.
For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
This is a very general question. I'm a self taught 'programmer' who programs in C#. A project I would like to work on would be made a whole lot easier (in the grand scheme of things) if I knew C++. How easy is it to move from C# to C++? Any pitfalls I should watch out for? And if I am using VS2010, can I program (not in the same class, but same project) something in both C# and C++?
Moving from C# to C++ is not easy. The basic syntax can appear the same (e.g. if, for...), but there are deep differences, e.g. the RAII pattern and stack-semantics variables whose destructors are called when they go out of scope, etc. are not present in C#.
Moreover, C# uses a non-deterministic garbage collector (which can be OK for memory resources, but is useless for other kind of resources). Instead, with modern C++, you can use templates and smart pointers (like std::/boost::*shared_ptr*), which allow you to have deterministic reference-counted "garbage collection", which is very efficient, and is valid for both memory and non-memory resources (like file handles, sockets, textures...).
Moreover, the C# generics are very different from C++ templates (C++ templates are very powerful, and allow an advanced level of programming called template meta-programming).
In VS2010 you can have a solution hosting both C++ and C# projects. To communicate between the two worlds (the native world of C++ and the managed world of .NET/C#) you can use C++/CLI as a kind of bridging layer.
In Windows 8 a new technology should be introduced, called WinRT (based on COM), which allows inter-language communication. In this case, you can use C++ with WRL (a template-based library) or C++/CX language extensions to build C++ components that can be used from C# and .NET.
Happy learning.
I came the other way from c++ to c#. In many ways that was a relief. C++ has a lot more rules than c# particularly around memory allocation. The syntax can also be challenging and it is easy to wander off into out of bounds memory. C++ is however much more suitable for system level programming but with great power comes great responsibility.
I recommend first grabbing a copy of Scott Meyer's Effective C++ and read it cover to cover. This is the best resource I know of for getting the basics correct and without question improved the quality of the code I was producing, even as an "experienced" c++ developer. Then grab a unit test framework and take a look at a c++ kata (in this case an xcode project but should still be useful). And get familiar with the Standard Template Library which contains a lot of useful/efficient code/classes for containers, algorithms, etc.
Lastly, best of luck. Learning a new language is always a challenge and can be daunting but the payoff is generally worth it. If nothing else you will see your c# code with new eyes.
can I program (not in the same class, but same project) something in both C#
and C++?
Answer is no you cannot. You can if you use Managed C++ & C++. But if you are working with C# then you can't have C# and C++ code inside same project
How easy is it to move from C# to C++?`
It is a bit subjective but in my opinion it will be a very hard step. C++ is a different language so it will be as hard as learning a new language :) again it's subjective so I won't go into details
Since you're working with .NET, I presume you're using Visual Studio?
It's rather easy to combine C# and C++ in the same program, using the /clr compiler option. Your C++ code can include both normal, standard-compliant C++ classes, and also ref class .NET objects designed for use from C#. The two are separate but can access each other, via pointers from ref class to native class, and the gcroot template from native class to ref class.
Note that I said "in the same program", not "in the same project". You'll have to split into two parts, one C# project and one C++/CLI project, and one will be a DLL that the other loads. There's also a trick for combining the two together during build so you end up with a single executable file, but that's more trouble than it's usually worth.
Note, you might find this smart pointer class I wrote useful, it makes the use of native class objects from ref class .NET objects much easier.
scoped_ptr for C++/CLI (ensure managed object properly frees owned native object)
I'm building an c# app that is designed to replicate and enhance the functionality of an VB6 app developed many years ago.
My problem is that one module in the old app does some realy complicated things and trying to replicate this starting from specs would be a big pain for me. Even if this sounds like the best idea.
My question is : is there a way i could keep the old VB module and integrate it into the c# app, so that i wouldn't have to rewrite everything ?
Thanks!
Yes. You can turn the module into a COM object, and .Net will happily call into COM objects. Depending on what you have right now you may need to find a copy of Visual Studio 6 to make that happen (it's still available on MSDN if you have a subscription). To give you more exact instructions we'd need to see more of your code.
Visual Studio has a wizard that allows you to convert VB6 into VB.NET, which you could then reference in your C# project and use. However, this migration tool is no longer shipped with Visual Studio 2010 (it was shipped in older versions) Even still though, there generally is a lot of manual touchup work required, you are generally better off rewriting it by hand which could result in higher quality code, anyway. My recommendation to you is to rewrite the code, you can make touchups and make sure that it works correctly without having to go the COM/Interop route, but don't necessarily shun that option either. If rewriting all the code really is an issue, then interop is a solution.
You can use COM or export the module as a DLL. Here's some information for you regarding VB6 and COM.
In theory yes, turning it into a com module, and calling it from your c# code. Whether this would be easier or not, I am not sure.
The problem is that this issue will not go away, and if there are changes needed to the module, or the interface, then someone has to do it. So practical yes, but consider carefully what you are doing.
You can migrate the existing vb code to vb.net and compile it as a separate assembly and add it to the C# application.
Can't VS2010 (maybe 2008) support both VB and C# projects in the same solution? If I'm not mistaken, they can. So you could actually convert your VB6 code into VB.Net and have the project in your solution with the C# stuff.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've done my C++ classes and practices after which I started learning Visual C++ using book Ivor Horton's Visual C++. The problem is that I am unable to understand the language of this book and badly trying to understand the codes. I want to learn Visual C++ for Windows application development and making my future in that (also because I already know C++).
Some of my friends told me to switch to C# since it has many library function to create GUI etc and told me it's hard to code Windows applications in Visual C++.
Now in these holidays I am going to join classes, can you help me which language I should stick to, and which one will be easy?
From very beginning I want to learn Visual C++ and sometimes I think it's hard when I don't understand concept in reference books etc.
Any help will be very appreciated, thanks a lot for taking your precious time.
Visual C++ and Visual C# are not languages nor GUI frameworks; they are Integrated Development Environments - IDEs. This means they are text editors tailored to the task of development.
Visual C++ lets you code in C++, Visual C# lets you code in C#. Also, both let you create GUIs in a point-and-click manner.
Sounds like what you really want to do is create GUIs. In that case, without having further information, I recommend you go for C#. It is a much cleaner language than C++, it has fewer ways to shoot yourself in the foot, and it provides access to the immensely useful .NET framework.
C# features that C++ doesn't have:
Fully automatic memory management
Lambda functions¹
Type inference¹
Reflection
Remoting
Automatic serialization
True entity types
Properties
Database integration via LINQ
Convenient functional-style programming via LINQ
No header files
No undefined behavior
Direct interoperability with many languages
Compile once, run everywhere
¹ these features have been added to C++ in the C++11 standard.
C++ features that C# doesn't have
Template metaprogramming
Typedefs
Zero-overhead principle
Means to enforce const-correctness
Mature compilers that produce extremely optimized code nowadays
Much wider platform support
can you help me which language i should stick to , and which one will be easy.
In general, if you're goal is to develop Windows Applications, you'll probably find many, many more simple examples to learn from in C# than in C++. There is a huge community around C# for Windows GUI development.
That being said, many of the concepts you'll need are the same in any language you learn. You can't really go wrong - at some point, you'll probably want to learn both langauges if you're going to program professionally (as well as others).
i think it's hard when i don't understand concept in ref books etc.
You should get a beginning programming book, not reference books, and go through it step-by-step. If your goal is just GUI development, I'd recommend a good, simple C# book, and just step through it form beginning to end, and do all of the examples. Learning from a "reference" book won't work - it's reference material, and not meant to teach concepts.
C++ vs. C# - a Checklist from a C++ Programmers Point of View
http://www.thinkingparallel.com/2007/03/06/c-vs-c-a-checklist-from-a-c-programmers-point-of-view/
C# is the premeir .net language for developing applications on the .net framework.
Native C++ is more cross platform and low level. It's used for writing applications for windows, mac, linux, embedded systems, etc.
C++.net is C++ adapted to the .net platform, and is primarily used for writing performance critical parts of an application (the rest of which is written in C#, VB.net, or something else as they integrate virtually seamlessly).
Visual C++ is microsoft's windows compiler for C++ that can be used to write native and C++.net applications.
Writing .net applications solely in C++ in much harder than writing them in C# as you have to deal with more low level issues. If you want to write .net applications, I recommend using C# and C++.net if you need it.
with C++, you could be able to touch the 'low level' near 'assembly things' part of programming
c# is never meant to be created to beat c++, with c# you get the whole .net framework utilities, faster cleaner form generations, with the lack of 'low level' part
C# is largely intended for Business Applications so as Java. Visual C# is Microsoft's implementation of the C# programming language specification, included in the Microsoft Visual Studio suite of products.
C# is much slower than C++, since the code passes through CLR. VC++.net has the same drawback.
VC++ is very hard to learn, so as MFC and windows programming, even though you know C++. But is it a prestigious and efficient language.
It is easy to switch from VC++ to VC#. But the reverse is harder.
If you go for VC++, MFC and Windows programming, try this.
Maybe consider what you are likely to want to do in the future, as a professional or a hobbyist. Programming is a wide field, in which both languages have their place. If its too early for you to make that decision, C# is probably most likely to do you good in the future.
It's worth remembering that they are both only languages - and just as writing a good book is about more than correct spelling & grammar, writing good code is about more than the details of a particular languages syntax.
I would learn both.
Having said that, I would create GUI/Application projects using C#, and use VC++ for any COM or device communication.
I would check out Which platform should I use : native C++ or C# ?