Slashdot Mirror

Thanks for taking the time to reply.

Ad hominem fallacies aside (*) that doesn't change the fact that some programming languages are total shit.

What is THE purpose of a programming language? To communicate with a machine. You can communicate in an obtuse way, verbose way, in a precise way, in an ambiguous way, etc. There is a range of QUALITY. There is poor communication and there is good communication.

The reality is that ALL programming languages suck -- some just more then others. One of the properties of a good programming language is that it is consistent. i.e. See PHP is a fractal of bad design

> Sometimes I think you just hate any language that's actually useful ...

IF I was idealist I wouldn't use any programming language -- but that is not realistic. I'm a pragmatist -- things need to get implemented in the Real World TM. However, that doesn't mean I'm going to just blindly accept and ignore the problems of a language.

> ... extremely useful JavaScript ..

Let's talk about Javaschit.

Is it useful? Yes! It has become the new BASIC of the millennium. It is ubiquitous.

I'm NOT against useful languages -- I'm against the BAD DESIGN and IMPLEMENTATION of them.

Do you know how many man years are wasted tracking down bugs simply due to misspelling??? All because the language designer was too fucking lazy to make the KLUDGE "use strict"; the DEFAULT. It's as if NOTHING was learnt from the experience of BASIC. Gee, if only the computer could tell us about misspelled variable names, oh wait, they can! Good engineering is about FAIL EARLY. Javascript was never designed with that mindset -- it was literally hacked together in 10 days. And 20+ years later we are STILL paying the price.

On the other end of the spectrum we have over-engineered shit like Boost where a simple to Read and Write ~25 lines implementation of CRC32 turns into 1,100+ lines of Crap++. WHEN was the last time you _actually_ needed to modify a CRC implementation??? If you need a stronger hash than CRC32 then, chances are, you are probably using a DIFFERENT hash such as FNV, SHA1, etc. due to a) performance, or b) more cryptographically secure (i.e. less collisions.) reasons. The Boost guys have become so obsessed over one little tree that they COMPLETELY missed the entire fucking forest.

Let's talk about C. It was a stupid decision to default every function as returning int. Why wasn't the return type mandatory? Having to run a "lint" program is a SYMPTOM. So why wasn't the CAUSES addressed?

Let's talk about C++. We are STILL waiting for modules -- something that has been standard in Pascal for 35+ years! Why aren't error messages _standardized_ ?? One of the few things MS Visual C++ does right -- is to provide an unique error code. This makes it easier to search for solutions. Go figure!

I am extremely vocal about shitty engineering practices because I'm tired of having to deal with other people's retarded designs and waste MY timing tracking down WTF is wrong with their broken, inconsistent, implementations.

If nothing is ever said about WHY said designs are crap then nothing will ever change.

I am only one voice out of many saying WHY PHP sucks (When even diehard PHP users say PHP needs to die you know there is a problem.)

People who use PHP are either ignorant, stupid, lazy or some combination of them. But that should come as no surprise -- it was designed for non-programmers. Gee and is there ANY wonder it has problems when any decent prog

Serious question: What languages and frameworks are you going to use to compile to your web assembly?

C++ code, probably with boost although it isn't a requirement; CMake for a cross platform build system, emscripten or clang to do the actual compile to wasm

> Boost

Uh, a complete clusterfuck of 1,109 lines of over-engineered Crap++ is NOT the way to sell this. Just saying.

ArgoUML

ArgoUML is the leading open source UML modeling tool and includes support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten languages. See the feature list for more details.

Bongo

The Bongo Project is creating fun and simple mail, calendaring and contacts software: on top of a standards-based server stack; we're innovating fresh and interesting web user interfaces for managing personal communications. Bongo is providing an entirely free software solution which is less concerned with the corporate mail scenario and much more focused on how people want to organize their lives.

Boost

Boost provides free peer-reviewed portable C++ source libraries.

Boost emphasizes libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.

Boost aims to establish “existing practice” and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2.

Bro Network Security Monitor

Bro provides a comprehensive platform for network traffic analysis, with a particular focus on semantic security monitoring at scale. While often compared to classic intrusion detection/prevention systems, Bro takes a quite different approach by providing users with a flexible framework that facilitates customized, in-depth monitoring far beyond the capabilities of traditional systems. With initial versions in operational deployment during the mid '90s already, Bro finds itself grounded in more than 20 years of research.

Buildbot

Buildbot is a freely-licensed framework which enables software developers to automate software build, test, and release processes for their software projects. First released in 2003, Buildbot is used by leading software projects around the world to automate all aspects of their software development cycle.

BusyBox

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

Clojars

Clojars is a community-maintained repository for free and open source libraries written in the Clojure programming language. Clojars emphasizes ease of use, publishing library packages that are simple to use with build automation tools.

coreboot

coreboot is an extended firmware platform that delivers light

Oh come on, at least use boost::filesystem -- which anyway looks on-track to be part of C++20 standard libraries.

I assume you're smart enough to re-implement a filesystem library even though Boost already did it. And then you're smart enough to extend it to cover all the cases. Smart enough to fix any subtle bugs that come up. And you'll end up in the same place that they ended up with -- with a library that deals with all the platform-specific filesystem details and abstracts it up into a nice interface with common idioms.

But is that software development or masochism?

What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon).

Given that boost::filesystem is landing in C++17 it is not much of a stretch to expect the network counterpart to follow in C++20. Networking is considerably more complex than filesystem access especially with the asynchronous element, so it will be better for everybody if they take their time and bake it well. Meanwhile, libc provides everything that 99% of networking applications need, in a mature and powerful form.

Maybe someday someone will figure out how to use C++ in a clean, nice looking style. Then I'll use it. Until then, I'm staying away.

You may also make suggestions and contribute to shape the next iterations of the C++ standard...

Personally, I really like what has become of C++ since C++11, and I'm seeing that C++17 is getting some real nice additions in the Standard Library too. What I'm still missing though: standardized networking (Boost.ASIO looks like a monster at this stage, don't know if that would or even should make it into the ISO standard anytime soon). Missing networking is a big minus IMHO. I also consider the difficulty of writing more specialized streams, e.g. for encryption etc. a small minus... but that may only be me not yet grokking enough the iostreams / streambuf library design to extend it that way.

Save for that, C++11's style and philosophy is something you get used to after a while. It takes some time to finally "get it" and get the hang out of it. That's not just a couple of syntactic rules and keywords and weird ways to write templates and template specializations and throw in iterator flavors everywhere where you don't expect them to come up, it is more than that. Once you finally reach some stage of enlightenment, you'll start to really like C++ and will start coding in it as it was supposed to be and designed to be. I know, it sounds like a pathetic excuse for not being easily accessible...

There's still no std::string split() method.

It's in boost. http://www.boost.org/doc/libs/...

> Just look at all of the shitty, shitty code that's out there.

Sadly the two biggest pieces of shit, PHP and Javascript, have the most crap code.

> What's worse is that they'll try to blame properly trained professional programmers for this shitty code.

What's worse is over-engineered code supposedly written by professionals.

i.e. Look at C++'s Boost's CRC complete clusterfuck.

HOLY FUCK. 1109 lines of over-engineered C++ shit for a simple CRC32 function when a mere 21 lines of code would solve 99% of the problem!?!?

When was the last time you needed a custom CRC hashing function??

Here are the "de facto" easing functions in Javascript. Look at this over-engineered garbage:

easeInElastic: function (x, t, b, c, d) {
        var s=1.70158;var p=0;var a=c;
        if (t==0) return b; if ((t/=d)==1) return b+c; if (!p) p=d*.3;
        if (a < Math.abs(c)) { a=c; var s=p/4; }
        else var s = p/(2*Math.PI) * Math.asin (c/a);
        return -(a*Math.pow(2,10*(t-=1)) * Math.sin( (t*d-s)*(2*Math.PI)/p )) + b;
    },

WTF? This can be written simply as:

easeInElastic: function (x, t, b, c, d) {
        t /= d;
        if (t <= 0) return b ;
        if (t >= 1) return b+c;
        t -= 1;
        return -(c*Math.pow(2,10*t) * Math.sin( (40*t-3) * Math.PI/6 )) + b;
    },

Which is still obnoxious compared to the simple one parameter version:

easeInElastic : function(p) {
        var m = p-1;
        if( p <= 0 ) return 0;
        if( p >= 1 ) return 1;
        return -Math.pow( 2, 10*m ) * Math.sin( (m*40 - 3) * Math.PI/6 );
    },

BASIC, JavaScript, PHP, C++ are only part of the problem -- you can write shit in any code -- it is the mindset of people abstracting everything until it is completely over-engineered where it becomes job security.

Almost no one gives a dam about writing clean, simple, code and taking pride in their craft.

Oops! Posted this before logging in. Anyway, hope you find a good solution that fits your needs. To get Shenidam working, development packages and boost libraries must be installed before it complies successfully. Once it works, you can write a bash script and do things in batches and bring in other utilities like avconv / ffmpeg / sox, etc. as needed to for instance, convert a left-channel-only audio to true mono / stereo.

You said that it should be cross-platform, which rules out C#, IMHO

Also consider that, if you go for C++, you'll have to compile it for each platform.

Maybe you can have a C++ library that deals with memory and do the rest in a language you're more familiar with? e.g. using Boost.Python to interface with... well, Python.

There are similar solutions for Java and other high-level languages (in general I tend to avoid mixing languages but sometimes it's a necessary evil).

Let's let at the clusterfuck of Boost's CRC code
1109 lines of over-engineered C++ crap for a simple CRC32 function!?!?

Now compare that to these simple 27 lines of C/C++ code.

#include <stdint.h>
 
const uint32_t CRC32_REVERSE = 0xEDB88320; // reverse = shift right
const uint32_t CRC32_VERIFY = 0xCBF43926; // "123456789" -> 0xCBF43926
/* */ uint32_t CRC32_Table[256] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 }; // i.e. 0x00000000, 0x77073096,
 
void crc32_init()
{
  for( short byte = 0; byte < 256; byte++ )
  {
      uint32_t crc = (uint32_t) byte;
      for( char bit = 0; bit < 8; bit++ )
          if( crc & 1 ) crc = (crc >> 1) ^ CRC32_REVERSE; // reverse/reflected Form
          else /* = 0*/ crc = (crc >> 1);
      CRC32_Table[ byte ] = crc;
  }
  if( CRC32_Table[8] != (CRC32_REVERSE >> 4))
      printf("ERROR: CRC32 Table not initialized properly!\n");
}
 
uint32_t crc32_buffer( const char *pData, uint32_t nLength )
{
  uint32_t crc = (uint32_t) -1 ; // Optimization: crc = CRC32_INIT;
  while( nLength-- > 0 )
      crc = CRC32_Table[ (crc ^ *pData++) & 0xFF ] ^ (crc >> 8);
  return ~crc; // Optimization: crc ^= CRC32_DONE
}

Typical bloated code solves some theoretical "general purpose" solution. Good code does one thing well:

It communicates clearly what it is trying to do.

_When_ was the last time you actually needed a different CRC function from the standard 32-bit one?

>Debugging has always been a problem. One of the other posts here suggested using CLANG because of it's better error reporting. Thats right now, after 25 years. Let's face it, C++ is legendary for the obscurity of it's compile and link time error reporting. Beyond that, it's not like the run time debugging environment is any better. All that it supports is the kind of break point debugging that was in C. No value added beyond K&R.

This is true. I teach introductory computer science using C++, and one of the biggest hurdles for my students is understanding the error messages from the compiler. Half the time they don't mean anything unless you already know what it's supposed to mean.

And that's before even getting to templates. Once you get into templates... /shudder. The error messages are insane.

I tried compiling the rather simple boost program from the "getting started" section here: http://www.boost.org/doc/libs/...

Without the proper library linked in (i.e. just doing a "g++ test.cc"), I get 38 lines of vomit that look like this: .text._ZN5boost11 basic_regexIcNS_12 regex_traitsIcNS_16cpp_regex_ traitsIcEEEEE6assignEPKcS7 _j[_ZN5boost11basic_ regexIcNS_12regex_ traitsIcNS_16cpp_regex_traitsIcEEEEE6assignEPKcS7_j]+0x22

(e.g., pre-allocating memory as you are, using temp variables that don't get deallocated, overloading operator+= operations to avoid hidden allocation and copy operations, etc.)

You probably already know this technique, but just in case: you can avoid a lot of temporaries with Expression Templates.
The technique is used in boost.uBlas

Something I got wrong: looks like the replacement for is_initialized() is to explicitly cast to bool, using static_cast.

What I don't get is this: suppose Dog inherits from Eater and Walker. If I have a vector of pointers to Eater objects, and I add a pointer to a Dog instance to that vector, and I call eat(dogFood) via that pointer, how can the vtable handle both the Eater and Walker member-functions? Surely they each have an idea of which member-function pointer belongs in which index of the vtable. If we have two vtables, surely we mess up the offsets for one of them. Or do we just bounce all the calls for Eater through a trampoline to handle the offsets?

Looking at Boost.Optional...

Boost.Optional's is_initialized() is now deprecated, presumably you're meant to just implicitly cast to bool now.

Apparently there are some pretty major compiler-compatibility issues with Boost.Optional, including the latest Visual Studio compiler, and GCC 4.5 (but not newer GCCs, happily).

Some StackOverflow discussion and toy examples.

What I don't get is this: suppose Dog inherits from Eater and Walker. If I have a vector of pointers to Eater objects, and I add a pointer to a Dog instance to that vector, and I call eat(dogFood) via that pointer, how can the vtable handle both the Eater and Walker member-functions? Surely they each have an idea of which member-function pointer belongs in which index of the vtable. If we have two vtables, surely we mess up the offsets for one of them. Or do we just bounce all the calls for Eater through a trampoline to handle the offsets?

Looking at Boost.Optional...

Boost.Optional's is_initialized() is now deprecated, presumably you're meant to just implicitly cast to bool now.

Apparently there are some pretty major compiler-compatibility issues with Boost.Optional, including the latest Visual Studio compiler, and GCC 4.5 (but not newer GCCs, happily).

Some StackOverflow discussion and toy examples.

The idiomatic C technique is to have one function pointer per virtual function in the class as a member.

Is that how GObject works?

I admit I never really 'got' vtables. How they handle multiple inheritance still doesn't make sense in my head.

You get the condition that all code you look at can assume the class is in a vaild state. It makes code much simpler to read and write.

I'm a fan of that. I'm not a huge fan of being forced to use exceptions, though. The fact that the LLVM coding standards forbid them on performance grounds has to count for something.

Even without that in C, you have to remember to call that macro to initialise things every time. Each time is an opportunity to forget and there's another bug.

Indeed, unless you macro-horror your way out of the chance to forget.

If you want to not use exceptions, you can add a validity flag to the struct which you have to test and/or add a .init() method which runs any code that might fail on construction. It's more verbose and possibly slower than using C++ properly.

Vaguely related: the rather neat Boost.Optional library. There's no way to make it 'safe' and implicitly check against use of uninitialised objects, annoyingly (though you can query it manually), but the machinery seems to be there.

What is the compile-time-friendly subset?

constexpr. The subset was grown considerably in C++14.

Its primary remaining use is conditional compilation. That hardly counts as a language.

Well, no, it does count as its own language, because... it is. If you grant that the preprocessor is, at least. It's clearly separated from the C++ 'core' language, and it's something non-trivial that a C++ programmer needs to know about. Much like the preprocessor.

There are plenty of neat tricks to be had with the template system that aren't really just conditional compilation. Type traits, static-asserts, Boost.Function and Boost.Bind spring to mind.

What is the compile-time-friendly subset?

constexpr. The subset was grown considerably in C++14.

Its primary remaining use is conditional compilation. That hardly counts as a language.

Well, no, it does count as its own language, because... it is. If you grant that the preprocessor is, at least. It's clearly separated from the C++ 'core' language, and it's something non-trivial that a C++ programmer needs to know about. Much like the preprocessor.

There are plenty of neat tricks to be had with the template system that aren't really just conditional compilation. Type traits, static-asserts, Boost.Function and Boost.Bind spring to mind.

What is the compile-time-friendly subset?

constexpr. The subset was grown considerably in C++14.

Its primary remaining use is conditional compilation. That hardly counts as a language.

Well, no, it does count as its own language, because... it is. If you grant that the preprocessor is, at least. It's clearly separated from the C++ 'core' language, and it's something non-trivial that a C++ programmer needs to know about. Much like the preprocessor.

There are plenty of neat tricks to be had with the template system that aren't really just conditional compilation. Type traits, static-asserts, Boost.Function and Boost.Bind spring to mind.

Boost multi_array is pretty powerful and supports all sorts of slices.

Some languages do have what you want, e.g. F#. Others allow this to be done as a library, like C++.

But this feature is sufficiently niche that I wouldn't expect it in PHP.

Maybe you should read stuff from people who actually program:

http://www.utf8everywhere.org/

Here is some actual comments from boost developers:

http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/recommendations_and_myths.html

Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html

Long discussion with many points of view (including yours) but I hope this convinces you that there is disagreement with you:

http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful

Here is somebody trying to patch boost to handle unicode by supporting UTF-8:

http://sourceforge.net/p/tinyxml/patches/54/

We're using Boost Multi-array as a multi-dimensional array, so that's not really a problem. And since we call back the original Fortran code users are still free to use their original libraries (some restrictions apply -- not all of these libraries will be able to handle the scale of current supercomputers).

Regarding the speed issue: yeah, that's nonsense today. It all boils down writing C++ in a way that the compiler can understand the code well enough to vectorize it.

Good points - in fact in this case one can say that ALL of the calculations done by the different computer architectures are in fact wrong. to varying degrees When doing floating point math without rounding analysis being done then all bets are off. Measurements always have accuracies, and floating point math also adds it's own inaccuracies.

The Boost library can help: http://www.boost.org/doc/libs/1_54_0/libs/numeric/interval/doc/interval.htm

Of course all this extra interval management costs in terms of development and performance. But what is the cost of having supercomputers coming up with answers with unknown accuracy?

Once again, Boost comes to the rescue! Provide a couple of operators, and it fills in the other ones you may want. Very well thought out, as most Boost libraries are -- for example, NaNs mean floating point numbers can't necessarily be given a strict ordering, so they provide "partially_ordered" if you need that.

When it comes to efficiency, compilers are remarkably capable these days. I just ran a test with GCC 3.4.5. It optimized "a < b || a == b" to the exact same as it generated with "a <= b" (at -O1). Source code available on request, but just try it yourself.

The lesson here: never make assumptions as to what is most efficient until you actually compile and see what happens. Instead, give the programmer the tools to make the code readable and maintainable, and then fix inefficiencies as you find them. "Premature optimization is the root of all evil." (Donald Knuth)

You can already do that in C++. There's also a Boost library that offers a bit more flexibility.

seriously? The getting started guide is really straightforward, and even has examples embedded into it to let you know if you've set everything up correctly. I can understand someone griping about the build process, but that's hardly specific to boost. Your inability to get started with it might reflect more on you than boost....

Boost has on the order of 100 libraries , each of which undergoes a peer review
CPAN allows anyone to upload their own code and has on the order of ~120,000 libraries.

Boost is a lot less like cpan and more like the development branch of the next standard library.

Get ready to cream your pants:
http://www.boost.org/doc/libs/1_52_0/doc/html/boost_units/Examples.html#boost_units.Examples.DimensionExample

and http://se.ethz.ch/~meyer/publications/OTHERS/scott_meyers/dimensions.pdf

In C++, in addition to exceptions, boost::optional is useful:
Boost Optional

http://www.boost.org/

But I #include all of http://www.boost.org/ for good justice. . .

"No connotation of stealing. Perhaps you're thinking of "boost"?"

Nope. Boost is free! No need to steal it.

I run a recent Dell T3500, 24GB RAM and dual GTS450 graphics cards. The extra cores help a lot with Adobe After Effects. A. LOT. Not so much with Adobe Premiere, because you get far more bang for your buck with a medium-to-high end NVIDIA graphics card: Premiere makes excellent use of CUDA, particularly for encoding. (By default, Premiere will only see and use "pro" cards: Quadro, Fermi, Tesla. There is an easy configuration hack that lets it use any 200 series or better card. My GTS450 encodes full 1080 HD in real-time. ) There is a caveat there: only for encoding in the foreground, and it only uses a single NVIDIA graphics card: SLI does not matter.

I find it strange the the foreground encoding uses GPU acceleration, but batch encoding does not. So the extra cores would help you there, too.

In my programming, (large scale network simulation, real-time audio processing) any cores beyond 2 do little to nothing. When I re-compile the latest version of Boost, the extra cores substantially speed the build, but this is something I only do 2-3X per year.

There is no STL_LOCK.

Go tell that to to the originators of the STL, SGI. They would disagree.

you bother with the STL because it gives you proven, tested high-performance code

The boost STL documentation makes the point that it is NOT aimed for high performance

http://www.boost.org/doc/libs/1_43_0/libs/math/doc/sf_and_dist/html/math_toolkit/main_overview/perf_over.html

By and large the performance of this library should be acceptable for most needs. However, you should note that the library's primary emphasis is on accuracy and numerical stability, and not speed.

... as for ...

Why bother writing a vector-class when you have std::vector

... because I can write my own that does ONLY what I want for that particular application, doesn't include any other baggage, and as a consequence is easier to debug. Knowing exactly what's going on "under the hood" is never a bad thing. Why are you defending "dumbing-down"?

The thread-safety of the circular_buffer is the same as the thread-safety of containers in most STL implementations. This means the circular_buffer is not thread-safe. The thread-safety is guarantied only in the sense that simultaneous accesses to distinct instances of the circular_buffer are safe, and simultaneous read accesses to a shared circular_buffer are safe.

If multiple threads access a single circular_buffer, and at least one of the threads may potentially write, then the user is responsible for ensuring mutual exclusion between the threads during the container accesses. The mutual exclusion between the threads can be achieved by wrapping operations of the underlying circular_buffer with a lock acquisition and release. (See the Bounded Buffer Example.)

So managing a collection such as a thread_pool or gather/scatter array requires locking.

And suppose you're going through multiple parallel containers (what python calls "zip")? Then the new sugar doesn't work except for one container.

The sugar is meant for a simple case, just like Python's "for". When you need something more complicated, then - again, as in Python - you use a library solution. In case of zipping two sequences together, you'd use a zip_iterator. In general, you can also simplify many STL patterns by using Boost range library.

And STL is unwieldy mainly because of the need to explicitly spell out types everywhere. With auto in C++0x, most STL operations are much more concise.

'High level' does not mean a language is 'new.' (Technically, C is a high level language.) Higher-level languages predate most others. Semi-random example: ML and derivatives (SML, Haskell, OCaml, et cetera).

And C++ is probably one of the highest level languages you have ever seen. Java, by comparison, doesn't even come close to it. But typically, only expert library authors are wielding C++'s full potential. In common use, C++ is used as a less descriptive Java.

'High level' does not mean a language is 'new.' (Technically, C is a high level language.) Higher-level languages predate most others. Semi-random example: ML and derivatives (SML, Haskell, OCaml, et cetera).

And C++ is probably one of the highest level languages you have ever seen. Java, by comparison, doesn't even come close to it. But typically, only expert library authors are wielding C++'s full potential. In common use, C++ is used as a less descriptive Java.

'High level' does not mean a language is 'new.' (Technically, C is a high level language.) Higher-level languages predate most others. Semi-random example: ML and derivatives (SML, Haskell, OCaml, et cetera).

And C++ is probably one of the highest level languages you have ever seen. Java, by comparison, doesn't even come close to it. But typically, only expert library authors are wielding C++'s full potential. In common use, C++ is used as a less descriptive Java.

Erlang sucks. C++ and Boost.MPI is better.

...OK just kidding. Erlang's a neat language. C++ is one of those things you wouldn't wish on your worst enemy, although it's occasionally very interesting what people achieve with it. I hope more programmers will throw aside their initial fear and learn how fun (and easy) functional programming really is.

I don't know if GC uses refcounting at all, though I suppose it's possible.

However, the point is that the reference counting itself isn't just the extra bytes of RAM, it's the extra bytes of CPU cache. It's the difference between a chunk of your program fitting in cache and running insanely fast, then being paged out for GC to run (and GC sits in cache during its run), and that same program needing the refcounting, malloc/free, and a bunch of other housekeeping stuff always hot in cache, meaning it's likely your program will have to have chunks of it paged in and out of cache much more often.

Actually, ref-counting is mostly just the extra few bytes. An auto_ptr (or a unique_ptr or a boost::scoped_ptr) doesn't even use the extra bytes because it has single ownership. When they go out of scope, the object is destroyed. No extra byte; no complicated memory management. The C++ compiler knows when the object goes out of scope and will call the destructor at that time.

For boost::shared_ptr, there's extra memory for reference counting because there can be multiple owners. But, again, I'd be surprised if a GC-based language wouldn't use reference counting. Perl, for example, uses reference counting exclusively *because* it's much faster than other schemes. It has the same drawback that C++ has which is that circular references may leak.

Paradoxical, and I'm not convinced, so I'd want to benchmark it. It does seem plausible, and I did read it in a respectable-looking paper.

If you have a link to that paper I'd like to see it. As I said, there's not much more to reference counting other than incrementing a value when the object is assigned a new owner and decrementing that same value when it's being released. The allocation is done once and there is a single delete.

So no, I wasn't talking about the GC keeping anything "in memory" (as opposed to what?) -- yes, once the object isn't referenced, its data is meaningless.

And yes, I'm pretty sure malloc/new implementations have, at least at one point, been direct system calls. I imagine they still are, on some embedded platforms.

I've programmed in C and other procedural languages, Pascal for example, for a long time. I've never seen a single implementation that would make a system call for each malloc/free call. If you know of one, again, I'd be interested to have a link.

When you're starved for memory, it makes sense -- you want everything free'd for other processes to use as soon as you possibly can.

When delete is called (or free in C), the memory used by the object is made available immediately. This requires a call to the C or C++ library, if that's what you mean, but this is not a system call. It doesn't require an intervention from the OS except, maybe, in a multi-threaded application. If this library call is what you mean by "system call" then yes it has some overhead. I have heard of implementations of new/delete that accumulate the delete in order to gain a few extra cycles. But when you need these extra cycles you probably should be programming in C++.

Good to know about boost -- though now I'm curious what the difference is.

here

Boost is really much more than template programming. To get the most out of it, it helps to understand the more general concepts of meta-programming and generic programming. C++'s template system just happens to be how you use those paradigms in C++.

Here's a good overview of generic programming:
    http://www.boost.org/community/generic_programming.html

Dave Abrahams' book is a good intro to template meta-programming:
    http://www.amazon.com/Template-Metaprogramming-Concepts-Techniques-Beyond/dp/0321227255

I've also found Python to be a great language for learning both concepts. While you won't get all the performance benefits of C++, Python's rapid development cycles make it easy to play around with the both techniques.

-Chris

It sounds like the Boost project might be something for you:

http://www.boost.org/

You really have to wonder what the serve in the cafeteria for EVERY product they make to be so universally terrible.

It's funny because as someone who fully shares in your opinion, I was completely perplexed when I examined Adobe's Boost-licensed image processing/manipulation library GIL, which is not only superbly designed but one of the best modern C++ libraries I've ever seen; A lot of thought went into making it very fast, without sacrificing its 'genericness.'

So while I guess you can call most of Adobe's product implementations shitty, particularly Flash's, Adobe does actually have respectable programmers working on at least parts of Photoshop. I don't think Photoshop itself is a great product either, but my complaints for it are centered more around its consistently bad UI and poor platform integration.

C++ only becomes slower if you use certain features that have a performance impact.

And virtually every useful feature of C++ that is not in its common subset with C is one of those.

What is the performance overhead of namespaces, typesafe object creation, references, function and operator overloading, use of const ints for array sizes (more efficient than C), non-virtual methods, STL (the word "virtual" does not appear anywhere in the STL sources), support for wide characters, protected/private modifiers, etc.? While features like templates and metaprogramming have performance tradeoffs, skilled programmers can use them to make programs that are faster than the corresponding C programs.

Example: if you use exceptions, there is a performance penalty.

And if you use operator new, you use exceptions.

Firstly, this whole point is spurious because you can always use nothrow new, which was put in the standard precisely for people who want exception-free code.

Secondly, the (exception-throwing version of) new may well be faster at error handling than malloc. For the very many programs that only catch allocation errors at the top level, setting up the exception handler is just negligible part of startup costs and far faster than checking the return value from each malloc for zero.

Even if you are doing fine-grained error checking around each call to new, it's not clear whether setting up the exception handler is slower than checking for a null-returrn. It is certainly far less error-prone.

The main slow downs you will see in your average C++ program, over the corresponding C, is the use of the string class

That and <iostream>. Once, I tried programming in GNU C++ for a system with an ARM7 CPU and 288 KiB of RAM. Even after applying all the link-time space optimizations I could find, Hello World statically linked against GNU libstdc++'s <iostream> still took 180 KiB. (Dynamic linking wouldn't even have worked because libstdc++.so itself is bigger than RAM.)

Many C++ programmers use printf instead of iostream. You're perfectly free to use whichever you want, depending whether you are more concerned with code size/performance or type-safety/extensibility.

Note that C++0x has features specifically designed to support a typesafe printf, which will completely own the very type-unsafe C version.

Furthermore, C++ templates allow code re-use with exactly 0 performance loss

As I understand it, C++ compilers implement templates by making a copy of the object code for each type for which the template code is instantiated. Once you instantiate a template numerous times, your binary gets bigger, and it slows down because it has to keep loading data from storage instead of caching it in RAM. This hurts especially on handheld platforms such as the Nintendo DS, which has only 4 MiB of RAM.

I agree that Nintendo DS programmers should limit their use of templates. Not sure why the many programs which are not targeted at the Nintendo DS (Even the DSi has 4 times as much memory) shouldn't be able to generate the far-faster code made possible by template programming (See the "Was it Worth It?" section here).

Frankly, there is no valid reason for starting a new program in C in this day and age.

This is true but only

The same cannot be said for Adobe. I've had to use their libraries in the past, and had to contact their developer support (I use the term loosely.) The responses I received were usually along the lines of "the function call operates as intended according to the documentation." The fact that it did no such thing didn't seem to make much difference. That was a few years ago though, so possibly they've improved.

Allow me to dispel your illusions: Adobe's C++ Boost-accepted Generic Image Library (or GIL)

But who knows. I don't. This may be Adobe's only noteworthy library.

It's called not reinventing the wheel. Using an INI library would be ideal, a generic solution more ideal. And in fact, one exists.

namespace pt = boost::property_tree;
pt::ptree ini;
pt::ini_parser::read_ini("/some/ini/file.ini", ini);
std::string text = ini.get<std::string>("section.value");

Why use a library, when writing an INI parser takes 10 minutes? Because a solution like the above is more consistent, readable, portable, generic, likely more performant, standardized, is guaranteed more safe, supports features like type-safety & streams & exceptions & iterators & algorithms & locales, and much more flexible. How long would it take to write an equivalent library in hours of spare time? Months.

As an added benefit, if I desired to, I could now serialize this resultant in-memory data structure to binary or XML format with little additional effort. Isn't that nice?

It even works with things like std::merge, std::find_if, and std::unique. And it all comes in one very lightweight header-based library. And the best part is, it has negligable overhead, and unused components are not compiled -- benefit of the raw power of metaprogramming.

Did you know, I once caused a buffer overflow in Knights of the old Republic (PC game) by writing exceedingly long lines in one of its INI files? This bug was likely shared by all previous Bioware Aurora games, including Neverwinter Nights. This is the main reason why you should avoid custom half-baked implementations whenever possible.