0

I'm interested in getting into C to get close to the metal performance, but would like to write in a Pythonic style and don't want to roll my own dynamic strings, lists, and dictionaries. Cython is pretty good, but would like to know how to use dynamic variables in straight C if possible.

With C++ there is of course the STL, which will give you String, Vector, and Map. Certainly one possibility is to program in a C-like style in C++, using only those features. Is that the standard practice if you need dynamic variables in C?

ramanujan
  • 5,581
  • 5
  • 30
  • 31
  • 15
    `I'm interested in getting into C but would like to write in a Pythonic style`. Don't. This is C, not python. They're vastly different. If you want to write python, write python. If you want to write python in C, you'll just end up with horrible code. – Falmarri Dec 31 '10 at 18:54
  • 3
    @Falmarri: Certainly this is true, but at the same time it can be helpful to take the techniques learned in one language and apply it in another. Provided it doesn't make your code look like crap, of course. – Ignacio Vazquez-Abrams Dec 31 '10 at 18:57
  • 2
    [Container Class / Library for C](http://stackoverflow.com/q/305611/2509), [Any library for generic datatypes in C?](http://stackoverflow.com/q/649649/2509), [What is the most popular generic collection data structure library for C?](http://stackoverflow.com/q/3027797/2509), [Standard data structure library in C?](http://stackoverflow.com/q/1819416/2509) none of which are exact duplicates, but the *answers* are more or less the same... – dmckee --- ex-moderator kitten Dec 31 '10 at 19:15
  • If you go writing Python in C, you're not going to get "close to the metal performance". Using the correct idioms, not the correct language, is what makes C fast and light. – R.. GitHub STOP HELPING ICE Dec 31 '10 at 20:17
  • @Ignacio: It takes a fair bit of experience in both languages to know when that's appropriate, though, especially with such fundamentally different languages as these. For less experienced users, it's more likely to get in the way of learning. – Glenn Maynard Dec 31 '10 at 20:29
  • 2
    @R: That's simply not true; Python has the serious overheads of GC, a high-level VM and dynamic typing, which makes the same algorithm written similarly in Python and C almost categorically much faster in C. – Glenn Maynard Dec 31 '10 at 20:33
  • "If you want to write python in C, you'll just end up with horrible code" -- well, sure. I guess what i'm saying is that a large class of algorithms do use dynamic lists/strings/dicts. Any C code I write will likely have to use those, as I'm not dealing with fixed-width records. So given that Python has fairly nice strings/lists/dicts, was just looking for the idiomatic C equivalent. It can't be the solution for each developer to roll their own -- there has to be a winner out there -- but I don't know what that is, and google surprisingly doesn't provide any obvious answers. Hence the Q... – ramanujan Dec 31 '10 at 22:08
  • @Glenn and if you want to write it in anything like Pythonic style in C, you end up (wasting your time and) replicating most of the things that make the Python code slow. – Karl Knechtel Dec 31 '10 at 22:10
  • @Karl, it depends what to call pythonic style - you can still have some "pythonic" features without a huge performance impact, for me this is a big part of what boost and C++0x try to achieve. – Roman L Dec 31 '10 at 22:56

2 Answers2

4

glib is pretty good and widely used:

GLib provides the core application building blocks for libraries and applications written in C. It provides the core object system used in GNOME, the main loop implementation, and a large set of utility functions for strings and common data structures.

In fact, glib provides more (much more...) than just ADTs for strings, lists and dicts. But you can easily start by just using those parts, expanding later.

That said, don't think that having dynamic strings, lists and dictionaries will make your code Pythonic. The vast majority of C applications above some level of complexity have implementations of such data structures, but I'm not familiar with any such application written in "Pythonic style".

Eli Bendersky
  • 263,248
  • 89
  • 350
  • 412
  • 2
    glib has a painfully ugly API; for most typical tasks, the C++ standard library leads to much more readable code. – Glenn Maynard Dec 31 '10 at 19:08
  • 1
    Bad advice, the worst code I've seen was from people rooted in glib. Start using C++ facilities, standard library, boost, etc., don't start with C and #$%y libraries. – Gene Bushuyev Dec 31 '10 at 19:16
  • 2
    @Gene: Boost (or much of it, at least) isn't an improvement; the ugliest C++ template abuses imaginable are found there, tied with crypto++ for the worst C++ code you're ever likely to see. – Glenn Maynard Dec 31 '10 at 19:40
  • @Glenn: totally agree! But are there any alternatives to boost (and templates)? Here, at SO, half of C++ related questions end up with a single reference to boost, as if it was the only option. – Roman L Dec 31 '10 at 20:11
  • 2
    glib is basically the worst of both worlds (C and C++). Either write real C code, or use C++. Just like with natural languages, trying to translate the idioms of one programming language to another doesn't work; it generally results in extremely inefficient and ugly code. – R.. GitHub STOP HELPING ICE Dec 31 '10 at 20:16
  • @7vies: Templates aren't evil, and the C++ standard library uses them well--it's when you start writing entire algorithms as convoluted, crisscrosses of templates that things start to go bad. When you see what looks like functional code, but with templates--turn and run the other way, as fast as you can. – Glenn Maynard Dec 31 '10 at 20:27
  • @Glenn, I tend to consider C++ templates evil, just because they are poorly implemented, leading to limitations and consequently ugly workarounds. But in general is there any fundamental reason why functional style cannot be nicely combined with a low-level language? – Roman L Dec 31 '10 at 20:44
  • @7vies: I'm the wrong person to ask, because I don't like functional style in the first place. It always seems like nothing but people wanting to pretend they're doing math while they're programming. It encourages writing large blobs of code rather than cleanly breaking code into logical statements; the resulting code is invariably needlessly opaque. – Glenn Maynard Dec 31 '10 at 21:03
  • @Glenn, maybe functional style brought to extreme might result in such problems, but it looks to me that simple functional things like map/filter/foreach/lambda/... simplify programming a lot (python is a proof for this, isn't it?). Inverting the control flow as it is often done say in recursive factorial etc etc is a different thing, though. – Roman L Dec 31 '10 at 21:23
  • 1
    @7vies: Some of Python's semi-functional constructs are fine, but, for example, almost every case of `map(lambda...` in Python is much clearer when written as a list comprehension. The C++ functional-style functions like `std::bind1st` almost instantly become hard to follow. – Glenn Maynard Dec 31 '10 at 21:48
  • @Glenn: I'd say the opposite. Procedural languages (including OOP) tends to lead to long blobs of vaguely related code, where a functional style typically allows you to naturally split everything up into functions of, at most, 2-3 lines. That is, assuming that by "functional style" we mean the style used in a *proper* functional language, and not the approximations enabled by C++ or other non-FP languages. – jalf Jan 01 '11 at 01:32
3

Use C++; it has standard and highly-optimized versions of all of these. There's absolutely no reason or benefit to limit yourself to C.

(ed: In other words, yes, that's a very standard practice. Remember, there's no requirement to use any of C++'s features when using C++; by design, you can pick and choose. I often disable exceptions, for example, since it leads to massively bloated executables. There's simply no reason to write code in C.)

Glenn Maynard
  • 55,829
  • 10
  • 121
  • 131
  • Many linux libs are written in C, and there are some people arguing that is more appropriate than C++ - isn't there a reason for that? – Roman L Dec 31 '10 at 20:13
  • 1
    @7vies: People who have been using C for decades, who have dug trenches in their habit and history. C was my first serious language, but today the only places I'll use it are 1: when contributing to an existing project that's in C, and 2: if a platform simply lacks C++ support (eg. some embedded systems). – Glenn Maynard Dec 31 '10 at 20:21
  • @Glenn: for your second point, too bad gcc cannot "compile" to C. – Roman L Dec 31 '10 at 20:37
  • I am pretty sure you can still get C++-to-C cross-compilers from **somewhere**... – Karl Knechtel Dec 31 '10 at 22:11
  • @Karl: the problem with "somewhere" is that you can rarely rely on it. – Roman L Dec 31 '10 at 22:47
  • @Karl, @7vies: Embedded software is generally so small--rarely more than a few thousand lines of code, as these systems often have on the order of 8-32k of flash space--that being stuck in C is usually not big enough of a problem to involve quirky code conversion. At that size, lots of language features are out anyway--exceptions, anything involving vtables and all but the most basic of templates (like std::max) are usually avoided entirely. That having been said, there is native g++ support for Atmel chips. – Glenn Maynard Dec 31 '10 at 23:43
  • Still so, most kernel developers disagree with `There's simply no reason to write code in C`. Am just pointing out. – jweyrich Jan 02 '11 at 09:27
  • @jweyrich: Most kernel developers are wrong. Am just pointing out. – Glenn Maynard Jan 02 '11 at 11:24