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.
You can pick one of the two and make no promises about the other.
Or does "cross-platform" in this context mean "Linux+Windows"?
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 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.
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..
Objective C is more readable and easier to debug than C++. However on Linux it is a mess. GNU's implementation is not good.
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!
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.
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.
All true, except that C++ makes some things so much easier? Need a linked list of variable length strings that will be updated? vector in C++. In C you'll be rolling your own linked list and managing your own char* array memory using realloc(). Not hard for an experience C programming but still a lot messier than the C++ equivalent.
"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.
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
Can you hear it, my son? This is the voice of ignorance.
Mod parent up!
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.
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.
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!
I am getting up in years, but find it interesting that no one mentioned COBOL but me. :)
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.
std::vector is an array--not a linked list. For list, use std::list, or even better: boost::instrusive::list.
Goodbye Slashdot. You've changed.
C++ is the best language for garbage collection because C++ makes so little garbage.
For a list use LISP.
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.
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.
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.
ADA is the Americans with Disabilities Act or the American Dental Association. The programming language is called Ada.
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
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
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
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).
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.
Not necessarily. For many programs "good enough now" beats "completely correct when I no longer care about the result". For instance, many games cut corners when rendering graphics in order to increase speed. Does it really matter that a shadow is off by a couple of pixels if the alternative means the game will not run on a laptop at playable speeds?
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.
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.
No, just NO.
From a performance perspective, you immediately run across thunking between C# and C++/CLI, not to mention the API idiocies like not being able to sent a buffer from C++ to the network directly (you have to write a loop and send integer sized chunks at a time, then at the end send the final few bytes).
So unless you want to screw yourself well, just avoid C++/CLI. You'll thank me later.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
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.
That's because Ada was named after a person, a woman known generally as "Ada Lovelace" (she was a noble in the early 1800s, her full name is really long). Java was named after either an island or a type of coffee or both. Python was named after a snake. PHP is an acronym, which originally stood for "Personal Home Page". Acronyms are generally written in all-caps; that's why it's written that way.
Just an infinite tape then?
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
The thing you're missing here is library support. Modern programming makes use of lots of libraries (esp. for things like GUIs), and really new languages may not have the library support that a mature language enjoys.
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 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.
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.
So I agree with your point but I think you missed the point of the previous point. However, correctness isn't limited to: "Did I adhere exactly to the mathematical definition of what I am trying to implement?"(in your case a shadow). But did my code match my intention or specification. No one will write a game, see it chug along at 2 frames and say "Well, at least that shadows nice..." Part of the spec, whether it is written or not, is the expectation that a game will run at a playable frame rate. Therefore, the slow implementation does not conform to a programmer's definition of correctness. //do some expensive computation, or some other thing that was not intended
}
Instead, I think the previous poster was implying that some tools and languages have subtle behavior that make it easy to make mistakes.
E.g. If my language allows things like (where = is assignment):
if (debug = true) {
Then it might lead to fewer correct programs.
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 agree with you. Tools should facilitate correctness.
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.
You can also do this in C#, although to make it cross platform compatible you'll have to write a PCL to implement the memory management on each platform as the P/Invoke code won't be portable.
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.
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