Mmm, kinda.

    var i0 = $(Int, 5);
    i0 = $(String, "Hello");

Perfectly valid.

> There are many languages with excellent C ABI compatibility with nearly the same portability

Which ones?

Another recent one is Ivory. http://ivorylang.org

…unless your library exposes classes/templates, which is probably what the majority of C++ libraries do (e.g., wxWidgets, Qt, Boost, etc.). In this case, creating C bindings is a real pain.

the Big "I" is the type, which is a macro parameter. The variable name "i" is not a parameter. If There is another variable "i" in the scope, the loop variable will shadow it in the DO statement. Something like this

    float i = 10;
    DO({i+= 10;} 20);

will evaluate to this, modifying the "i" declared inside the macro

    float i_1 = 10;
    {I i_2=0,_n=(n);for(;i_2<_n;++i_2){i_2 += 10;}}

    typedef long I;

    #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}

    DO({i+= 10;}, 20);

    typedef long I;

    {I i=0,_n=({i+= 10;});for(;i<_n;++i){20;}};

    typedef long I;

    {I i=0,_n=(20);for(;i<_n;++i){ i+= 10; }};
 

It is certainly not an improvement for a systems language

Why do you think that's not already happening? Have a look at Django ORM.

https://github.com/django/django/blob/master/django/db/model...

The name is specific to what they're poking fun at. They'd have to find another decaying process with a simple name maybe.

Somehow I doubt C++'s built-in object system will allow you to create classes (yes, classes, not objects) and/or alter their vtables at runtime. (I know, vtables are an implementation detail. You still get the idea.)

> Compile times aren't that slow

I beg to differ. C++ encourages placing more code than strictly necessary into header files. Even the standard headers such as <algorithm> add considerably to the compile time, and they keep getting larger with every revision of the standard. When you are making incremental changes, it accumulates to a lot of time spent waiting.

C++ libraries often add new semantics to the language, and that is not so obviously a benefit. Recently I explored Kiwi project (constraint solver). It is easy to use if you solve specific cases, e.g.:

  Variable x, y, z;
  solver.add(x <= y);
  solver.add(z >= x - y);

But if you need it in meta-way (and I always do, I rarely write non-meta code), you have to unwind all the sources[-in-headers] to find out what Expression is, how does one construct one, write dynamic expression builder, etc. Sources do consist mostly of one-line helper methods/getters/constructors that are nested and intercalled 10-15 times per operation. LPSolve was much simpler in API, since you don't mess with variables and add constraints directly as matrix values.

  double row[size+1] = { };

  /* ...fill row... */
  add_constraint(solver, row);

  /* ...fill row... */
  add_constraint(solver, row);

In the end of the day, both libraries involve identical usage pattern, but for C++ I have to create a convenience unwrapper. This 'convenience' swamp is SO popular in C++. Once you say "++", you have to deal with it all the time, unless you write something really dumb and straightforward. Not to mention most libraries have huge header-only parts due to template obsession. Qt, yeah. It takes forever to compile 20 modules on reasonably priced laptop even with fine-tuned prefix header and -j9.

From the employment point of view, C++ is a nightmare. No one really knows it, and everyone thinks he does. Experienced developers can't tell what explicit constructor is, are confused with move semantics, blink hopelessly on "what is RVO". You actually employ python programmers for sky prices, while all they know is easiest part of C++/stl magic, which is effectively beginner-grade python with low-level bugs and UBs.

>wrap C++ libraries in a C API

Together with "ecosystem" such as std::cool_ptr<std::map<std::bar,std::baz>>. That's a concern.

When I want nice bridgeable object model above C, I use Objective-C or simple embedded language with proper features. Personally, I'm really tired of C++ everywhere.

To be pedantic, the C standard doesn't define an ABI[1] – it just seems that way because implementations follow the platform they're building for.

[1] http://stackoverflow.com/questions/4489012/does-c-have-a-sta...

Looks like C to be. Just some macros and function calls.

Why would you say that "Cello isn't really C"?

But it didn't look to me like Cello was an object model. To me, it felt more like Perl or Python than C++ - more like a dynamic scripting language.

> Precompiled headers never worked well due to a variety of limitations.

We use precompiled headers on a large project, we've never had any issue with them (MSVC and GCC)> Care to elaborate on the limitations?

>Precompiled headers never worked well due to a variety of limitations.

want to elaborate? i use MSVC's implementation and never encounter any problems with it. then again, i also don't work on large projects, so i would like some insight.

I wonder if the Iron fans realize that they are doing more harm than good the way they go about this. It reminds me of the perl zealot days.

Can you please point me to where that's happening?

To be fair I think I've seen one comment mention rust so far in this thread.

Iron Fist

That seems annoying. It's probably a lot better to have a large group of hardcore fans of C who relentlessly disrupt all of programming in general with vulnerability-riddled code. Make sure they're writing code instead of disrupting any discussion threads, that will make sure they're not annoying.

Then you could say that just using void-pointers in C that C is also dynamically typed.

Yes, surely the downfall of Perl was caused by its zealous fans, not by the apparition of other programming languages that were either easier to use (PHP), more readable (Python) or had more attractive frameworks (Ruby) :)

It would be hard for it to be a completely strict superset of C because that would require not introducing new reserved words (like "class") since those end up being legal variable names in C but not C++.

Why did you find that crazy? They are 2 fully separate languages that have both evolved after the latter (C++) was first introduced.

Can you provide C code that will not compile with c++ compiler?

  $ cat foobar.c
  #include <stdio.h>
  
  struct foo {
  	int x;
  	int y;
  };
  
  int foobar(struct foo *f)
  {
  	return f->x + f->y;
  }
  
  int
  main(int argc, char *argv[]) {
  	(void)argc; (void)argv;
  
  	printf("%d\n", foobar(&(struct foo){10, 20}));
  	return 0;
  }
  $ gcc -Wall -Wcast-align -Wextra -pedantic -std=c99 foobar.c -o foobar && ./foobar
  30
  $ g++ -Wall -Wcast-align -Wextra -pedantic foobar.c -o foobar && ./foobar
  foobar.c: In function ‘int main(int, char**)’:
  foobar.c:17: warning: ISO C++ forbids compound-literals
  foobar.c:17: warning: taking address of temporary
  30
  $ # taking address of temporary means that it's undefined behavior

I'm not the parent, but C has a certain simple elegance: everything's an int; those things which aren't ints (e.g. compound structures like structs and arrays) are represented using pointers and offsets, so in a sense they're also ints; except for floats, but meh.

In C++, everything is an int; except for objects; and templates; and lambdas; and classes; and exceptions; and all the other things which keep getting chucked on to the pile.

I like languages with a clear, simple concept behind their operation: lambda calculus, combinatory logic, Scheme, Forth, Joy, Pure, etc. C is a bit gnarly, but passable. C++ is horrible.

As someone who likes C, I'd like to add a bit of a different look:

The aspect that I love about C is how easy it becomes to read. C offers a (arguably) nice programming interface while not allowing the programmer to hide very many things that are going on. C allows you to make nice abstractions, but those abstractions are still built upon the same basic concepts that C supports, and these abstractions generally don't fundamentally change how the language works, so you can very easily tell the control flow of your program if you simply understand the interactions between the basic parts in use.

Now that said, I'll be the first to say that I think C could benefit from a variety of different features (Some from C++, some from others, and some unique to C), and I could easily give you a fairly long "wish-list" I have for C. But, the clear nature of C is a huge advantage that I think is underrated, and is something that you really can't get back in a language once you lose it.

When you (or I) read a piece of C++ code, there are a lot more details you have to take into account then when you read a piece of C code, simply because C would force the writer to be more explicit in what they are doing in those cases.

Again though, I'll make it clear that I don't think C is the be-all end-all of languages - in particular I'm excited to see how Rust goes - but I do think it has traits that are very nice but largely ignored in most of the current languages in favor of adding lots of different ways to write your code.

C++ is very complicated. C is basically the simplest possible programming language, and the closest to the API actually presented by the processor (i.e., assembly language)

It would be relatively easy for C++ to add some kinds of C compatibility, and they just haven't bothered to. (E.g., the "static" keyword for parameter array sizes.) It's a little annoying for shared headers that have to be used in C and C++ programs.

Well, your argument doesn't really prove anything, as Obj-C is actually much closer to C than C++ is.

There's literally not a single comment in this thread comparing C to Rust, and yet Rust fanatics are the ones derailing here? Care to elaborate, my good friend?

I'm not sure what you mean by objects at runtime. Can you elaborate? The sort of objects I interact with at runtime are typically typed structures, so I guess I don't understand your statement.

To clarify, I should probably have said "integer" to avoid confusion with the C type called "int", or to be more accurate ℤ/w for a variety of widths w.

I didn't mean "C is nice because I can just write 'int' for all the types and it works", I meant "C is nice because it represents data in a very conceptually uniform way: either as integer, or 'pointers' which are themselves integers."

The current world population is an integer, my bank account number is an integer, but that doesn't make it's meaningful to add them together. Values can have the same representation without being the same type :)

> "Everything is an int" is not a good way to be thinking about things. There's a reason that `intptr_t` exists.

From http://en.cppreference.com/w/c/types/integer (top Google hit for `intptr_t`):

    intptr_t
    integer type capable of holding a pointer

They're integers :)

> Well written C shouldn't rely on any integers being specific sizes or the same size unless you're using the standard types for that purpose (Llke `uint8_t`, `uint32_t`, etc.).

I never said it should; but from that same cppreference site:

    int8_t, int16_t, int32_t, int64_t
    signed integer type with width of exactly 8, 16, 32 and 64 bits respectively

These are also integers :)

> you should basically never be casting integers into pointers

Again, I never said you should. I didn't say, or mean, anything about casts.

I had that same problem. I wrote a C library [1] that has a structure field named "class". It's "class" because the protocol being described (DNS) calls that particular field "class" [2]. And I'm not about to pay lip service to an abomination like C++ [3][4].

[1] https://github.com/spc476/SPCDNS

[2] https://github.com/spc476/SPCDNS/blob/ca5052c3d0c3252071a18e...

[3] I am NOT a fan of C++.

[4] But I had to anyway, but I used the C pre-processor to rename the field.

But the standards have made some effort at avoiding gratuitous incompatibility, and have even introduced changes to reflect changes in the other standard.

Also, much C code is still valid C++. Sure, you can write code that isn't, but I would guess (pulls a number out of nowhere) that 90% of the valid C code is also valid C++.

That makes them languages that have separate standards, but not completely independent standards, that share a whole lot of source code. That's something less than fully separate in my book.

Actually those are very bad examples. In practice, compilers will produce warnings in all of those examples.

Better examples (of actually useful things) would be things like designated initializers, struct literals, declaring array lengths in args using static, etc.

I don't see what is 'horrible programming practice' about

    int *x = malloc(sizeof(int));

Like C, C++ doesn't force you in any way to have extra useless abstractions over the hardware. The rest of your team do (and C make this way harder).

    struct vtable {
            foo_function *foo;
            bar_function *bar; };
    struct a {
            struct vtable vt;
            ...
    };

> So, for example, you know if at offset 0xDEADBEEF there is are 8 bytes which are holding a number that you want to use, you can access that chunk of memory and use it however you want. And you can interpret it how it is appropriate for your use case, for example reading it into a string, or an int.

Except these days with strict aliasing that's not true. If you access memory through a pointer of the wrong type, you've probably committed the crime of undefined behavior, for which the compiler might punish you by breaking your code - but probably won't, leaving the bug to be triggered in the future by some random code change or compiler upgrade that creates an optimization opportunity.

Admittedly there are ways to avoid undefined behavior, but still. C gives the compiler a lot of leeway to mess around with your code.

Not really that dangerous, except for all the code for which it is dangerous?

Of course, you've got me, it only breaks existing code, and doesn't affect code that's written perfectly according to the rules of C and not peoples' intuitions about what pointers actually mean on a hardware level.

It's not even safe to do this:

    struct a {
        int x;
    };
    struct b {
        int x;
        int y;
    };

    struct b b;
    struct a *a = &b;

You have to write b like this:

    struct b {
        struct a inner;
        int y;
    };