Guess what? Cold places use MORE energy than warm ones. While people like to hate on ACs as some excess, they are actually quite efficient. Since they move heat, they can move more energy than they use. A good AC can easily move 3-5 watts of heat for each watt of energy it requires to operate. No such luck with heating systems, they at best get you 1 watt of heat for each watt they take.
Actually here in Denmark many people use "jordvarme", which google translates to geothermal, which it is _not_. It is a AC turned around: you pump heat from the colder ground under your garden into your house using less electrical energy than the heat energy you get into your house. The efficientcy is better than 1:3.
Quite often I define a method as a template over one of the parameters. Then as it calls another method etc I can specialize. Forinstance, if I have class hiracy with Object at top, I could write a method called foo(Object *obj) {....} , or template foo(Obj *obj) {
Another examble is building classes consisting of one of more objects, which will differ. Doing it the OO way, you will need to do class Foo { Interface *mSomeObject;
I have done so as for special cases, but in most cases stl works just fine. In the past it has been buggy but that was 10-15 years ago - and more so in embedded environments.
When I started at my current job 7 years ago I came from C and C++ to Java. I liked Java a lot. We had a little bit of C++ and C utilities but our main application was Java.
Then we needed something running realtime and I went back into C++. It took quite a while to make a relative simple application because I had to start from scratch with basic network and serial interface handling. Also I had to make an interface protocol to speak with the rest of the application writen in Java.
Then we started another much larger add on which needed high performance. C++ was the only realistic choice. I estimated the time to write the code would be 3 times that of our prototype written in Python. I was wrong! It is hard to meassure because the prototype and the production code did not do the same thing, but it certainly did not take 3 times the efford to write it in C++ than Python. And compared to Java it was not much harder to write it in C++. Debugging might be a be harder, but we have no problems with memory leaks, segmentaion faults and other memory issues being the usual problems haunting C++. And note: Java and Python also have memory leaks due to dangling references. These can be very hard to find, too.
C++ is not 3 slower to write code in than Java and Python as I expected. It is almost 1-1 - as soon as you have written the framework of your application. One of the major design rules which definitely helped us was: Avoid multithreading ! Instead our application is split in processes, communicating with sockets. Each process is a loop around a select() call. The split in processes makes it much easier to spot errors. Each process is run in a while loop in a screen such the system can recover from a crash of one of the processes.
We avoid memory leaks by using (now deprecated, I know) std::auto_ptr. It is implicit in our code that the owner have the auto_ptr, while all others jave a plain poitner to the object. The owner have it as a auto_ptr. shared_ptr are rarely needed.
Another thing: We write Java like rather than C like C++: We do not use pointer arithmetic. We use STL or our own containers. We avoid unsafe typecasting. We try to code against interfaces rather than implentations and all the other best practises of object orientated programming. Stuff you only learn properly by coding Java or another OO language.
The network handling in the C++ parts worked almost flawlessly, old bugs keeped appearing in the Java network code. This was because Java per default rely on thread for everything: Befoe select was added to Java you needed a thread for reading a thread for writing for each TCP connection. And getting the threads to work together quite right is hard - in any language. Then it is easier to have one thread and events when the socket changes state.
The major issue with C++ over Java and Python: "Batteries are not included". And no STL is no near the standeard libraries in Java and Python. Not even boost gets close. But in our case, once we had the basic eventdriven framework with sockets and buffers, connection handling build up of logical classes around a select loop it was easy to add new functionality. C++ is not good for writing large monolithic applications because it can be very hard to localize errors - Java handles that much better because it is much easier to localize errors. But Java (and Python) still uses way to much memory when you represent data as objects.
Another thing C++ has is ofcourse templates. It is a really good alternative to object orientated techniques for writing re-useable, generic code. The good thing is it all bindings happens compile time. That means both that many errors are caught compile time, and that the compiler can optimize seemingly very expensive code. When calling a virtual function in an interface the compiler very rarely can figure out which implementation it really is and do optimizations.
All in all: C++ is a good, powerfull and high performance language - but it requires a lot of decipline from the developers (especially when dealing with pointers) to avoid the usual deathtraps in C++. By now I like C++ better than Java. Java was a disappointment for me: You end up with a lot of threads. Garbage collection is not fail-proof against memory leaks anyway. The seemingly ease of writing code in Java only fools you: The code ends up having many bugs but the application can "limb on" even though one thread have thrown say a FloatingPointException.
If LLVM had not been under a BSD license they wouldn't have used GCC, it's corporate poison, they would have rather licensed Intel's C compiler or something and the community would have gotten absolutely nothing.
WRONG: They used GCC and contributed back to the project. But as far as I understood, FSF and RMS stopped accepting their patches because of dislike of Apple. Not really GPLs fault, but FSFs centralized "community" model.
There is nothing wrong using GCC under GPL in a coorporate context. We do it at work all the time. I worked with VxWorks. Wind River sent us a version of GCC (and binutils, gdb etc) as part their development kit and IDE. Nothing wrong with that.
What is wrong with the GNU project is _not_ GPL, but the copyright handover and centralized control, which have a tendensy to impose political constraints on projects. Things like the Linux kernel and git works a lot better under GPL but out of FSFs control.
You have totally misunderstood than man: He has nothing against "for-profit." He is against closed source. He want to let everybody to have the freedom of controlling, modifying and hacking their own devices - and sent usefull programs to your friends with no commercial license stopping you. That is the freedom GPL is designed to protect. It is not some "socialist", anti-capitalist ideology, but fighting for freedom of the individual hacker over cooporate profit.
8 Catfish = 1 Octo-puss