Fog Creek Software
Discussion Board




Modern development with C?

A lot of people post topics asking C-related questions in this forum. Something I've noticed is that in almost all of these topics, at least one person always replies with something to the effect of "use C++ instead" or "use Java instead" or "use Perl instead." The responder is usually trying to be helpful, speaking from their own personal experience that doing complicated stuff in C is, generally, painful.

I was thinking about this a few days ago when I was messing around with Libxml2. For those of you who don't know, Libxml2 is the Gnome project's XML library. It contains a SAX/SAX2 parser, a complete implementation of DOM, an HTML parser, an RSS aggregator, a DocBook parser, XML generators, an HTTP client, an FTP client, and a ton of other stuff. It can handle almost anything XML related, and as a result, it's huge, and extremely complicated--I have trouble imagining people actually linking to Libxml and using it straight from raw C code whenever they need to manipulate some XML.

Thankfully, there are Libxml wrappers for a variety of languages, including C++, Perl, and Python. This makes me wonder now if Libxml is even intended to be used directly from C code. DOM is an object oriented protocol, after all.

Which brings me to my question: how many of you still write a substantial amount of C code on a regular basis? When's the last time you churned out a C library containing thousands of lines of C code? Or how about that Win32 application built using straight Win32 function calls--no MFC or WxWidows?

Has C been relegated to the world of kernels, drivers, and compilers?

Phalse Witness
Tuesday, April 27, 2004

I'm working in C right now...oh, wait, no!  I'm slacking off on JOS!

I am involved in upgrading older versions of our software, which were written completely in C, and none of the code was encapsulated into Dlls.  Either the piece was a monolith, or it spawned another exe.  Nasty.

However, the products involve a lot of statistics, and the computations can be time consuming.  Forcing it all into OOP would slow it down too much.

So, as I go through these projects, I take reusable code and create Dlls that are linked to either C++ or C# GUIs.  But the Dlls themselves are just libaries of C functions.

Many people hate C because it's not OOP.  Sure I prefer OOP when it makes sense, but there are times when it doesn't.  You have to make the determination based off of the project.

Walt
Tuesday, April 27, 2004

"However, the products involve a lot of statistics, and the computations can be time consuming.  Forcing it all into OOP would slow it down too much."

Ummm, Otay.

Jorel on Software
Tuesday, April 27, 2004

Yes, allocating objects requires more overhead by the system.

If you were dealing with calculations that are in the millisecond range, it's not a problem.

The analyses my software does can take days.  Having to do it OOP would stretch it out even more.

Walt
Tuesday, April 27, 2004

class CHelloWorld
{
public:
  CHelloWorld ();
  ~CHelloWorld ();

  int doIt ();
};

int CHelloWorld::doIt ()
{
  cout << "Hello World!";

  return (0);
}

int main (int argc, char *argv[])
{
  CHelloWorld hw;
  int i = hw.doIt();

  return (0);
}


-vs-


int main (int argc, char *argv[])
{
  printf("Hello World!");
  return (0);
}


He's right, C is faster

Capn' Kirk
Tuesday, April 27, 2004

"The analyses my software does can take days.  Having to do it OOP would stretch it out even more. "

Fresh out of college I worked on a program that took 7 days to run. I refactored using some OOP and got it to run in 2 hours. The original programmer had spent weeks trying to optimize. My major improvements were done in one day.

I don't know the details of your program, but sometimes OOP gives you a better way to eliminate bottlenecks.

HotSH
Tuesday, April 27, 2004

"However, the products involve a lot of statistics, and the computations can be time consuming.  Forcing it all into OOP would slow it down too much."

Or maybe not, you might be surprised. Most modern languages have very highly optimized, compiled libraries to handle the heavy number crunching (hey, it's good enough for the Hubble):

http://www.stsci.edu/resources/software_hardware/numarray

Tom H
Tuesday, April 27, 2004

You can be modern and still use C. My company is only living from its C code and "expertise".
But I won't recommend C for people with very limited low level computing knowledge.

GinG
Tuesday, April 27, 2004

Ultimately anything that you can do in one language can be done in a lower level language, just with a bit less transparency (though on the flip side a bit less leak). Before classes and C++, people took a struct as the first parameter of the method, and the method operated on that struct. In C++ parlance, that method would be a member of the class (which is a struct, just with a default visibility of private), and the compiler would hide the fact that the instance pointer was the first variable. Of course I'm being a Master of the Obvious saying this.

Dennis Forbes
Tuesday, April 27, 2004

Our product is a tool used on embedded systems,
and it is implemented in a combination of C and some Lisp
(used for the development environment).  Our tool
works quite happily with C++, but the runtime (in particular)
is written in "just above the metal" C, with a bit of
asm in some environments.  Our most constrained
environment is a 16 bit, 8 Mhz CPU with 12K of RAM and
a 32K code segment, so we have to be careful about
"abstraction bloat".

We actually have quite elegant API's, but by necessity,
we have a very short, but fat, "abstraction pyramid".

x
Tuesday, April 27, 2004

I'm sure there are many projects that get sped up by switching to OOP.  Just not mine.  I'm not talking out of my butt here.  We've done a lot of homework and found what works best, and in this case, the calculations work best in flat C functions.

You must also consider whether OOP is the *right* thing to do, or whether you're using a horse bit on your cat.

OOP offers encapsulation and polymorphism (in a nutshell).  However, if your application doesn't need encapsulation or polymorhpism, why use OOP?  You personally need to wonder if you're fitting square pegs and round holes.  You may decide to do just that, but you should have a dang good reason to.

OOP isn't the end all of computing.  Structured programming has it's place.  Perl has done wonderfully well without being strictly OOP.

Point:  Use the programming motif best suited to the project.  It may be OOP, or it may be structured, or it may be assembler.

Walt
Tuesday, April 27, 2004

My situation is the same as X's... I write quite a bit of code for embedded systems. The code is in C as much as possible, and in assembly where needed.

I wouldn't mind using C++, but C is a lot more straight forward, and in the particular applications I work on, it is not really necessary or any more elegant.

grunt
Tuesday, April 27, 2004

I just shipped a product with 450K lines of C code.
It has many competitors in its field that were written in C++ with less features that took more programmers more time to write.

A good programming language must be expressible, readable, and debuggable. C aint perfect at all three of those, but it's better than C++ at the second two.

xyz
Tuesday, April 27, 2004

"I just shipped a product with 450K lines of C code.
It has many competitors in its field that were written in C++ with less features that took more programmers more time to write."

And I could say the same thing in my field, using similar size metrics, but with the languages flipped.

It has NOTHING to do with the language you use.  It has EVERYTHING to do with your proficiency in using that language.

BadgerBadgerBadger
Wednesday, April 28, 2004

"It has NOTHING to do with the language you use.  It has EVERYTHING to do with your proficiency in using that language. "

Sure, but note the title of the subject we're discussing.

xyz
Wednesday, April 28, 2004

It does. More people are proficient in non C languages, hence the proliferation of non C app development.

The schools churn out Java, C++(maybe), VB, Delphi and .net programmers. Ditto for the tool manufacturers.

Hence no production in C. Ditto for Lisp too.

Ever wondered why the finer points in law are expressed in Latin. Same applies for the bleeding edge stuff in programming (lower level languages, not Latin)

It is just easier and  transactionally more expedient to do the rest in English, or C#

Tapiwa
Wednesday, April 28, 2004

>> printf("Hello World!");

Both versions compile to the exact same code.

I guess you meant a C program is faster to *type* ;)

Ignorant youth
Wednesday, April 28, 2004

Bad design has nothing to do with language.

OO code is more volumnious and often slower, but gives you the namespaces that enables you to scale beyond a few programmers.

Jonas B.
Tuesday, May 04, 2004

*  Recent Topics

*  Fog Creek Home