Slashdot Mirror
Ask Slashdot: Is C++ the Right Tool For This Project?
ranton writes: I am about to start a personal project which I believe should be done in C/C++. The main reasons I have for this are the needs to manage memory usage and disk access at a very granular level and a desire to be cross-platform. Performance is also important but I am unlikely to spend enough time optimizing to be much faster than core libraries of higher level languages.
On the other hand, network access is also a critical part of the project and I am worried about the effort it takes to make cross platform code for both network and disk access. I have been working in the Java / C# world for the past decade and things like TCP/IP and SSL have just been done for me by core libraries. Do libraries like Boost or Asio do a good job of abstracting these aspects away? Or are there other options for doing granular memory and disk management with more high level languages that have better cross-platform library support? I am willing to brush up on my C/C++ skills if necessary but want to spend as much time as possible developing the unique and potentially innovative parts of my project. Thanks for any advice you can provide.
On the other hand, network access is also a critical part of the project and I am worried about the effort it takes to make cross platform code for both network and disk access. I have been working in the Java / C# world for the past decade and things like TCP/IP and SSL have just been done for me by core libraries. Do libraries like Boost or Asio do a good job of abstracting these aspects away? Or are there other options for doing granular memory and disk management with more high level languages that have better cross-platform library support? I am willing to brush up on my C/C++ skills if necessary but want to spend as much time as possible developing the unique and potentially innovative parts of my project. Thanks for any advice you can provide.
consider using python with py2exe, psutil and mmap. you may find what you are looking for !
I would recommend using Qt for a cross platform framework. I haven't tried every C++ framework, but of the ones I have tried, Qt is by far the best.
You haven't provided nearly enough information to make a decision here. You haven't defined what you mean by "granular level", whether you need a UI, what functionality you have to provide.
Decide whether your project is to be done in C or C++. Choose one and embrace it.
There's an illusion that because these two languages share a common origin that they're somehow the same, bundled together as "C/C++". Especially since C code can often be valid in a C++ compiler.
In reality, the good programming styles in each of these two languages differ substantially. Start wedging bits of C code inside a C++ program and you'll soon find yourself fighting the language and core libraries. Likewise, the conventions for core concepts like objects and linked lists in C are somewhat different to C++ and with their own strengths. Both are powerful languages for large projects, but not the same language.
Then C++ is almost certainly not the language for you, unless it is a pure learning experience.
Really.. C++ is a relatively high commitment language, and performance is one of its mainstays, however you dont feel you will spend much time optimising it?
If you cannot look quite quickly over the descriptions of Boost/ASIO and see what they do (and dont) bring to the table, then you will be fighting a very
uphill battle.
The reference to TCP/IP being 'done for you' is worrying.. do you think people program raw TCP in C++?
If you value your project at all then I would suggest C++ is not sounding like your solution.. especially if you need cross
platform. Your reasons seem almost to be reasons NOT to use an unfamiliar language.
As almost everything else has equal or better cross platform support, it seems to me like you need to look more closely to what you mean/need by
'granularity' and perhaps change your mentality using familiar languages, and the solutions for problems in those areas.
You said nothing useful about your project
C++ could be a good choice for all the things you've mentioned. Networking is not an issue, as there are many open source libraries (e.g. libcurl - http://curl.haxx.se/), and using Boost is often a good thing anyway. Also, there are at least two good memory allocators: tmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html) and jemalloc (http://www.canonware.com/jemalloc/) so you may not need to write your own. (I assume that the above open source licenses are good for you, but they are just examples...)
However... I doubt that your project will be only Network + Memory + Disk. What else do you need? Some UI? Should it interact with the Web? Or with services in the Cloud? There's no easy answer to your question without knowing what else you need, and I wouldn't even exclude a hybrid-language approach (e.g. C++ / Python / JavaScript*).
* Before someone starts ranting about JavaScript having to run in a browser: NO - JavaScript runs perfectly fine withouth a browser, and can easily interact with C++. Have a look at V8 or SpiderMonkey, just to name some JavaScript engines.
Can you hear it, my son? This is the voice of ignorance.
It is possible to use C++ with Java. Try to look at Java Native Interface (JNI). It comes with a performance penalty on each call across the interface, but if you are using it for networking, the penalty will be negligible.
If you are working on Windows, it is possible to do the same with C# using a CLI interface wrapper. I have no idea if that trick works on Linux/Mac.
The truth may be out there, but lies are inside your head
You can treat C++ as the name implies; plain old C with some extra stuff you may or may not use.
Nothing in C++ is forcing you to create object oriented code.
I think that using smart pointers and RAII pattern is in all respects better than garbage collection.
I love C++. It will take you a a couple of years to get good at it, but as you say - it's a personal project, and I am guessing you've had enough of Java.
However, if you are doing any sort of front end GUI for it, then don't go there. Stay with Java. There is no unified FE GUI for C++ which I could recommend.
Likewise, many of the suggestions above seem to have not read that you already know Java.
This comment was written with the intention to opt out of advertising.
The main reasons I have for this are the needs to manage memory usage and disk access at a very granular level
And why, exactly, do you imagine you need these things?
(You may well do - but you don't give a reason for it, so it's entirely possible that you don't need to manage those things on a granular level)
Not everything that can be measured matters; Not everything that matters can be measured.
C++ is often unreadable
That's not a problem with the language, it's a problem with whoever wrote the code.
I've been writing software for about 40 years - and one of the things I've observed in that time is that it's possible to write unreadable code in pretty much any language. I've also observed that it's possible to write readable code in pretty much any language.
Not everything that can be measured matters; Not everything that matters can be measured.
Boost is a very powerful addition to C++ but that doesn't mean it's as easy to write code as it is in a high level language. e.g. boost's asio is extremely complex and even doing something simple with it like setting a timer is far more pain than other languages. Boost doesn't implement stuff like web sockets or other things either so it's no good on its own without other libraries. If I had to write something in C++ which was performing in a role that would more naturally fall to something like C# or Java, I'd probably use the QT library instead but only after being certain that I needed C++ to begin with.
If you're better at Java or C#, use that.
Sometimes the right tool for the job is the tool you know best.
If you're not confident at what you know, perhaps the best tool is someone else.
I am about to start a personal project which I believe should be done in C/C++.
I cringe when someone says "C/C++". Sort that out first by choosing one language for your project. Either write lean and clean pure C code, or fully use the proper abstractions of C++ to write memory-safe and easily-maintainable code, but don't make an unprofessional crusty mix of the languages.
That's because you have no clue. The problems of high-performance, incremental garbage collection was already solved in the 80s and it is ridiculous that there are still ignorants like you around who think that reference counting and incongruent OOP design patterns could replace GC.
It has only been solved in theory, not in practice. In practice garbage collection is still garbage if you need high performance, usually because high performance usually implies low memory usage and consistent high performance.
Check out http://cython.org/. This project will enable you to write high level logic in python and drop to C in the performance critical sections of your code.
Nothing important in VS is written in C#. The compiler, linker and so on - you know the things that need to be tight with optimal performance, are all written in C++. The platform itself (WPF) is written in C++ (Visual Studio UI is WPF). .NET CLR is written in C++. Do you want me to continue or are you happy enough stewing in your own ignorance?
C++ is never the right tool for the job, but for a lot of jobs the right tool doesn't exist and C++ will work.
I am TheRaven on Soylent News
The C++11 specification was explicitly written to permit garbage collection and includes standard library functions for providing hints to a garbage collector.
I am TheRaven on Soylent News
Could you describe a project for which the choice of c++ is a good one?
Guess what, you can easily do that:
Oh... good luck!
Edit: My statement that Python in implemented in C++ may not be entirely correct (there are C implementations) but that's not the point and shouldn't prevent you from doing the exercise.
By the way, you're welcome to copy your final list on Slashdot, I'd be curious to see it for my own education.
Are you trolling? For anyone not already intimately familiar with the process, the vertical learning curve of writing Perl bindings for C++ code will cause more pain, anguish, wailing and gnashing of teeth than writing in either pure Perl or pure C++. You will also gain nothing in portability: in fact you will lose, because portability will be the lowest common denominator of both Perl and C++ (I won't argue over which is lower to start with, both can be high with the right libraries), with the added headache of having to deal with two orthogonal sets of problems, in different languages.
ASIO is in fact part of Boost now and I personally like it. The thing you need to remember though is that ASIO is not an HTTP client or really any type of client at all - if you want to do HTTP you'll need to write the HTTP headers and handle chunking yourself. That's actually not so hard though. For cross platform SSL you just need to use Open SSL which is actually pretty simple in C++.
Basically if you want really fine control of your network streams or are using things other than just HTTP then ASIO is going to be what you want. If you just want to have something handle HTTP for you then there's quite a few other libraries out there you can choose from.
Doesn't Automatic Reference Counting at the compiler level give most of the benefits of Garbage Collection (except for manually breaking retain cycles with a 'weak' modifier) at the same time as offering benefits on resource-constrained devices? A garbage collector takes CPU clicks, and therefore reduces performance and battery life.
Languages like Swift and Vala use reference counting and have a very modern, clean feel. Objective-C also does, if you don't mind an antiquated syntax.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
But then you are simply programming in C.
Nothing wrong with that, but why use a C++ compiler when a plain C compiler would spare you so much overhead?
And on the Eighth Day, Man created God.
Here is Stroustrup's take on learning C++, which includes some examples of why you might not want to start with C first.
Nonaggression works!
So true!
Personally I don't like to hire people that don't understand low level programming, unless it's for mundane / cheap stuff; no matter what the argument is, the guys that know C / ASM always seem to have a better understanding of problems in general.
Lack of garbage collection is one of many reasons why C++ produces fast code. The entire point of using C++ is that you want to have control over how, when and where things are allocated and deallocated.
In practice, single desktop class machines with 6000+ concurrent users are not typical use cases. Instead, high performance applications are likely to look more like 3D rendering engines.
In practice, when you have 16ms to produce a frame, it really matters that the garbage collector doesn't kick in for 2ms once every second, because that'll push you past your frame window and lead to stuttering and dropped frames.
In practice, it really matters that you can structure your code to make sure no allocations are happening during certain critical operations, because an allocation will potentially need a new page, and the kernel barrier and/or hit locks resulting again, in 1-2ms of unexpected delay, and a dropped frame.
In practice, it really matters too that you have enough control over memory layout to guarantee that certain structures are all going to end up in cache at the same time, and that you're not going to be doing a bunch of pointer indirection fetching memory during time critical rendering code.
In practice, modern garbage collection doesn't allow you to solve any of these problems. That is why real time rendering engines are still written in C++, and will continue to be, and why everyone writing them will continue to be glad that C++ is not garbage collected.
C and C++ mix very well. Being able to use C API straight from C++ code, was design goal #1 from day 0 when C++ got invented
Using C++ from C, is a little less straightforward but quite doable. I wrote a small article years ago on how to do it easily. Check for yourself if you are curious
Idioms for using C++ in C programs
concerning OP question. Despite I'm a C++ person, I would recommand doing it in C first. Yes, there are C++ framework such as Boost but I have never liked these frameworks because it bloats your exec with a lot of code (mostly templates) and it adds a magical layer (things works magically) that has a mystical aura (I mean only few people knows how ASIO really works under the hood). Even if you become an ASIO expert after lot of time, the project will still have the potential to become bloated and inefficient as soon as a new contributor, less knowledgeable will jump in. Efficiency is the price to pay to use these type of framework.
Do what successful projects do, start easy and simple. Use C. If down the road, this appears to not be enough for your needs, reevaluate. FFMPEG comes to mind when thinking about a project that has exactly the same requirement than your project and has been very successful with C
Good luck and have fun with your project!
No one denies that one can write bad code in any language, but the accusation still stands - languages can help or hinder understandability with their syntax. C++, and it's desire for backward compatibility with C, led to some really unfortunately syntactic decisions that make the code less legible. Operator overloading isn't very good for understanding of performance characteristics (Is this adding 2 ints or an array?). Memory management has provided code bulk (because not everything can be RAII) and the plethora of pointer idioms one must navigate if one has any sort of sizable codebase that has been maintained by many others over the years. Now add on features and libraries so broad and complex that organizations actually have their own dialects of C++ (or so I am told) that their employees are allowed to use. Need I go on?
Frankly, C++ has advantages in some places, but aiding in making code legible and understandable is not one of C++'s strong suits. And I've worked on (and probably helped generate) enough crappy C++ codebases to know of which I speak.
That is all.
Python is written in C. Linux is written in C. OS X is written in C (with libraries in Objective C). Most low level software is written in C, not C++. It's very important for this exercise to differentiate C from C++. They are not the same language and haven't been since C++ stopped being implemented using macros and the preprocessor and got its first compiler.
C is a much simpler language to learn and maintain, especially if you're doing low level code. C++ has a lot of very nice features, but it's benefits really only come into play if you're willing to put the time and effort into properly learning generic programming (the foundation Boost and the STL).
But, as most people have already pointed out, starting with Python and then migrating portions over to C or C++ as needed for performance is a much better approach. You can manage IO just as effectively from Python as you can from C or C++ and your development time will be much much shorter.
-Chris
As a systems programmer, I have used both C and C++. When using C, I (and my team) needs to expressly have the discipline to embrace the tenets of C++ vis-a-vis encapsulation, maybe some facade dp thrown in. Most of the rookie mistakes are easier to spot in C, but there is a lot more code to be written in C to achieve the same effect (writing & using an object agnostic linked list for example).
When using C++, things are hidden in plain sight, and rookie mistakes are easily overlooked, because someone found a "smarter" way to use the language. I've pulled my hair out in cases when people had overloaded operators in nonsensical ways. People would just compare a string with constant, without knowing that it is invoking a copy constructor and equals operator, which in turn is doing some form of strcmp to get the job done. C++ is great for system software if people know the ins and out of it and performance isn't of a great concern. It will give you the same performance as C if you know how to use it well.
Also if performance is important, you'd probably need to use DPDK on intel boxes for networking, squirrel away huge pages for your memory allocator or do something like jemalloc etc, so your choices might be limited.
If performance is not THAT important, then most of the modern libraries build on top of any high level language will give you all the tools that you need to build your project. Personally I'd try to look at Go. I don't know much about it, but it seems to have taken care of a lot of pain points in systems design (specially queuing, async processing, threads etc).
Templates I think were a mistake to add to C++. It has removed a lot of object orientation from C++ programs, and it has bloated things up tremendously because of popular styles of using them and due to STL. Templates are essentially smart macros. You end up with duplicated code for each instantiation, and with some styles even the functions themselves are inlined. This only works because this style is big on the PC where there is massive amounts of RAM and cache space to soak up the inefficiencies. The current compiler/linker technology is not capable of effectively turning template heavy code into efficient code by recognizing when there is duplicated code that could be combined into shared object code. Often what is normally a library of object code in other languages turn into a library of header files in a template-heavy C++ style.
Now templates as a concept aren't all bad. A small template that provides type safety while sitting on top of a small tight library is great. Programmers need to learn their tools, learn how to use them well, and learn when to not use them. But most programmers don't do this, instead they learn to follow what other people do blindly until it becomes a habit.