Fog Creek Software
Discussion Board


I've been particularly interested by a few recent threads complaining about C's pointer syntax. I've never liked the fact that the pointer declaration operator is the same as the pointer dereferencing operator. And I think alphabetic mnemonics are much more helpful than symbolic ones (*%!=~). I like to see _keywords_ in code. Keywords and named functions help to make code much more self-documenting than symbolic operators.

Consequently, if I'm faced with reading someone else's code, I'd rather read Java code than C/C++ code. I can sit down and read someone else's Java code even if I'm not familiar with the architecture of the project or the packages that are being imported. Trying to read someone else's C/C++ code is much more of a headache, though.

Once you compile the code, though, my preferences go the other direction. I have very little patience for the runtime memory performance and UI capabilities of Java code. What's more, I actually LIKE using indirection in my code. I'm really comfortable with using pointers and pointers to pointers and pointers to functions and arrays of function pointers. I like templates. And I like to allocate and release my own resources.

I just wish that the code looked more like Java.

What I propose it this: a language that makes an exact one-to-one mapping to the capabilities of C++ but provides a much easier-on-the-eyes syntax. A bi-directional preprocessor ought to be able to turn any code implemented in this language directly into C++ code or convert existing C++ code into the more readable language.

What do you think?

Benji Smith
Thursday, January 23, 2003

Cool.  When can you ship it?  ;>

Sam Gray
Thursday, January 23, 2003

>>> What do you think? <<<

This sounds like a personal preference issue to me.  Hmmmm, I guess that's obvious.  I have been trying to imagine what it would be like.  For the most part the C++ operators are just fine with me. Or, at least, I can't think of a way to improve things with keywords.  Some examples:

Comparison operator:
    FORTRAN:    A .EQ. B
      C/C++:          A == B

C looks better to me, but maybe Pascal got it right.

How about logical operators, C vs. keywords:

    a | b      vs.    a  bit-wise-or  b

    a || b      vs      a  logical-or  b

Maybe you're thinking of something else.  I don't see any improvement.

Thursday, January 23, 2003

Someone else likes the idea: papers/PDF/ModestProposal.pdf

(aka if that wrapped)

Thursday, January 23, 2003

Hmm... it did wrap :)

Thursday, January 23, 2003

And I pasted the wrong thing.

Thursday, January 23, 2003

All this reminds me of is several misguided attempts to use the C pre-processor to make C 'better'.

One guy decided he liked Pascal's begin/end so he used
#define begin {
#define end }
to define them (and other Pascal-isms) and proceded to used them throughout his code. I had to takeover maintance of this crap - it took me a week to get everything out.

I actually ran into this at a second job, but instead of Pascal, he made his own 'improvements' like:
#define If if (
#define Then ) {
#define Else } else {
#define EndIf }

which looked like:
If a > b Then
  a = b;
  b = a;

This took even longer to remove...

The problems with this is that:
1) They can cause subtle errors if you don't completely understand how your changes work
2) No one else understands (or wants to understand) your 'improved' syntax.
3) Very few standard source tools are usable with your made-up syntax.

Thursday, January 23, 2003

I was thinking the same as jeff. I heard tell that Steve Bourne, author of the Bourne shell, carried out similar pre-processor abuse so that he could write it in something that looked like Algol68.

If you're that hung up on syntax, wouldn't you be better off using something else?

Andrew Simmons
Thursday, January 23, 2003

I once found this:

#define ever (;;)

  for ever


will loop forever.

Clever but not worth it.

Thursday, January 23, 2003

On a similar note, when I was cutting C code daily, I always used to do this

if (pMyStruct != NULL)

However, when I went over to C++, my mentor at the time said I should be doing this instead

if (pMyStruct != 0)

because no matter what your address bit pattern for a NULL pointer is, C / C++ will guarantee that 0 in the context of a pointer gets evaluated to it.

I ended up thinking that C convention uses NULL and C++ convention uses 0.

Better than being unemployed...
Friday, January 24, 2003

Upon reading some of the responses here, I can see that my comments didn't make a very favorable impression. But, I'd like to agree with practically everything you're saying here.

I couldn't agree more emphatically with pointless preprocessor replacement of things like END for } in code that is otherwise C code. It can accomplish nothing but to spread confusion, increase maintanence, and generally piss people off.

Besides, in this particular case, using symols makes sense. The use of braces to enclose blocks of code carries very little semantic value, only to group the lines of code together within a larger enclosing structure of some sort. That's almost purely syntactical. Dereferencing a pointer, on the other hand, carries much more semantic value. Dereferencing a pointer is an actual event that takes place at runtime, and I think it deserves a keyword of some kind.

Personally, I think dereferencing a pointer should look like a function call:

value = pointer.dereference();

The link given above (at ) for the 'modest proposal' for a resyntaxed C++, is exactly the kind of thing I'm talking about.

Another similar concept is the compilation of Python code to the Java Virtual Machine. For one reason or another, someone like the performance characteristics of the JVM enough to write Python bindings to it. Of course, in this case, my understanding is that Python makes use of the JVM in a much different way than you can accomplish with Java code. But, at the heart of it, some people just like writing Python code more than they like writing Java code.

So, as I envision someone writing 'resyntaxed' C++ code, they're not burdening a development team with a bunch of kludgy preprocessor directives. They've made a choice to implement a piece of code in a different language ('minus minus', perhaps) for the strengths of that language (in this case, readability).

Benji Smith
Friday, January 24, 2003

In Pascal, pointers are nicely handled.

IIRC you can:

var PInt: ^integer;  (* to declare it *)
PInt^ := 12; (* to dereference it *)

In delphi, if you have a structure, such as:
type Point: record x, y: integer; end; (* my type *)
var myPoint: ^Point;
myPoint^.x := 12;  (* explicit dereference *)
myPoint.x := 12; (* implicit dereference *)

This implicit dereferencing, because it is unambiguous, just makes things much more tidy.  Why do you need you choose either . or -> in c++, when the compiler knows exactly whether the variable is direct or a indirect?

Sunday, January 26, 2003

.. and don't get me started on the beauty of the "with" keyword...

sorry (me takes my pills)

Sunday, January 26, 2003

"Personally, I think dereferencing a pointer should look like a function call:

value = pointer.dereference();"

You can already do something like this using templates, you just can't get the member function call syntax:

template <class T> T * AddressOf( T & t ) {
    return & t;

template <class T> T & Dereference( T * t ) {
    return * t;

int main() {
    int n = 42;
    int * p = AddressOf( n );
    Dereference( p ) = 666;


Neil Butterworth
Sunday, January 26, 2003

(Not sure if anyone will read this one-year-late message, but I stumbled onto this page via google, so...)

There is a package called Cugar that is a C++ preprocessor that provides Python-like syntax. It is unlike the horrible tricks mentioned above in that if you dislike the Cugar syntax, you can simply run their preprocessor and instalntly the entire tree is converted to normal C++ code. No "it took me forever to get rid of it." Plus, a custom preprocessor allowed them to be much more thorough: it would not be possible to implement Python syntax with the standard C precompiler.

Scott Lamb
Friday, February 20, 2004

*  Recent Topics

*  Fog Creek Home