Choice between C ++ and C #
I will try to raise a controversial, but I think an interesting topic. To begin, I will introduce myself. By occupation, I specialize in developing desktop applications for Windows, so for the most part from this position I will perform a comparison.
At the start of a project, there can often be a question about the choice of development tools, and if in some cases the answer to this question follows from the need for compatibility with libraries and applications, in others the answer is not obvious.
Separate articles require consideration of the choice of Java or interpreted languages. They will be preferable to C ++ or C # in some cases, but we will move such cases beyond the scope of this article and focus on comparing C ++ and C #.
')
For clarity, I’ll designate C ++ as unmanaged code, and C # as managed code. The article could compare managed and unmanaged , but it would be less useful practical. And the mixed code, although it is of some interest, is left mostly outside the scope of this article.
I apologize for some categorical statements, however, I think it is required for more accurate reporting of thoughts. I will compare the criteria, giving for each some conclusion based on personal practice, the fundamentals and well-known experience of use. So, let's begin.
C # allows you to start development faster, and this allows you to quickly get a prototype solution. The speed of development in C # at the initial stages of the project is significantly higher compared to C ++.
However, when the project's infrastructure is created, the main approaches and libraries are chosen, and the build is set up, the development speed in C ++ and the development speed in C # become approximately the same.
Thus, in short low-cost projects, C # will have an advantage in terms of development speed, but in long and relatively expensive projects this advantage will be insignificant.
C ++ cross-platform in fact, albeit with some reservations, additional costs, as well as binary incompatibility between platforms.
C #, in fact, turned out to be non-cross-platform, despite the existence of unofficial .net environments under different platforms and even potential binary compatibility between platforms.
C # is designed to be cross-platform, but its development has not gone in this direction. Therefore, under Windows a fairly complete .net infrastructure has been formed; on other platforms, equivalent infrastructure did not appear.
At the same time, an almost equivalent infrastructure has developed for development in C ++ on most existing platforms, there are a lot of libraries that are compiled or can be compiled for any existing platforms. That is why there is a huge number of cross-platform applications and libraries of different scale, written in C ++, along with cross-platform libraries there are libraries specific to individual platforms. All this gives practical equal chances for developing applications on various platforms.
And although C # can be used to build applications for non-Windows platforms, the problems caused by using .net in a non-Windows environment negate many of the benefits of choosing C #. Therefore, it is possible to recommend it for cross-platform use unless the C # code is already written. At the same time, it should be clearly understood that in future this will bring additional support costs.
The obvious fact is that the possibilities for optimizing unmanaged code are much wider than the possibilities for optimizing managed code. Thus, peak code performance is achievable only in unmanaged execution, i.e. in the limit, almost any problem in C ++ can be solved with less resource requirements. Therefore, in the heavy tasks associated with processing large amounts of data, C ++ has strong advantages over C #.
But it should be understood that when choosing the wrong approach, in C ++ it is possible to write code that will run slower than C # code that performs the same task.
If we talk about the totality of subjective “simplicity of development”, “beauty of the code” and objective performance, then using C # it is easier to write code that satisfies these criteria simultaneously. However, this does not mean that productive C ++ code will necessarily be scary or difficult to understand, just when writing it you will need a more “creative” approach to meet the listed criteria at the same time.
The fundamental basis of the advantages of C ++ is the ability to write code that will be executed directly by the processor, and the ability to work directly with memory. Of course, freedom gives you more opportunities to create problems for yourself, but in some cases it is better than not being able to overcome the performance ceiling. And this ceiling may well lead, for example, to the solution of a problem for which one good server would suffice, you have to build a farm of several servers, or to the fact that your application will require top hardware for tasks, for which would be enough iron released 7-10 years ago.
The difference in the range of C ++ and C # libraries is that C ++ has more libraries, they have a long history, for which they have become well-established and optimized, often cross-platform, many with open source. However, with all the positive aspects, C ++ libraries both have very different, often even archaic architecture, often not an object, but a structural-procedural interface. This is due to the fact that many C ++ libraries are C libraries.
Another unpleasant feature of C ++ libraries is the creation and redefinition of their base types. Many C ++ libraries get their own types of strings, containers, override some basic types. There are logical explanations for this (better performance, support for cross-platform, lack of suitable types at the time of writing the library), but all this does not add ease of use and beauty to the code. The basic C ++ libraries do not give as much as the standard C # libraries provide, therefore the selection of the right libraries for a C ++ project is a task that is necessary even in relatively simple projects.
However, not everything is so bad, for C ++ there are quite a few “beautiful” libraries. And the base libraries are constantly expanding. The question is often only what sacrifices this beauty will require.
In C #, the problems listed above are significantly less. A huge number of libraries with .net is in the database, plus a large number of freely available libraries, which covers almost all the primary development tasks for Windows. The presence of a large number of standard types almost eliminates the libraries where the base types are redefined. And due to the fact that C # libraries are relatively young, the interfaces of libraries, as a rule, fit better into certain design patterns, which often simplifies their study.
However, on closer examination, there is a great chance that for your specific task the C # library will not turn out, moreover, it may turn out that it is not sufficiently efficient to solve such a task in C #, therefore such a library will not appear in the future, and , it will not work fast enough.
The second unpleasant feature of C # libraries is that many of them are just a wrapper around unmanaged libraries, which will always lead to performance losses on type conversions, and create additional problems of debugging and distribution.
One could simply say that under Window, C # is much more convenient to debug and stop there.
However, if for some reason you are using unmanaged along with the mananged code from the C # assembly, then its debugging will become more complicated than the usual debugging of unmamanged code from C ++.
At first glance, C ++ and C # code is very similar in appearance. But the variety of C ++ code is greater, because C ++ is both C and C ++ and C ++ 0x at the same time, and you can use all this at the same time (of course, if your compiler supports this).
With #, it is only C #, although its syntax is constantly expanding. C # code, as a rule, looks simpler and more concise than C ++ code (although it was not always possible to say about the first C # versions). The C ++ and C # language constructs are very similar, but significant differences can be found in the details.
If C ++ can be blamed for the lack of reflection, late binding and garbage collection “in the base”. This C # should be blamed for the lack of full-fledged destructors, the lack of full-fledged macros, a rather coarse setting of inheritance, the absence of constant methods and members, the lack of global methods (procedures), very limited support for templates, the list goes on ... case C ++, so in the case of C #.
The syntax C #, perhaps, can be called a simplified version of C ++, so C #, like any simplification, has both positive and negative effects.
It is worth saying that more complex code is often easier to write and analyze if it is written in a simpler language. From this position, using C #, there are less chances to make a mistake in fundamentally complex code and more chances to write clean code, possessing the same resources. This can be useful in solving problems that are rather complex, but not demanding on performance. However, the greater the number of "synthetics" in C # makes a smaller assessment of the performance of the code for its "appearance."
There is not much difference in application support between C ++ and C #. Although it should be understood that some bugs in applications written in C #, it is impossible to fix using .net tools and, if necessary, fix the cost of support may increase significantly. However, if we talk about refactoring, then often applications written in C # will be a bit cheaper to refactor.
Perhaps the main risk of using C # is a strong tie to Microsoft. Of course, Microsoft is unlikely to disappear somewhere in the near future, but it is worth understanding that Microsoft is a commercial organization whose goal is to make a profit, and for profit, we need sales of its products. Therefore, it is in the interest of Microsoft to develop the development of C # and .net so that this leads to sales of new Microsoft products. So if the interests of your development will not be in the interests of Microsoft, sooner or later this can lead to problems.
There are risks of using C ++ too, but these are other risks. I would call the main problems related to binary compatibility of libraries. If your libraries are not in the source code, then it is important for you that they are compatible. For example, switching to another runtime will be possible only when rebuilding or obtaining new versions of libraries, the work of several runtime-s in one process can lead to interaction problems. All this can significantly increase the cost of project development.
Along with the risks of development, there are risks of low-quality code. Since C # is less demanding of a developer, the probability of low-quality code appearing in C # is on average higher than in the case of C ++. With a critical mass of such code, this can create serious problems in the operation of the application.
In the case of C ++, the situation with low-quality code is somewhat better, since the chances of survival for a bad code are lower, but the cure for a bad C code is of course not.
C ++ and C # have no complete application self-sufficiency. For C ++, runtime is somehow needed, and for the C # .net framework.
However, I would like to note that C ++ runtime, like any other library, can be static linked into an executable module, so the executable module can contain everything necessary for work, and thus becomes self-sufficient, in the case of C # such, standard means not feasible.
Building C ++ projects is much more complicated than building C # projects. However, it should be understood that greater complexity provides additional flexibility, which sooner or later may become useful to you. True to this point will only increase the costs of your time.
Perspective reasoning is always speculation. Today, both C ++ and C # are actively developing (although C ++ began to actively develop not long ago), but what will happen next?
I am am disturbed by the fact that the growth rates of processor performance (at least per core) have noticeably decreased and it is unlikely that we will see significant growth in the near future. The same thing, I think, can be said about I / O performance.
All this, most likely, will create a request for optimization of software products and a request for parallel computing. I have some skepticism as to whether C # can satisfy all these requests.
I can not say that there is a universal answer to the question “C ++ or use C # for the next project?”, However, I can say that at different periods of my work I would answer the question of choice in different ways, and if years 5 back, I would not consider C ++ as the preferred choice, but now in more cases I tend to use it. However, I think that for rapid prototyping under Windows, C # is and probably will be the preferred solution for C ++.
At the start of a project, there can often be a question about the choice of development tools, and if in some cases the answer to this question follows from the need for compatibility with libraries and applications, in others the answer is not obvious.
Separate articles require consideration of the choice of Java or interpreted languages. They will be preferable to C ++ or C # in some cases, but we will move such cases beyond the scope of this article and focus on comparing C ++ and C #.
')
For clarity, I’ll designate C ++ as unmanaged code, and C # as managed code. The article could compare managed and unmanaged , but it would be less useful practical. And the mixed code, although it is of some interest, is left mostly outside the scope of this article.
I apologize for some categorical statements, however, I think it is required for more accurate reporting of thoughts. I will compare the criteria, giving for each some conclusion based on personal practice, the fundamentals and well-known experience of use. So, let's begin.
1. development speed
C # allows you to start development faster, and this allows you to quickly get a prototype solution. The speed of development in C # at the initial stages of the project is significantly higher compared to C ++.
However, when the project's infrastructure is created, the main approaches and libraries are chosen, and the build is set up, the development speed in C ++ and the development speed in C # become approximately the same.
Thus, in short low-cost projects, C # will have an advantage in terms of development speed, but in long and relatively expensive projects this advantage will be insignificant.
2. Cross platform
C ++ cross-platform in fact, albeit with some reservations, additional costs, as well as binary incompatibility between platforms.
C #, in fact, turned out to be non-cross-platform, despite the existence of unofficial .net environments under different platforms and even potential binary compatibility between platforms.
C # is designed to be cross-platform, but its development has not gone in this direction. Therefore, under Windows a fairly complete .net infrastructure has been formed; on other platforms, equivalent infrastructure did not appear.
At the same time, an almost equivalent infrastructure has developed for development in C ++ on most existing platforms, there are a lot of libraries that are compiled or can be compiled for any existing platforms. That is why there is a huge number of cross-platform applications and libraries of different scale, written in C ++, along with cross-platform libraries there are libraries specific to individual platforms. All this gives practical equal chances for developing applications on various platforms.
And although C # can be used to build applications for non-Windows platforms, the problems caused by using .net in a non-Windows environment negate many of the benefits of choosing C #. Therefore, it is possible to recommend it for cross-platform use unless the C # code is already written. At the same time, it should be clearly understood that in future this will bring additional support costs.
3. Code performance and resource requirements
The obvious fact is that the possibilities for optimizing unmanaged code are much wider than the possibilities for optimizing managed code. Thus, peak code performance is achievable only in unmanaged execution, i.e. in the limit, almost any problem in C ++ can be solved with less resource requirements. Therefore, in the heavy tasks associated with processing large amounts of data, C ++ has strong advantages over C #.
But it should be understood that when choosing the wrong approach, in C ++ it is possible to write code that will run slower than C # code that performs the same task.
If we talk about the totality of subjective “simplicity of development”, “beauty of the code” and objective performance, then using C # it is easier to write code that satisfies these criteria simultaneously. However, this does not mean that productive C ++ code will necessarily be scary or difficult to understand, just when writing it you will need a more “creative” approach to meet the listed criteria at the same time.
The fundamental basis of the advantages of C ++ is the ability to write code that will be executed directly by the processor, and the ability to work directly with memory. Of course, freedom gives you more opportunities to create problems for yourself, but in some cases it is better than not being able to overcome the performance ceiling. And this ceiling may well lead, for example, to the solution of a problem for which one good server would suffice, you have to build a farm of several servers, or to the fact that your application will require top hardware for tasks, for which would be enough iron released 7-10 years ago.
4. Libraries
The difference in the range of C ++ and C # libraries is that C ++ has more libraries, they have a long history, for which they have become well-established and optimized, often cross-platform, many with open source. However, with all the positive aspects, C ++ libraries both have very different, often even archaic architecture, often not an object, but a structural-procedural interface. This is due to the fact that many C ++ libraries are C libraries.
Another unpleasant feature of C ++ libraries is the creation and redefinition of their base types. Many C ++ libraries get their own types of strings, containers, override some basic types. There are logical explanations for this (better performance, support for cross-platform, lack of suitable types at the time of writing the library), but all this does not add ease of use and beauty to the code. The basic C ++ libraries do not give as much as the standard C # libraries provide, therefore the selection of the right libraries for a C ++ project is a task that is necessary even in relatively simple projects.
However, not everything is so bad, for C ++ there are quite a few “beautiful” libraries. And the base libraries are constantly expanding. The question is often only what sacrifices this beauty will require.
In C #, the problems listed above are significantly less. A huge number of libraries with .net is in the database, plus a large number of freely available libraries, which covers almost all the primary development tasks for Windows. The presence of a large number of standard types almost eliminates the libraries where the base types are redefined. And due to the fact that C # libraries are relatively young, the interfaces of libraries, as a rule, fit better into certain design patterns, which often simplifies their study.
However, on closer examination, there is a great chance that for your specific task the C # library will not turn out, moreover, it may turn out that it is not sufficiently efficient to solve such a task in C #, therefore such a library will not appear in the future, and , it will not work fast enough.
The second unpleasant feature of C # libraries is that many of them are just a wrapper around unmanaged libraries, which will always lead to performance losses on type conversions, and create additional problems of debugging and distribution.
5. Convenience debugging
One could simply say that under Window, C # is much more convenient to debug and stop there.
However, if for some reason you are using unmanaged along with the mananged code from the C # assembly, then its debugging will become more complicated than the usual debugging of unmamanged code from C ++.
6. Language and Syntax
At first glance, C ++ and C # code is very similar in appearance. But the variety of C ++ code is greater, because C ++ is both C and C ++ and C ++ 0x at the same time, and you can use all this at the same time (of course, if your compiler supports this).
With #, it is only C #, although its syntax is constantly expanding. C # code, as a rule, looks simpler and more concise than C ++ code (although it was not always possible to say about the first C # versions). The C ++ and C # language constructs are very similar, but significant differences can be found in the details.
If C ++ can be blamed for the lack of reflection, late binding and garbage collection “in the base”. This C # should be blamed for the lack of full-fledged destructors, the lack of full-fledged macros, a rather coarse setting of inheritance, the absence of constant methods and members, the lack of global methods (procedures), very limited support for templates, the list goes on ... case C ++, so in the case of C #.
The syntax C #, perhaps, can be called a simplified version of C ++, so C #, like any simplification, has both positive and negative effects.
It is worth saying that more complex code is often easier to write and analyze if it is written in a simpler language. From this position, using C #, there are less chances to make a mistake in fundamentally complex code and more chances to write clean code, possessing the same resources. This can be useful in solving problems that are rather complex, but not demanding on performance. However, the greater the number of "synthetics" in C # makes a smaller assessment of the performance of the code for its "appearance."
7. Cost of support
There is not much difference in application support between C ++ and C #. Although it should be understood that some bugs in applications written in C #, it is impossible to fix using .net tools and, if necessary, fix the cost of support may increase significantly. However, if we talk about refactoring, then often applications written in C # will be a bit cheaper to refactor.
8. Risks
Perhaps the main risk of using C # is a strong tie to Microsoft. Of course, Microsoft is unlikely to disappear somewhere in the near future, but it is worth understanding that Microsoft is a commercial organization whose goal is to make a profit, and for profit, we need sales of its products. Therefore, it is in the interest of Microsoft to develop the development of C # and .net so that this leads to sales of new Microsoft products. So if the interests of your development will not be in the interests of Microsoft, sooner or later this can lead to problems.
There are risks of using C ++ too, but these are other risks. I would call the main problems related to binary compatibility of libraries. If your libraries are not in the source code, then it is important for you that they are compatible. For example, switching to another runtime will be possible only when rebuilding or obtaining new versions of libraries, the work of several runtime-s in one process can lead to interaction problems. All this can significantly increase the cost of project development.
Along with the risks of development, there are risks of low-quality code. Since C # is less demanding of a developer, the probability of low-quality code appearing in C # is on average higher than in the case of C ++. With a critical mass of such code, this can create serious problems in the operation of the application.
In the case of C ++, the situation with low-quality code is somewhat better, since the chances of survival for a bad code are lower, but the cure for a bad C code is of course not.
9. Self-sufficiency of applications
C ++ and C # have no complete application self-sufficiency. For C ++, runtime is somehow needed, and for the C # .net framework.
However, I would like to note that C ++ runtime, like any other library, can be static linked into an executable module, so the executable module can contain everything necessary for work, and thus becomes self-sufficient, in the case of C # such, standard means not feasible.
10. Convenience assembly
Building C ++ projects is much more complicated than building C # projects. However, it should be understood that greater complexity provides additional flexibility, which sooner or later may become useful to you. True to this point will only increase the costs of your time.
11. Perspectives
Perspective reasoning is always speculation. Today, both C ++ and C # are actively developing (although C ++ began to actively develop not long ago), but what will happen next?
I am am disturbed by the fact that the growth rates of processor performance (at least per core) have noticeably decreased and it is unlikely that we will see significant growth in the near future. The same thing, I think, can be said about I / O performance.
All this, most likely, will create a request for optimization of software products and a request for parallel computing. I have some skepticism as to whether C # can satisfy all these requests.
findings
I can not say that there is a universal answer to the question “C ++ or use C # for the next project?”, However, I can say that at different periods of my work I would answer the question of choice in different ways, and if years 5 back, I would not consider C ++ as the preferred choice, but now in more cases I tend to use it. However, I think that for rapid prototyping under Windows, C # is and probably will be the preferred solution for C ++.
Source: https://habr.com/ru/post/262461/
All Articles