What are the parts of C++ that make C unsuitable to be used for scientific libraries?
Someone could argue the merit of C (or Fortran for that matter) to be simplicity. However, why do developers choose to expand onto C++, rather than remain in C?
$\begingroup$
$\endgroup$
3
-
4$\begingroup$ PETSc is written in C, so I'd take issue with the premise of your question. $\endgroup$– Daniel ShaperoCommented Jul 15, 2022 at 16:51
-
4$\begingroup$ The question is ideed wrongly posed. C++ is better for software development than C, simply because C++ is progressing for more than 20 years now, whereas C isn't. That doesn't make C unsuitable for scientific libraries, in the same way that Fortran isn't. Moreover, C is also not simpler than C++. $\endgroup$– davidhighCommented Jul 16, 2022 at 0:11
-
$\begingroup$ @davidhigh Well possibly, but OTOH I've also read arguments for "stable ABI", which is the reason why a lot of high-level languages have difficulties in binding to C/C++ libraries: compiler-research.org/libinterop. This may be interpreted to favor sticking to C in order to allow a development of a better C-derivative language. $\endgroup$– mavaviljCommented Jul 16, 2022 at 16:32
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
6
Nothing makes C unsuitable for scientific libraries. There are tons of very useful libraries written in C, and C's ABI is compatible with almost every other language unlike C++.
The primary reason for using C++ is simply convenience. You don't have to be so explicit and careful about everything you're doing (especially concerning memory management), and there are many features which let you reduce how much duplicate/redundant code you have to write.
answered Jul 15, 2022 at 13:26
-
$\begingroup$ Is it wrong to interpret convenience as in laziness? $\endgroup$– mavaviljCommented Jul 15, 2022 at 14:20
-
1$\begingroup$ We are a very big community, from people who are just starting programming to experts on the ISO C and C++ committee, but even with experts too much code is always a problem. $\endgroup$ Commented Jul 15, 2022 at 16:26
-
3$\begingroup$ "too much code is always a problem" -- so use a programming language that allows you to say
std::map, rather than having to write 8290 lines of code (the GCC implementation ofstd::map). $\endgroup$ Commented Jul 15, 2022 at 19:00 -
1$\begingroup$ that is what I generally do, though just because C can't write "std::map" doesn't mean there isn't any existing C library which implements a self-balancing binary tree, or I might have a special situation where
std::{x}doesn't fit what I need and I have to resort to at least interfacing with a C-like library interface (i.e. HDF5, PETSc, MPI, METIS/PARMETIS, etc.). I could just as easily say "I'm not going to write a massively parallel sparse matrix library so I'm just going to use PETSc". $\endgroup$ Commented Jul 16, 2022 at 1:28 -
1$\begingroup$ @helloworld922 Well yes, of course you can find C libraries that support balanced trees. But then what is the advantage of using C + external libraries (which may or may not be portable) over C++ with its built-in library (which is, by definition, portable)? I'm not arguing that C cannot be used. I just don't see the point when people argue that C is actually better suited. $\endgroup$ Commented Jul 18, 2022 at 2:50
$\begingroup$
$\endgroup$
2
C++ is a vastly larger language. The C++20 language standard has 1610 pages, the C11 language standard has 470 pages (without appendices in both cases). In that difference of more than a thousand pages are:
A vastly larger standard library. Of course you can express everything in the C++ standard library (containers, algorithms, I/O, ...) in C as well, but why would you spend years of your life writing code that comes as part of your compiler?
A vastly easier system to manage large code bases. C++ has many mechanisms that allow for convenient encapsulation (classes, polymorphism, namespaces, now modules) that require inconvenient and laborious workarounds in C. As above, it's of course possible to all of this in C (as it is in assembler, for that matter), but it takes work and time and effort and debugging skills -- why would you put in the time and money to do that if you didn't have to?
In the end, if your goal is to write a 200-line program, I'd say choose whatever you want. Doing easy things is easy in any language. But most of the world operates on programs that have hundreds of thousands or millions of lines of code; these are hard, and you want as much support as you can to minimize the potential for bugs and maximize the time you can actually spend on the stuff that matters rather than re-writing core data structures that are already available and tested.
answered Jul 15, 2022 at 18:58
-
2$\begingroup$ Originally coming from C, I found that one of the most useful features of developing computational libraries with C++ is the availability of templates. To achieve similar functionality in C required extremely ugly macro manipulations which were a nightmare to maintain. $\endgroup$– njuffaCommented Jul 16, 2022 at 22:59
-
$\begingroup$ @njuffa Yes, that's an excellent observation as well. Think about the clumsiness of the BLAS interface, for example, in order to support multiple data types. $\endgroup$ Commented Jul 18, 2022 at 2:47
$\begingroup$
$\endgroup$
9
The actual question is that developers ask is usually not "which available language is better for a computational task at any particular point of time" but "what will get the job done with the least effort".
Fortran77 is still used in numerous computational engineering codes. That is because some extremely complex models have been developed in that language and tested extensively over many years. Rewriting those in a more modern language (even Fortran90) will not only be a waste of time, but will potentially introduce bugs. So people continue to use those.
C++ and C were popular when new codes started moving away from Fortran. As a result, there is now a huge legacy code base in these languages. The effort that will be needed to move to more modern languages, e.g., Rust, is not worth it at this time. Once Rust has proven itself and has enough libraries, we will see new generation codes being developed in that (or whatever language becomes the most popular next).
answered Jul 16, 2022 at 21:40
-
$\begingroup$ I think our worlds differ, because I think it the other way around. I would prefer using an elegant tool over getting a solution using a second-class technological paradigm, which some people consider C++ to be. Which motivates the question as to why couldn't one use just C. $\endgroup$– mavaviljCommented Jul 17, 2022 at 9:27
-
2$\begingroup$ That's OK if you have invented a new vastly superior numerical method, are funded by large grants with the express purpose of developing a new code, or are independently wealthy. The majority of computational engineers will have to pay attention to cost and time. I'd ask why not use Fortran, which is designed for computational engineering and science (supports multidimensional arrays without hassle), instead of C, which is designed for compilers and operating systems. $\endgroup$ Commented Jul 17, 2022 at 10:17
-
$\begingroup$ Seconded. For much of computational engineering and science I would contend that modern Fortran is an elegant tool. $\endgroup$– Ian BushCommented Jul 17, 2022 at 10:53
-
$\begingroup$ @mavavilj Nobody here is arguing against the "question as to why couldn't one use just C". Of course you could. People are just not seeing why one would use C. C++ can do everything C can and much much more. Why would anyone restrict themselves to C? It's like asking "but why couldn't one just ride a lawnmower from New York to L.A.?" Well yes, you could. But why would you for a regular trip, unless you have a very specific goal in mind? $\endgroup$ Commented Jul 18, 2022 at 2:55
-
$\begingroup$ But I've also heard about problems of post-docs having to translate Fortran to C. But I agree that in principle it's probably a better designed tool for CSE. But as is the case with other languages, it's not always the most fit that wins in use. After all, we also have Numerical Recipes in C and what not. $\endgroup$– mavaviljCommented Jul 18, 2022 at 6:43
$\begingroup$
$\endgroup$
1
Some of the biggest reasons I choose C++ over C for non-trivial scientific computing codebases time and time again are:
- simple encapsulation mechanisms (classes, namespaces, etc.)
- the portable standard C++ libraries
- the existence of templates in C++ and the expanding features and uses for them, e.g.:
- generic functions/data structures
- compile time polymorphism via CRTP
- constraints & concepts
Item one and two have some pretty clear benefits when used right, so I will focus on an example for the last point. The example I will use stems from a somewhat recent research project I was involved in where we were developing a distributed spacetime discontinuous Galerkin codebase.
In this project, we were trying to architect the codebase to be able to run in a distributed manner using MPI. However, we tried to make some optimizations where we would spawn separate non-MPI processes and use shared memory segments via Boost.interprocess to exchange data between MPI and non-MPI processes on the same node.
Now, Boost.interprocess had functionality that allowed one to allocate data structures on shared memory segments but you had to carefully design the data structures to do it. What we already had were existing data structures we used for localized, serial work and the ideal goal from both a usability and performance view was for us to try and make them also usable with shared memory instead of constantly serializing and deserialize things.
After studying the Boost.interprocess library, I wrote a small amount of new code using ideas from type traits and SFINAE to extend these data structures so they could either live in a serial environment or live in a shared memory segment, depending on how a template parameter was set. The implementation did not break older code using the data structures and made it much easier to write new, correct code to communicate our data structures between an MPI and non-MPI process.
This could not have been done with C.
-
$\begingroup$ "This could not have been done with C.". But what about with some other language that interops with C? $\endgroup$– mavaviljCommented Jul 20, 2022 at 7:07