Tag Archives: c

Something good about every language I used in 2010

Inspired by Samuel Tardieu’s post, I want to do a year in review of all the languages I have used this year.  A lot of times we prima donna programmers complain about anything and everything. I really enjoyed the positive outlook of Samuel’s post and want to take note of my experiences with similar attitude.

Bread & Butter

  • Python – My language of choice for the year.  Whether prototyping, experimenting, developing a Facebook application, maintaining a test framework I wrote for my workplace, or implementing cryptographic algorithms for a security course, Python continued to serve me well.  Between a copy of “Python Essential Reference” and PyPI, I feel there are very few problems beyond my means thanks to the power of this beautiful language and its surrounding community.
  • Java – As a student, I pounded out many a line of Java throughout the wee hours of the morning in my capstone classes.  Java seems to be the New Age language of academia and I can speak it universally to my classmates and professors as a lingua franca.  I’ve noticed that my Java programs tend to structure themselves well without much effort thanks to the strong object influence forced by Java and expansive standard library and Collections classes.  Also used at two collegiate programming competitions which is an entirely different experience than normal software development where the large standard library again came in handy.

Good Progress

  • C – I launched a good sized networking project in C as my first big project in the language and contributed a number of portability fixes to the libevent project.  Fast to compile, fast at runtime, and full low level control, C is a great language for Unix Systems Programming.  I greatly expanded my knowledge of the POSIX interfaces this year and really enjoy programming at this level.  I’ve noticed that some principles from other higher order languages have rubbed off on my C style; namely, data hiding and well formed/adaptable interfaces (see the post right before this one).
  • C++ – Been putting this one off because of all the FUD and intimidation at the sheer size of it.  C++ is pretty much the Latin of our field and is used in everything from safety-critical Jet aircraft systems, to GUIs, to games, to JITs, to cutting edge research.  As some of the pundits say, C++ is the language for “Demanding Applications”.  If you consider Java as the Flight Engineer of a large aircraft, C++ is definitely in the Pilot seat.  You have full control and high visibility of what is going on, but if you aren’t careful you can crash and burn.  I’ve probably progressed to the advanced beginner stage where I can use it as a better C but haven’t endured the trials and tribulations of an expert in the art of C++, nor read important references like Scott Meyers’ “Effective C++” series.  I really like the power and efficiency of the STL and plan on knowing enough C++ to use it when called upon.

Breaking New Ground

  • VHDL – After a required Electrical Engineering course, I was exposed to the entirely different paradigm of programmable hardware (FPGAs).  This was an eye opening experience.  Fundamentally, digital design is concurrent.  There may be valuable lessons here for both academic and professional Computer Science and I need to explore more here.  In 2011, I’d like to buy my own FPGA development board and work through the design of a simple CPU to gain further appreciation of hardware and VHDL or Verilog.

Back Burner

  • PHP – The first language I seriously learned and used some 12 years ago (I dabbled in Perl before that at the ripe age of 8, and probably Lego Logo a year before that :-P ).  I’ve been keeping an eye on it and it seems some of the Framework movement that stole a lot of developers away to other languages has sprouted mature analogues in PHP land.  No longer just C for the web, PHP 5.3 continues the lineage of the 5-series as a serious object-oriented language for web development that is basically universally available and dead simple to scale.  The extent of my PHP coding in 2010 was limited to maintaining some programs I’d written in years past (aside from merely installing/using PHP products like this blog).

On to 2011

  • D – D2 has me really excited.  For some intents and purposes, it seems like an evolution of C++ with a healthy removal of backward compatibility.  Embracing fast compile times, integrating concurrency and message passing, allowing easy interfacing to C libraries, and more mean this is a language capable of “Demanding Applications”.  Perhaps most intriguing is the use of the language proper for metaprogramming and compile-time programs.  I have Andrei Alexandrescu’s book on my shelf and have thumbed through it a few times.  The fact that he is involved speak volumes of D’s potential and his book looks superbly written. 2011 means working my way through the book and working on at least one sizable project in D.
  • Erlang – Erlang has been on my radar for a couple years now.  The fact that the OTP has roots in the demanding and critical realm of telecom means this is a serious language and seems to deliver interesting take on concurrency.  Erlang has already proven itself effective for XMPP servers and Message Queues.  This may yet be one of the best languages around for scalable networking applications and I’d like to get some hands on experience with it in 2011.
  • Haskell – I don’t know much about Haskell other than playing around with TryHaskell.  What I do know is that Haskell has a fairly mature Software Transactional Memory and that alone interests me.  I’ve also heard the optimizing compiler is pretty good.  Through investigation is due in the second half of the year.

No Nonsense Logging in C (and C++)

A lot of times people do zany things and try and reinvent wheels when it comes to programming. Sometimes this is good: when learning, when trying to improve state of the art, or when trying to simplify when only Two-Ton solutions are available.

For a current daemon project I need good, fast, thread-safe logging. syslog fits the bill to a tee and using anything else would be downright foolish — akin to implementing my own relational database. There’s one caveat. For development and debugging, I’d like to not fork/daemonize and instead output messages to stdout. Some implementations of syslog() define LOG_PERROR, but this is not in POSIX.1-2008 and it also logs to both stderr and wherever the syslog sink is set. That may not be desired.

So, the goals here are: continue to use syslog() for the normal case as it is awesome, but allow console output in a portable way. Non-goals were using something asinine like a reimplementation of Log4Bloat or other large attempt at thread-safe logging from scratch.

Using function pointers, we can get a close approximation of an Interface or Virtual Function of Object Oriented languages:

void (*LOG)(int, const char *, ...);
int (*LOG_setmask)(int);

These are the same parameters that POSIX syslog() and setlogmask() take. Now, at runtime, if we desire to use the the “real” syslog:

LOG = &syslog;
LOG_setmask = &setlogmask;

If we wish to instead log to console, a little more work is in order. Essentially, we need to define a console logging function “inheriting” the syslog() “method signature” (or arguments for non-OO types).

/* In a header somewhere */
void log_console(int priority, const char *format, ...);
int log_console_setlogmask(int mask);

And finally, a basic console output format:

/* Private storage for the current mask */
static int log_consolemask;

int log_console_setlogmask(int mask)
  int oldmask = log_consolemask;
  if(mask == 0)
    return oldmask; /* POSIX definition for 0 mask */
  log_consolemask = mask;
  return oldmask;

void log_console(int priority, const char *format, ...)
  va_list arglist;
  const char *loglevel;
  va_start(arglist, format);

  /* Return on MASKed log priorities */
  if (LOG_MASK(priority) & log_consolemask)

  case LOG_ALERT:
    loglevel = "ALERT: ";
  case LOG_CRIT:
    loglevel = "CRIT: ";
  case LOG_DEBUG:
    loglevel = "DEBUG: ";
  case LOG_EMERG:
    loglevel = "EMERG: ";
  case LOG_ERR:
    loglevel = "ERR: ";
  case LOG_INFO:
    loglevel = "INFO: ";
  case LOG_NOTICE:
    loglevel = "NOTICE: ";
    loglevel = "WARNING: ";
    loglevel = "UNKNOWN: ";

  printf("%s", loglevel);
  vprintf(format, arglist);

Now, if console output is what you desire at runtime you could use something like this:

LOG = &log_console;
LOG_setmask = &log_console_setlogmask;

LOG(LOG_INFO, "Program Started!");

In about 60 lines of code we got the desired functionality by slightly extending rather than reinventing things or pulling in a large external dependency. If C++ is your cup of tea, it is left as a trivial reimplementation where you can store the console logmask as a private class variable.

Some notes:

  1. You should still call openlog() at the beginning of your program in case syslog() is selected at runtime. Likewise, you should still call closelog() at exit.
  2. It’s left as a trivial exercise to the reader to define another function to do logging to both stdout and, using vsyslog(), the syslog. This implements LOG_PERROR in a portable way.
  3. I chose stdout because it is line buffered by default. If you use stderr, you should combine the loglevel, format, and newline with sprintf before calling vprintf on the variable arglist to prevent jumbled messages.
  4. Of course, make sure you are cognizant that the format string is passed in and do not allow any user-supplied format strings as usual.

Why VIM is not my favorite editor

clang_complete is what the people want and what the doctor ordered:

let g:clang_snippets=1
let g:clang_conceal_snippets=1

C^X, C^U, profit. Another awesome development for LLVM!

VIM clang_complete

It sucks for C and C++ development.

Popup code completion (“IntelliSense”) is a godsend.  Instead of flipping back and forth between an API reference and your code, a non-invasive popup of available functions, method signature, struct members, instance variables, etc is right at your fingertips.  It’s especially useful when it contains the declaration’s comment/Doxygen/JavaDoc.

Building a ‘ctags’ file of my system libraries takes ten minutes and weighs 1.5GB for VIM’s integrated omnicomplete.  Any time the headers are updated, it has to be manually rebuilt. The project’s tags need to be rebuilt per change.  Unbearable.

I also can’t get inline function/method signatures or automatic struct member completion without a three year old script, omnicppcomplete.  Yes, this is true for plain old C too.

The one editor I’ve found that provides the level of introspection I expect yet otherwise stays out of the way is KDevelop 4.1.  It basically takes the Kate text editor, with awesome syntax highlighting and standard editing features, and adds some of the best auto-completion I’ve seen for C or C++.  It’s fast too, and doesn’t require a ridiculous manual scan or gigabyte symbol database.  It just works – automatically.

Well, editing from the console is pretty convenient, especially on slow remote SSH connections.  Lazyweb, am I missing something that VIM gurus know and I don’t?  Does emacs provide the level of completion I’m looking for on the console out of the box?

I know the llvm devs have some code brewing that uses llvm for syntax completion.  Maybe there’s light at the end of the tunnel.

My .vimrc looks like this if anyone has any suggestions: Continue reading

But First, Write No Code

Something I see often in person and online are programmers constantly implementing common solutions, reinventing wheels, or embracing NIH.

Before you do this, please consider the Kev009’s Oath“But First, Write No Code”.  This is a solution to a variety of problems in software development, but today’s article is specifically on using external code.

I’ve found that programmers who follow a system similar to mine (detailed below) develop systems that are more stable, maintainable, and sane.  They likely write better code because it means they understand their tools and also read others’ code.  They examine the problem first rather than going in guns blazing.

Steps to decide whether to use an existing solution or write your own implementation:

  1. Scan the area. Google, Freshmeat, SourceForge, standard library, OS libraries, etc. are your friend.  See if the problem you are trying to solve has been solved.  I don’t care how long you’ve been programming or how much you think you know. The ecosystem of a language is constantly changing.Make a list of hits that look similar to the problem you are trying to solve.  Try and get a quick sense of the idiomatic methods of using your language, OS, etc.
  2. Do research. Are the solutions you found in step 1 suitable to the problem at hand?  Consider the pros and cons of each item.  Now, carefully evaluate how idiomatic the items are to your language and environment.If the item is open source, does the community seem active?  If it doesn’t fully map to your problem, does it look like you can modify it to do so?

    Even if you end up developing a solution from scratch, you should at least now have some good references.  Keep in mind, extending an existing project may be considerably less work.  You might even be able to offload maintenance of that component.

  3. Consider the license. This isn’t just for the legal department.  What kind of project you are working on will weigh in heavily.  Commercial or open source?  As a software professional, you need to be abreast with the various licenses in the wild.  As an open source developer, you need to consider how licenses will affect your work being packaged by distributions.An open source library licensed under the GPL is not acceptable for static linking to commercial software.  However, you can link to an operating system provided copy or bundle the dynamic library with your application.  LGPL does not have this restriction.  With both of these, you must supply your changes upon request from end users among other things.

    BSD, MIT, and Apache style licenses allow you to make changes and redistribute under completely different licenses.  Some just want credit in your documentation.  These are very compelling even in commercial development.

    Commercial components may have a per-copy fee associated which may dissuade their use by your organization.  If you don’t get the source, you won’t be able to effectively change or maintain it so you will also be at mercy of that developer.

  4. Make a decision. By now, your list should have been pared down based on licenses and research.  Perform extensive evaluations of the remainder and eventually hone in on the one you think fits best.  You’re going to have to rely on your experience and intuition while making the critical decision.  Perhaps the hardest part:  weighing it against a mythical home-grown solution in your mind.
  5. Implement the decision. Self explanatory.  This either means bootstrapping your own project or fully integrating the external one.  If you are extending an open source solution, consider submitting the patches back to the community for feedback and perhaps integration.  If you are bootstrapping your own solution, you’ve got your work cut out.  Is this only suitable for an internal project, or perhaps it would have its own merit as a new open source project?Be sure to reevaluate early and often.  That library you chose might turn out to be a can of worms, just as the “easy” new solution you had in your head might require years of development.
  6. Subscribe to the announce mailing list. Only if you used an external solution. Does the project have an RSS feed for releases or a low volume announcement list?  Don’t be like Adobe.  Avoid embarrassing security problems.  Also consider how enhancements and bug fixes to the external project might make your own project better, more stable, and more efficient.  This is where the real lasting dividends of using an external solution come from.

This list is widely applicable.  You’ve got a seriously high bar to reach if you are developing containers of <T>, sorting methods, GUI frameworks, parsers, text and binary file formats, and much more so try and follow it the next time you code.

El Reg Humor and Java in free software

The Register has a good article on Sphinx search with some entertaining pop-shots at Java and “enterprise software” that got a rise out of me:

Solr is popular with the enterprise crowd, who love its Java. Being a Java program, Solr includes no shortage of technology whose acronyms contain the letters J and X.

This tickles the enterprise pink, because these sorts of developers love nothing more than hanging out around a whiteboard drawing boxes and arrows and, from time to time, writing XML to make it look like they’re doing real work. Solr thrives in this environment, being an Apache Foundation project, the Apache Foundation, of course, widely known as a cruel experiment to see what happens when bureaucrats do open source.

Having a bit of experience with Java from academia and a few open source projects I make use of, I can’t help but laugh at how comically and concisely the editor summed it up.

By and large, successful open source projects tend to be written in languages other than Java. The entire GNU/Linux OS stack is primarily C, with some components using C++ like KDE, OpenOffice and Firefox.  On the ever popular web front, PHP, Ruby, and Python lead the pack.

I think it turned out this way for a multitude of reasons.  When working on the OS stack, the power and control of C and C++ are hard to beat.  The plethora of libraries and raw speed of these compiled languages set the bar high for any newcomers.  Java exists as a kludge, mildly useful for desktop apps and mildly useful for web apps while historically having a lot of problems.  Native look and feel have long been the layman’s complaint, though SWT has done a pretty good job there.  Of course, omnipresent Java in the Linux world is relatively new.  I think Java would have been the darling language of client apps had it been open sourced sooner, but this came about 7 years too late to have a large impact on shaping the common FOSS userland.

It is interesting how the open source projects built with Java tend to be highly bureaucratic and abstract.  I think the bottom line is that FOSS programmers do what they do because it is fun and demand pragmatism.  The “enterprise software” attitude/baggage that many Java apps and libraries carry are a big turn off to pragmatism and the hacking culture.  The barrier to entry for Java web programming is also much higher than its “scripting language” competitors, which carry light and simple frameworks that focus on results, not procedure.

Java itself isn’t that of a bad language.  I actually enjoy working with it in school (…though I think it really isn’t appropriate as an introductory teaching language, shielding important concepts from students.  Maybe a future post?..).  When it comes time for real work though, I consider Python, C,  C++ more pragmatic depending on the job at hand.  That, and the fact that most of the common scripting languages are gaining JIT compilers may accelerate Java toward status as a legacy language.

Your thoughts?