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.
C++11/C++14 is usually the right tool if you need to balance performance of C and functionality of higher level languages. The only gap that keeps c++1x behind is full garbage collection, but many times reference counts and containers are enough to handle memory requirements.
You can pick one of the two and make no promises about the other.
Or does "cross-platform" in this context mean "Linux+Windows"?
If you're more familiar with C# or Java, then you should use one of those. As you say yourself, "Performance is also important but I am unlikely to spend enough time optimizing to be much faster than core libraries of higher level languages." That tells me that you're probably not capable of writing a program in C or C++ that will be faster than what you can write with C# or Java. And the C or C++ version will take you several times longer to write and debug.
I haven't used C# since '08, and I never used it for high performance computing, so I can't speak much for that. However, modern Java has a new high performance IO model called NIO that includes direct memory buffers. You can even create a direct memory buffer that's backed by a memory mapped file, and it won't count towards the Java heap or the direct memory limit. That covers "manage memory usage and disk access at a very granular level," and it's cross-platform.
tl;dr: The clear choice is Java, unless you're more familiar with C# and use Windows on your dev PC.
C++ can be used in Managed Mode, if you're working with Microsoft Tools. You can write your critical code in C++/CLI that also gives you access to low level stuff for the parts that you need, compile as a static library, then use C# for everything else.
The static libraries should be portable to other platforms as well.
Now word of advice, C++/CLI, if not used properly can be rather nasty. Be really careful with memory management when you're working with unmanaged pointers.
you want everything -- memory, disk, network, speed -- and c++ will give you all of that just fine. And it'll give you the giant learning curve, and force you to take every hard road from start to finish.
Have you considered using perl -- which is pretty well cross-platform -- and writing the few granular components in c++, bootstrapped into perl?
That's pretty standard for i-want-to-use-perl-but-i-need-this-part-to-be-faster.
Depending on how hard-core object-oriented you wish your program to be, plain old C might be a much better option, especially if you everything can just be command-line only and will not need a GUI.
Otherwise, and I'm almost loathe to mention these, C# and Java might be even better ways to go.
C++ is needlessly complicated.
And on the Eighth Day, Man created God.
It's fast and has all the libraries you'll ever need. Plus concurrency is really easy if you need it (and you probably do).
Spent 20 years in C++, using C when nobody else cared. I've spent a *lot* more time finding cryptic bugs in C++. Sure you can get cryptic bugs in C, but it is a *much* simpler language, Better options for linking with other languages too. Keep in mind that a Hummer isn't necessarily the best way to go down the drive to check your mail. YMMV.
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
'Cross platform' and 'manage memory usage and disk access at a very granular level' do not readily go together. And not in Java either. Abstract your 'granular access' away in a C (I said 'C', not 'C++') library of your own. Use a lot of #ifdefs. On top of that, build in whatever you want.
Religion is what happens when nature strikes and groupthink goes wrong.
"network and disk access"
Socket interfaces:
QTcpSocket: http://doc.qt.io/qt-5/qtcpsocket.html
QSslSocket: http://doc.qt.io/qt-5/qsslsocket.html
Http/Ftp/..:
QNetworkAccessManager: http://doc.qt.io/qt-5/qnetworkaccessmanager.html
Disk access:
QFile: http://doc.qt.io/qt-5/qfile.html
I'd reccomend to use Qt as a base for your project For sure you can use boost and asio as well
I think that using smart pointers and RAII pattern is in all respects better than garbage collection.
C++ is often unreadable but e.g. Objective C is only usable on Apple computers.
Why not give it a try with FreePascal/Lazarus. Ease of development, lots of core libraries, lots of controle, cross platform..
Could you describe a project for which the choice of c++ is a good one?
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.
I don't think you know enough to know that yet. Or at least if you know enough you haven't told us enough to justify it. As cliche as it is, I'm going to quote Knuth: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"
I suggest you just do a prototype in whatever's easiest, fastest, and most flexible. Python, Ruby, C#, whatever you like. Get it working . Then see if it's slow as you think it is and go from there.
I see lots of hostile responses here (either way) but as a practical person who has to use C++, Python, bash, C#, and (argh) dos batch every week I would start with C# or Java (since you know those) and once you get the logic working like you want, see where the bottlenecks are then replace critical sections with C++ as you need to. That's worked really well for us. To begin with, the parts that we thought would need to be low level rarely were. Smart algorithms are much more useful than brute force. Or using libraries that do the brute force for you smartly. After a while you get a feel for it - but you don't have that yet.
The key bit is that you'll be 10x more productive in an expressive powerful language like C# or python than you will be in a restrictive fine detail language like C++, so it makes sense to bang out the framework in something flexible then only optimize the very smallest of key performance critical sections. Experience says that's less than 5%, usually 1%... so again, Knuth is right on the nose with his 3% estimate.
I use this language since more than 15 year. In time I augmented with stl/boost/asio /c++11. I never used the plain C. Based on this experience I would say:
1. If you are not already comfortable with the language don't use it. Use whatever you are best with at the moment.
2. Yes, you can do fine grained memory/disk/network management. However, this is a problem of how much time you invest. You are competing here with armies of developers that implemented this topics for you in "Java/C#". You are only one. I have doubts you will be more efficient.
3. The cross platform support is there but you must understand a few about each OS. At minimum you must understand something like CMake or the GNU build system. And, of course, the two mentioned above are not best suited for Windows.
4. If your project involves a UI don't code that in C++.
To your questions:
1. Yes boost does a very good job in abstracting the OS.
2. Yes asio is excellent when programming I/O.
3. On paper, I don't think there is a better language for "granular memory and disk management". However, if I were you I would use Java/C#. If When you will be in charge of a large team with a serious budget, think about C++ again.
You mention 'C/C++', and I think you need to realize that the two don't really mix well; in my experience, you go with one or the other, simply. True, you can use C style practices in C++, but then what's the point of using a C++ compiler?
I think there are many, excellent reasons to choose C++ for a project, but perhaps not the ones you list. Things like control over memory allocation, cross-platform and networking may not in theselves be compelling reasons for choosing C++, as they can be handled easily enough in C. Cross-platform and networking is all about following the POSIX standard, really, and getting away from the Windows toolkit. That and separating the presentation layer from the business layer(s). This is perfectly possible in pure C - I have done it many times.
The real reason for using C++ is that it supports design patterns well, IMO. Templates and template libraries like Boost are really about that; and design patterns are about adopting an architecture that is well thought through - they are formalized best practices, in a way.
Actually C++ does have garbage collection. For example, you can collect garbage with something like this. But as loonycyborg says, the RAII pattern is how you collect garbage with C++.
I have been working in the Java / C# world for the past decade [...] 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.
What you think?
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
Without any actual details of the project it is really hard to say anything truly productive.
As a rule, you are better off sticking with a language you know well, rather than "brushing up" on something you don't.
For most projects one of the higher level languages is more appropriate: Haskell, Lua, Python or whatever.
They are much faster to develop and debug with and don't have all the problems C and C++ can have.
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.
There are lots of options for networking in C++. Boost is a big and complicated set of libraries, so unless you want their other features you're probably better off using the standard libraries for networking (sockets and the like).
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.
"I just pointed out that dbus written in C++ would be much faster then the C version: simply by avoiding the cache hits."
I read your comment and I see nothing to justify that position. Apparently you seem unaware of the existence of resizable arrays in C.
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.
are in this day and age done indeed by libraries. Chose one that fits and for each language usually there is more than one choice.
What this means is that If you really have a choice of language for your project and want to see if certain tool is useful just make a prototype. There is no better way really.
At the end it is like buying a house or getting married - you have good things and bad things in each choice but if your choice fits your and your teams profiles then with a bit of luck you will have success with some but not unreasonable amount of stress.
Use Object Pascal. It's a better language to work with than C++. Free Pascal with Lazarus is a good, open source option. Alternatively there's Delphi which also has good cross platform support (Windows, OS X, iOS, Android, but not Linux yet and maybe Windows 10 Mobile soon).
You're slipping, 'Climatedot', this article doesn't mention 'climate' once!
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.
That's like saying C++ does have JPEG decoding. For example, you can decode JPEGs with something like this.
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
So the problems "are solved" but we still have GUIs freezing in the worst possible moment ?
I call BS on your statement.
Rust, Swift, Sappeur are the way to go.
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
Can you hear it, my son? This is the voice of ignorance.
Mod parent up!
Also, a properly tuned C++ program wil have at least as efficient data structures as the equivalent C program. Inexperienced, wasteful developers cannot be attributed to a language.
You can actually have objects of one octet length:
class MyBitField
{
char _bitfield;
public:
};
And? You can do that in C too - replace class with struct. However in both languages it might default to word size so better to use #pragma option to make sure it doesn't.
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.
You seem to be very dogmatic about this issue. Why can't we "transform" C programs slowly into better C++ programs incrementally ? Using bounds-checked arrays, smart pointers and other safety/security improvements ? Limit Cyber War Domain a bit while doing so ?
That sounds like a tangible improvement as opposed to your dogmatics.
Assembler or bust!
Except the C++ source code navigation, which they destroyed in the C# version (after VS2008 ?). And except that the editor is no longer real-time on my machine. Which is a monster with 20GByte RAM.
I need a plugin(!) to just get proper source code navigation back.
In other words, Dumbing Down To C# has fucked up Visual Studio. I hope the Politically Correct Pussy In Charge will soon be booted into some harmless Government Chair. Get me the real C++ guys back, Microsoft. Visual Studio must be de-pussified !
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>
It seems like having to make a trip by car between two cities and trying to decide which type of car to use?
So does it really matter if you choose a Ford, Hyundai, Tesla, Ferrari, Saab, Toyota, etc.? In the final analysis, wouldn\t any of those vehicles get you there just fine? Why not go with what you're comfortable with?
"Consensus" in science is _always_ a political construct.
A few years ago, when I was compiling all software for my personal workstation myself (LFS) as a learning experience, I actually did that. C++ was too big a hassle for too litle gain.
After a while during a reinstall I disabled g++ and only installed programs written in C or other languages. It was no big deal actually, opensource C++ projects feel huge and sloppy compared to the rest.
I would miss any number of languages more that I do C++. Python is a good example, cpython (the default) does not use C++.
NB: I have no hate for C++, some C++ projects are great. But C++ does not nearly have the important position that C has.
Try Haxe (http://haxe.org/)if you dare, you can transcompile your code to many targets including Java, C# and C++.
Look at their standard library if Haxe.Http is enought for your networking needs:
http://haxe.org/documentation/introduction/stdlib-introduction.html
I am getting up in years, but find it interesting that no one mentioned COBOL but me. :)
Some people claim ARC will consume more CPU cycles. That might be true for some benchmarks.
BUT - ARC will reduce RAM consumption by a factor of two as compared to GC. Plus ARC will be at least semi-realtime if properly used. GC on the other hand often freezes a GUI or a game in the worst possible moment. And memory cells surely will consume energy, too. Whether you store something useful or not.
So your explanation is not fully correct, but your conclusion is.
Use Vala, Swift, Rust, Sappeur and have most of the benefits of C++ without the Cyber War Snake Hole features.
You're trying hard to be an idiot and succeeding it seems. C++ is a language specification. It now also has a Standard Library. Everything else you may need is available somewhere in the form of third party libraries or depending on your platform, an SDK that comes with your OS or development environment.
The point you've failed on is simple: the idiomatic way to manage memory in C++ is RAII. The non-idiomatic way to do it is with garbage collection. If you're going to use C++, use C++ idioms, same as any other language.
C/C++ isn't a language.
It is two.
C is procedural.
And C++ object oriented.
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.
What you cannot easily do in C is to wrap this tiny (one oktet) data structure in a nice object oriented API. You cannot overload operators for this tiny data structures. You have the semantics attached to the data structure.
This means that you cannot achieve the same level of security and readability in C. And if you think this is just my claim, have a look at the CVE database. About 50% of exploits depend on some C-style shittiness which would not have happened with smart pointers and bounds checked arrays. In C++ you get those easily while it is almost impossible to do in nice C code.
Use ADA and don't shoot yourself in the foot. Portability will be an issue from a compiler availability standpoint. It is actually much better from a platform compatibility standpoint.
C++ is the best language for garbage collection because C++ makes so little garbage.
If you have to ask if C++ is right for you, it isn't.
Then why didn't they? Well for one thing they spent so much time on writing and getting _dbus_get_first_of_list _dbus_get_next_of_list _dbus_get_previous_of_list ( or whatever they called them ) that they didn't want to get rid of them. Second they spent too much time using and writing these procedures to think about what the most efficient way is. This is not to mention lines like MyElement *e=(MyElement *)list->data; Which require a copy of a pointer to e. A few extra instruction. Of course the single most important aspect of this. DBus is a critical program for linux. A lot of other programs use it, Inefficiencies reverberate through the whole system. This is one application that you want to get as fast as you can So why didn't they?.
Reference counting is extremely expensive, but the costs are diffused throughout the program making it difficult to account for them. Touching all those refcounts increases the working set of the program, which reduces cache and VM utilization. In a multithreaded/multi-cpu/shared memory environment, the add/release operations must be atomic, which slows them down considerably. OTOH with a generational collector, multi-cpu/multi-thread/shared memory system, the concurrency issues rear themselves in much fewer places, and the extra CPU's can be leveraged to provide nearly pauseless GC.
Refcounting isn't necessarily bad, but like the other GC methods it has its strengths and limitations, and developers should be aware of them. Refcounting's biggest strengths are related to its convenience - it's conceptually simple enough that most developers can and do implement it themselves, and it can be added without compiler or language support. But those aren't usually the strengths that are imputed to it.
For a list use LISP.
std::vector
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.
There are several million dollars in my bank account that totally disagree with you.
Oh and by the way my company IS held legally responsible for the code we make.
1. You called it a "personal project", so yes, the language you want to do it in is the correct one :-)
2. Can you be more specific about some of your requirements, such as "memory management"? Many languages/third party utils have support for many aspects of that. While you can, of course, create your own whatever it is you're doing, someone probably already solved at least part of the problem, and probably using multiple languages.
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.
Since performance is important, Java is your only hope, Java is faster than C, and the more Java you use, the faster than C it becomes.
Write it in Java, and run it on a java interpreter, written in java running on a java interpreter written in java, the more recursion, the more speed!
Define your own language (including the primitives for memory management that you want) and write a compiler to some bytecode machine. Then implement that machine on each of your target platforms in assembler (the ultimate in fine grain control). That will probably take you the rest of the week, and maybe through the weekend. Then, next week, you can implement your end state system in your new language.
Use C++ Boost library, will help a lot.
And this could be interesting:
http://www.johndcook.com/blog/2012/04/11/facebook-and-cpp/
Regards,
-M
Thank you. Couldn't agree more. I operate in a world where we have to guarantee 60 Hz deterministic real time performance, even in the worst case, while rendering a full screen HD image to the display using a SOC with a single core 800 MHZ processor. There are no extra cycles for software architecture that does nothing.
We manage memory the old fashioned way: quality built software. Do we manually call new() and delete()? yep. Do we leak memory? Nope. Can I prove it? You can bet you life on it. Literally. We have proven our software will never leak memory--proven it to the point that engineers have signed off on our software certifying it for use in life critical systems. A car you drive, an airplane you fly in or a medical device used by your doctor may have our code in it.
Now please *PROVE* to me that a garbage collection based system will never fail. *PROVE* you will never fragment memory so badly that new allocations fail even though memory is available. *PROVE* that a call to new() won't suddenly take 1 millisecond or 10 milliseconds instead of 10 microseconds.
Now finally, after proving that it is safe enough, *PROVE* that your system is as fast as mine and I'll switch.
I will be long retired before that comes to pass.
C is not C++. Since the release of C99 you haven't been able to treat C++ as a superset of it's predecessor. Now with the push to rapidly update C++ every other year or so, the differences between them are going to become drastically noticeable even to the most novice user pretty soon.
In practice, the garbage collected Java-clone virtual machine is the reason why the Android user interface is generally slower and less responsive than the iOS user interface written in reference-counted Objective C.
It's funny, even UI designers have noticed it. I've seen rants about how garbage collection sucks for user interfaces, when in the past they probably wouldn't have lowered themselves to worrying about such uncool geeky implementation details.
This shouldn't even be a question for an experienced programmer, but since you had to raise the question: No, do it in a more forgiving language.
The primary requirement for a program is correctness. So a question should be what language and tools facilitate testing and avoiding errors? For a fast, buggy program is worthless while a slower correct program might well be.
Similarly if performance is a consideration the question should be what are the best algorithms and data structures to use? For example the most optimized bubble sort in assembler doesn't compare to say quick sort in an interpretive language for large data sets.
Uh? A huge majority portion of the world development community would like to disagree with you there. C++ is a superb tool for many jobs as long as you're clear on "which C++" and "which libraries". SWIG gives you easy access to most other stuff and it's the most mature development platform by a long shot.
I've seen some huge Python codebases that exist only because their original author was a Python junkie. We're stuck with those codebases now and they're universally despised because of poor performance (GIL), tricky testability and unhelpful API design.
You should never be starting a new project in c++, always use python or lisp for new projects. man.
Except the C++ source code navigation, which they destroyed in the C# version (after VS2008 ?). And except that the editor is no longer real-time on my machine. Which is a monster with 20GByte RAM.
I need a plugin(!) to just get proper source code navigation back.
In other words, Dumbing Down To C# has fucked up Visual Studio. I hope the Politically Correct Pussy In Charge will soon be booted into some harmless Government Chair. Get me the real C++ guys back, Microsoft. Visual Studio must be de-pussified !
I code in C++ and Java and I have noticed as well that the supposedly low-level fast code in VS is much slower than the interpreted code in Eclipse. Incredibly slow on VS is the context sensitive help. I have trouble understanding why VS is so slow. The feature set seems to be much more limited than Eclipse, so I can't imagine what it is spending all it's time doing. Heck VS doesn't even have Variable name refactoring out of the box, yet it is slow, slow, slow.
If you are not allowed to question your government then the government has answered your question.
I think that using smart pointers and RAII pattern is in all respects better than garbage collection.
I agree. If I am done with a reference, I am done with it right now. If I want to delete() my reference right now, then I want to delete it right now. If I am worried about CPU cycles over memory at the moment, then I can make it put off deleting in my code. I really like Java and do most of my coding in Java, but the two things I wish were in Java is a deconstructor and the ability to recover memory for a particular object at my discretion.
If you are not allowed to question your government then the government has answered your question.
I think it's correct, but in the sense of the (apocryphal?) Churchill quote: "Democracy is the worst form of Government except for all those other forms that have been tried from time to time." -- C++is never the right tool for anything ... and neither are any of the other programming languages.
Or to paraphrase Tolstoy: "Each imperfect programming language is imperfect in its own way."
std::vector<bool >
The problem with smart pointers is that C++ has no native support for them. Which means you run into this lovely issue:
MyObject_ptr instance1( new MyObject ); // This works // This is a compiler error
MyObject_ptr instance2 = new MyObject;
instance1 = new MyObject; // Also a compiler error // This is how you reassign to a new object
instance1 = MyObject_ptr( new MyObject );
Despite the fact that for pretty much any other object or value all four ways "just work".
Also, reference-counted smart pointers fail miserably when your setup involves reference cycles. You're back to (effectively) manual memory management, which can be tricky if you're taking advantage of polymorphism, and you have objects which contain objects which may or may not contain other objects which may or may not contain back-references to other objects somewhere in the owing chain.
Yeah, yeah, you can "Doctor, it hurts when I do this. - Well, then don't do that!" things, but you can't blithely say "in all respects better" unless you're doing a "ignoring all the ways in which it is worse, it's in all respects better" double-think.
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
Fine. I know the difference between C and C++ and, as I wrote, that's not the point.
Can I see your list now, please?
Qt is cross platform, but non of the "granular memory stuff" will be. C++: write once, compile everywhere, with conditions Java: write once, debug everywhere Python (w/ Qt or wx): write it and get on with life
There are two driving use cases I see for using C++..
1. You need to have tight control over memory access/usage, and need tools to avoid copying while writing safe code (move semantics, references, etc)
2. You need to have tight control over generated code, allowing you to optimize your bottlenecks at the micro level
In the case of 1, you could also choose Rust or C, but the former is rather new and may look strange to you, and the later may require you to write code that is less safe (fewer compiler checks).
In the case of 2, I think C actually is just a better choice period -- its far clearer whats going on without objects and templates.
If you dont need either of those things there are a number of new languages that can give you adequate performance, systems-level access, all with cleaner, terser syntax: D, Rust, Nim, Crystal... im sure there are others.
I would suggest you look at D -- it has a C-style syntax, garbage collection, yet retains low-level access and C interop. You should be able to pick it up quick and you dont need to sacrifice your sanity to learn to write it cleanly and safely, unlike C++.
Since you're not saying what kind of tool/programm you're trying to build I presume it's some kind of performance critical focused but non-trivial application. So a compiled language probably is the best choice - you won't be dependant on some VM stuff or an interpreter.
The real C family of languages (I'm excluding C# with the 'real') isn't the worst choice for this sort of thing. In fact, it's just about the only choice. With C, C++ and Objective-C left to choose from, C++ comes to mind as a tried and true systems language.
Long story short: You can't go wrong with picking C++ - just don't expect your code to be the cats meow from the get-go. Once you're finished you'll know enough to rewrite the entire app again. But we all know that's how it goes with new PLs.
I still do have to important pieces of advice for you: ... Check that to save yourself tons of work.
Did you check the existance of FOSS Unix tools? It could be that your problem can be solved by doing some tricky CLI and scripting stuff with a set of specialized *nix tools - perhaps just compiling them into a single binary.
Something else: If you're in it for the learning experience consider those new hip system PLs Go and Rust. They look promising ... or at least interesting.
Good luck.
We suffer more in our imagination than in reality. - Seneca
Waiting for this one
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).
If you go with C, I'd recommend checking out beej's guide on network programming / sockets. He's got some examples in there that can be modified to fit basic client/server needs. Also, I for one enjoyed the read.
As for SSL, in my C projects, I use libCURL. It works well for little web servers and web services, and I've used it successfully as a client.
Have you actually demonstrated that the higher-level languages you are more familiar with just can not possibly do the job? And keep in mind both RAM and disk are cheap, so "just add more" may work if saving space is your motivation for "granular control".
Whip up a testbed in the higher-level languages you are more familiar with to simulate a load test, and see what sort of performance you get. Zero bells/whistles, just "how much of data that vaguely resembles what I'll be seeing can I shove through the pipe.
If that shows you don't get good enough performance, then try one of the tools that will generate a native binary from the higher-level language, and see if that is good enough.
Often our intuition of what can be done with these systems is off by several orders of magnitude. So make sure you really need it before you go all-native, especially because you're less familiar with all-native. For example, latency over a typical Internet connection means you'll be network-bound no matter what language you write it in, so write it in whatever you're most comfortable with.
Also, if there's particular operations that are really the bottleneck, consider writing the rest of the program in a higher level language, and writing the bottleneck in C or C++. All the high-level languages have some sort of native interface.
If you have to ask the question, it changes the answer.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
You say you need to manage the memory yourself, so I'm going to believe you. I believe this completely eliminates garbage collected languages from consideration*, and that's most languages these days. Aside from C/C++, I think you still have Rust, D, and assembly as contenders. You might be able to use Java with with sun.misc.Unsafe, but that is not really recommended.
Not knowing too much about these languages, I would tend to think Rust might be a good choice. People seem to like it. I believe legacy code bases are frequently a big consideration in the decision to use C++.
And as others have said, you might be able to write libraries in C++ and include them in a code base that uses a higher level language, like Python.
*Are there languages that allow garbage collection and manual memory management? Not sure. I believe the answer is no.
Democracy Now! - your daily, uncensored, corporate-free
We manage memory the old fashioned way: quality built software. Do we manually call new() and delete()? yep. Do we leak memory? Nope. Can I prove it? You can bet you life on it. Literally. We have proven our software will never leak memory--proven it to the point that engineers have signed off on our software certifying it for use in life critical systems. A car you drive, an airplane you fly in or a medical device used by your doctor may have our code in it.
Please tell me which airplanes have this shoddy code so I can avoid them. I've worked on avionics systems, and they do NOT use delete(), ever. That's completely against coding standards. Once memory is allocated in an embedded system, it cannot be de-allocated.
Use C (see "Programming in C" by K&R). Use C++ only if you must. C++ is better than C only if you require C++ OO or C++ GUI. New programming languages will be more obsolete than Commodore 64 BASIC in short order.
Just an infinite tape then?
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
My preferred general purpose C++ solution would be to use Qt when possible. It already has virtually everything you would use in an operating system with baseline networking, GUI, etc. already wrapped for cross-platform use in a clean, powerful way.
If you are writing a utility or a service, there are other choices. If you think you need the widest range of features, you might need a native GUI, GPU access, etc., Qt is the only real choice.
Depending on what you are trying to accomplish, Node with C++ modules provides a nice base. It is even used as the basis for desktop apps with web-based GUIs (see Atom editor https://atom.io/ .) You get Javascript scripting, full web server capability, WebSockets for bidirectional communication, etc. Nginx is another possibility for something like that.
You could use Java or C# for portable-ish apps. In some ways, Qt seems even more portable now, especially for GUI and OS-specific features. Java and C# also don't make for great UI without a lot of work, and then it tends to be sluggish. For UIs, you want either a modern web UI, or a well-designed Qt UI. Interestingly, Qt includes a modern web capability embedded. Even the native Qt GUI is styled using CSS.
For a pure server app, Java, Node (Javascript), Python (according to many), and C++ are good. PHP, because Facebook has improved it, may be OK. Perl, Ruby/Rails, Drupal, WordPress, etc. all seem to be fading for app framework use because of developments in Javascript libraries. WebComponents / Polymer SPAs are very interesting.
Stephen D. Williams
the guys that know C / ASM always seem to have a better understanding of problems in general.
Compared to what? The guys who don't understand C / ASM? Or compared to the guys who understand higher level constructs like OOP and can actually make the proper abstractions to make the code maintainable and scalable?
This is like saying "the guys who know how to pour cement and hammer nails into 2x4's (i.e. construction workers) always seem to have a better understanding of architecture". Better than who? soccer moms or architects?
The system allocates all the memory it needs at start-up. The tasks it's assigned fit into the available system memory. Since there's no such thing as processes which are started and stopped and restarted, you have no need of deallocating memory.
The fact that something is written in C++ is not evidence that writing it in C++ was a good choice. It's merely evidence that it was possible to write such a thing in C++.
There's actually quite a bit of C++ software out there that exemplifies why C++ is often NOT a good choice.
Can I prove it? You can bet you life on it. Literally.
You solved the halting problem? Awesome. Now make a bug free static analysis tool that finds all the bugs in everyone else's code, and we will live in a world where every piece software is perfect and you are the greatest computer scientist who ever lived after proving Turing wrong.
You aren't supposed to allocate and deallocate memory because it is usually not time-deterministic. But there are memory allocators that are time deterministic, but you lose some other nice features that general purpose memory allocators have.
Did you hear this some place or do you make up the bullshit as you go.
High frequency trading platforms can and have been written in Java. Java is plenty up to the task if you know how the GC works. Also stop-the-world GC hasn't been a thing for a while now.
Why only one language?
Languages are tools - you should use the right tool for the right job.
I program at work and at home and it annoys me how at work *everything* is done in C++. At home I use Python for pretty much most things, and if I need some low level fast stuff (e.g. a Monte Carlo which I do quite a bit of) then I write it in C++ and use SWIG to call it from Python.
Just because I use those languages, doesn't mean you have to. Choose the right language for the right task and stop thinking in single language terms.
+1 for Python.
If you insist on C++, start with https://www.chromium.org
Out of the box, you get integrated modern C++ libraries for networking, memory, GUI etc.
I heard it from the article "Why JavaScript On Mobile Is Slow". What about tracing garbage collection has changed in the two years since that article was published?
OTOH with a generational collector, multi-cpu/multi-thread/shared memory system, the concurrency issues rear themselves in much fewer places, and the extra CPU's can be leveraged to provide nearly pauseless GC.
When an object owns an unmanaged non-memory resource, such as a file handle, network connection, database connection, or graphics context, how are these resources destroyed? In my experience, the answer has been the dispose pattern, but it has as much conceptual overhead for the programmer as manual new and delete in C++. For example, any object that holds a reference to a disposable object after a method finishes must itself be disposable.
You solved the halting problem?
The halting problem is undecidable in Turing machines. It is not undecidable in machines less powerful than a Turing machine. I imagine that coding standards restrict programs to a model that is less powerful than a Turing machine while still powerful enough for useful work. A physical computer, for example, is closer to a linear bounded automaton (LBA) than to a Turing machine. Halting on LBAs is decidable, yet an LBA can decide any context-sensitive language.
The developers of the Python programming language tried smart pointers. But the need for reference count changes to be atomic between threads resulted in a Global Interpreter Lock, in which only one core is allowed to run Python code at once unless the task is split up into multiple processes that share nothing. And even then it's tricky to keep a forked process's copy-on-write memory from decaying to copy-on-read when a reference count in the same 4K virtual memory page gets changed.
A few suggestions:
1. If possible, do not write new code.
If there is open source that does something close use that, and update for your needs.
2. Use a language that fits the problem.
It could be nodejs for certain complex http state machines. It could be python for high level applications. It could be C or assembly for low level performance requirements.
3. Don't limit to one language. Sufficiently large applications are usually implemented in several languages. Not purely for programer preference. But because it fits. If you write 1000 lines of C++ for a task that could be done in 20 lines of python or nodejs, then you are doing something wrong.
Solving the same problem twice (in multiple languages), will often help in design but also in revealing the optimal choice.
4. Keep code modular, so you can easily replace an implementation( with a new language or new design). Modular, meaning split at a library/executable/networking boundary, not "Object oriented", which does not necessarily aide with any software engineering principal.
I disagree. In some respects, it's better. For example, it isn't just a memory management system, but a general resource management system. It's also more predictable.
However, it requires more attention, and it's easier to have memory leaks. If you have a reference-counted system with blocks of memory pointing to each other in a circle, and you lose the address, in C++ you've just leaked that memory. In a language with modern garbage collection, the collector will find nothing pointing to that memory, and collect it. Also, reference-counted pointers require an extra memory access when created or deleted.
In general, I prefer the C++ approach, but if the program isn't dealing with many resources besides memory the GC approach is usually better.
While there's some support in C++ for GC, I haven't heard of any good GC implementations.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Strange; I use arrays and structs a lot in Common Lisp. Lists are a wonderful structure for code, but in my experience most data is best handled in other ways.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Yeah, it might seem to be true, but automatic variables are simple to use and things like shared_ptr offer most of functionality of garbage collector when you actually need it. So I don't see much point in garbage collector. Other people too it seems given that there aren't any popular C++ gcs.
"I am about to start a personal project which I believe should be done in C/C++."
"I have been working in the Java / C# world for the past decade..."
Enough said
just do it. no reason to confine yourself to c. do you think oracle and microsoft and the other rdbms industry leaders would confine themselves to c if they were to write from scratch?
i think you are approaching this correctly, c++ is right for your project, i'm pretty confident.
if i could write everything in python i would, but not this.
It's GC'ed, but you can monitor memory & run GC any time you want. You're also much safer and have coroutines and a compiler which helps reduce dev-test cycles for interesting pointer things you may be doing (vs C/C++).
Science & open-source build trust from peer review. Learn systems you can trust.
Eclipse doesn't run interpreted code, unless you have done something truly awful to your install.
Linux MySQL Apache Perl/PHP/Python? ;)
Anything running on Java?
Microsoft Windows and Notepad? You can get a lot of mileage out of that.
MomentoOS (or whatever the fuck that autoerotic x86-asm OS is called)?
(Though I think these days, Perl and PHP have some C++ in them.)
--- Android is slow
- Article about Javascript
gtfo you dirtnigger faggot
The Erlang portion will be faster than anything in Python, and will be competitive with C++ you write yourself unless you are doing heavy string parsing, which Erlang does more slowly due to lack of multiple assignment. Like Python, you can code the performance related bits in C, but unlike Python, the C bits run in a supervised external process so they don't crash your program if you have a segfault in the C due to bad pointer assignment (you can actually integrate any language this way, not just C). The networking bit is all done for you and the sockets show up like little mini-processes you can monitor and send messages to/from. Because of the process model that Erlang uses, you don't have to deal with thread pooling and can handle a large number of concurrent clients in a straightforward way. There is also a cross platform gui in Erlang based on wxwidgets, but it isn't the fastest. Once I got used to it I found I could get stuff done pretty quickly.
The article explains how being garbage-collected makes V8 slow. Like V8, Dalvik is garbage-collected. What's the key difference between the two environments?
Your first priority is to finish it, and make it useful to others. Start with the language you are familiar with, and that facilitates maximum portability and compile time error detection. Once you are done, there is always an option to rewrite performance critical parts in native code. With C/C++, there is always a chance of memory corruption in your own code or libraries you are using. It may never manifest on your development system, but affect other users and other platforms.
Unless of course your primary motivation is to learn another language. Then go right ahead, but don't expect maximum productivity.
Golang sounds like a fit. Take a look.
I didn't read your entire post, but since you said "in practice" 5 times, implying that your post is a slam dunk, I'll just assume that you're right.
You're talking about what we would call "managed blocks" in the systems we used. We didn't have malloc even, we literally just had a block and a pointer to the head and we'd write our own new and delete functions that would just mark or unmark sections of a map.
There are however plenty of systems that do have native new and delete that are specifically written as RTOS embedded systems. EG: ITRON which is found in a lot of automotive [sub]systems.
Generally though most embedded systems set up their memory statically, like you pointed out. Parent poster here however is referring to a media system where some blocks (like display buffers) would be static there are probably many different modes so not a single function application and not something where one globally static map would fit all cases.
Wait, you're not using the stack? ;)
Ok, back to serious mode - I'm working on small embedded stuff, and memory is either allocated statically or it's on the stack in the form of local variables. new/delete/malloc/free don't appear in my code, either.
Java/C# = Automatic Transmission
C/C++ = Manual Transmission
Assembly = smelting and casting metals to create your own custom designed gearbox
For many applications Automatic is fine. You just care about making it work and performance is "good enough" that you don't sweat it. For performance sensitive applications you need finer tuned control and yeah, the safeties are off, but they're not slowing you down either.
A few years ago, when I was compiling all software for my personal workstation myself (LFS) as a learning experience, I actually did that. C++ was too big a hassle for too litle gain.
After a while during a reinstall I disabled g++ and only installed programs written in C or other languages. It was no big deal actually, opensource C++ projects feel huge and sloppy compared to the rest.
Was it really only "a few years" or are you forgetting how long it has been (easy to do)? was this machine a fully functional workstation (including stuff like web browsers and if so which web browser)? or was it just a toy/special purpose box?
A few years ago gcc itself switched from C to C++ https://lwn.net/Articles/54245... . Both of the two main web rendering engines (geko and webkit) are C++. One of the two main desktop widget sets is C++.
I agree C++ has it's problems, templates look good in microbenchmarks but can easilly blow up code size. Memory requirements for linking large C++ projects can be horrific but the fact remains C++ is far more widely used and supported than any other object-orientated native-compiled language. It's position may not be quite as important as C but it's not far off.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register