Two Features I’d Like to See in C and C++

October 1, 2013

This week, let’s discuss two features I’d really like to see in C and
C++; one trivial, one not so trivial.

fish-on-stilts

Read the rest of this entry »


Extending C++’s using statement

November 30, 2010

If you’re using C++ as your principal programming language as I do, you certainly know some or most of its capabilities, some of its limitations, and you’re surprised once in a while by a new construct or feature you never thought of even trying in C++.

Having inherited most of its basic behavior from C, C++ still has many quirks and omissions that keeps C++ from becoming a true next-generation language. I’m thinking, as a best example of this, the absence of true arrays. Arrays are pointers to stuff, sometimes you can get the size of the array, most of the times you’re stuck with the size of the pointer, which is of no use and forces the user to manipulate explicitly array meta-data (curiously enough, it wouldn’t ask for much to be able to know the size of an array all the time because new[] and delete[] do hide meta-data to do exactly that).

Read the rest of this entry »


One Does not Simply Rename Into C++

July 13, 2010

Programming is in many ways more art than science—I do not want to start that debate in this post—in that you need more than mere functionality and correctness to have great code. For code to be great, it has, amongst other things, to be beautiful in that strange, vague, language-specific way.

As you know, this blog is C and C++-centric. Those are the two main languages I use both for personal and for professional projects. I resisted the transition from Pascal to C a long time, for many reasons. One was that at that time C compilers were flimsy, while we had a couple of really great Pascal compiler, such as Turbo Pascal—quite the upgrade from my Apple II’s USCD Pascal. Another was that I found C just ugly, clunky, and primitive; it was terse and inelegant. But over the years, I learnt to like the way C gives you pretty good control on what code is generated—not that you can predict right down to the assembly instructions what the compiler will generate; but you still have a very good idea if you understand even vaguely the underlying machine.

Read the rest of this entry »


Is Python Slow? (Part II)

June 8, 2010

In a previous post I expressed my worries about Python being excruciatingly slow and I used a toy problem to compare the speed of Python to programs in other several languages, including C.

Of course, all kind of people complained that I couldn’t compare a dynamic, interpreted language with static, compiled languages. First, let met tell you that I sure can. First, the goal was to measure speed, and not the effects of type system of the language (although logically correlated) nor the programming paradigm: the amount of CPU used to solve a given problem was the primary (if not only) point in interest.

But to be fair to Python, I extended the tests to other interpreted, dynamic languages, such as Lua, Perl, PHP and JavaScript. I also added Pascal and Haskell in the compiled languages groups.

Read the rest of this entry »


Your Automatisms Betray You

March 11, 2009

Yesterday someone dropped on the IRC channel where my fellow programmers, computer enthusiasts, and I hang out to get help to find a bug. He uses one of the paste sites (like pastebin.ca, pastebin.com, or rafb.net), pastes his piece of offending code, and so we get a look at the code. Of course, I go over the short program, notice a mistake in the scanf but it took me a full two minutes to notice the loop:

for (c=0; c++; c<n )
 {
   ...
 }

That kind of bug always takes a while to find because we don’t read what’s actually written, but what we think is written, unless we pay the utmost attention to the code—what we should be doing anyway, but do not always. Usually, you zero in on that kind of bug rapidly, as you guide your search from the bug’s symptoms which leads you to defect’s approximate location. If you’re like me—write a little, test a lot—you find those bugs right away most of the times. However, even if you zero in rapidly, you still get a coarse-grained location: module, class, function.

Read the rest of this entry »


Follow

Get every new post delivered to your Inbox.

Join 76 other followers