acceptance of C standards

[Cubbi]

I imagine some people here care about C, and I am curious about the preferred standards: do you latch on every new bit of C11 that's supported by the latest alpha build of your favorite compiler? Do you just use C99? Do you (and why??) stick with C89?

Although I'm a C++ developer, I get to write C code once in a while, and when compiling C sources, our development environment is set up to use C99 across all platforms (different hardware, different C compiler vendors). It has been that way on my previous job, and the job before that, all the way back to about early 2002, which is when I last had to use C89 (and I don't look back, C99 is so much saner!)

This forum seems to be primarily hobbyists and students, I would imagine that having control of what to use, or learning something to use in future, people would be at C99 by default, C11 where possible, so I'm curious to hear a few opinions.

[Catfish3]

I use C99. I fell in love with VLA's, variadic macros and compound literals.

I have no interest in C11, because I don't see the improvement.

[chrisname]

It doesn't add anything useful. Waste of a revision IMO. The only interesting things are optional and therefore won't be supported by anything ever anyway.

[LB]

I actually don't like C. The issue is that just about all interfaces are based around it and if you want compatibility you're forced to use it. It is definitely a great language, but it feels like it is a huge limiting factor.

I see a lot of C practices that seem to be working around the fact that C is not C++, whereas in C++ compilers can often simplify things to be more efficient than C because of abstraction layers and inlining, but at the same time you have to use a C interface or things won't work.

I don't really know which standard I prefer - mainly because I don't use C :(

[z05DSL3A]

The main thing that I see with C11 is fixing what got broke in C99, thats got to be a good thing.

[Oria]

I've got the same opinion as LB. I find C too limited in this day and age for most programming industries I wish to become part of. I'm not really interested in low-level programming of hardware.

[1yR4jE8b]

When I write C, I use whatever standard the current C++ standard my compiler defaults to is required to be compliant with. It doesn't really change much though, so I don't pay it much mind.

[zb0S216C]

I don't think that the C standard has changed that much, definitely not enough to pay mind to the changes. I feel the same way for the new C++11 standard; the changes are minimal and not worth fussing over.

_Wazzak

[LB]

Framework wrote:

I feel the same way for the new C++11 standard; the changes are minimal and not worth fussing over.

I beg to differ - C++03 -> C++11 compared to C99 -> C11, C++11 seems like a lot changed. I think you're mistakenly thinking of C++98 -> C++03.

[zb0S216C]

@LB: Nope, I was right the first time.

_Wazzak

[LB]

http://en.wikipedia.org/wiki/C++11
Wikipedia begs to differ. Inspecting each element on that list makes the changes seem small, but added together C++03 -> C++11 seems pretty large to me. What do you think is minimal about it?

[Oria]

I would have to agree that C++11 is lovely. Just the fact that it makes a lot of things less verbose is great.

[Catfish3]

Not to further derail the thread, but many stuff from C++11 could have, and should have, been introduced in C++03 instead:

- right angle brackets in templates >>
- std::to_string() conversion functions
- std::unordered_map
- std::array
- file stream constructors overloaded to accept std::string
- the cstdint library, and long long
- automatic type deduction via the recycled auto keyword

I originally included initializer lists as well, but then I thought they're harder than it seems.

[LB]

Oria wrote:

I would have to agree that C++11 is lovely. Just the fact that it makes a lot of things less verbose is great.

Actually, Stroustrup specifically asks coders to write more verbose code.

@Catfish3 I agree, except maybe for auto - that sounds like quite a jump for C++03.

EDIT: To avoid derailing the thread, but to contribute to confusion, I will reply to Framework's post below in this post here.

@Framework those are what I would have called major changes, quite the opposite of minimal. And I don't see what's wrong with the lambda or member function syntax besides the lack of verbosity. The whole point of the new additions is to contribute to better code design (for_each, for instance) and better standardized cross-platform code (std::thread, for instance).

Do you expect to see a point if you don't learn them? Do you not learn them because you don't see a point? I am detecting a cyclic dependency on C++03.

[zb0S216C]

LB wrote:

"What do you think is minimal about it?"

Lambdas, "for_each", "auto", "std::chrono" and "std::thread", to name a few, are hardly ground-breaking additions, are they? I just don't see the point in learning something so trivial unless I have to. I mean, C++03 did just find without them.

Oria wrote:

"I would have to agree that C++11 is lovely."

Really? Lambdas aren't really all that beautiful, neither is the way one can define a member function.

But, yes, let's no derail the thread anymore.

_Wazzak

[Oria]

Actually, Stroustrup specifically asks coders to write more verbose code.

Maybe, however I would still rather use auto in many cases and I do like the initializer lists. I think to have verbose or non-verbose code is a matter of opinion, but I find that the least verbose makes it more clean (while still using common sense).

[LB]

(Sorry, Cubbi, I've destroyed your thread)

Using 'auto' is verbose - it is specifically telling a reader that you don't care to know the specific type of the object you're dealing with, and that the type is dependent on the value of an expression.

He gave this example: what does this function take as its parameters?

void drawRect(int, int, int, int);

Is that two points? Is that a point and a width+height?

void drawRect(Point, Point);
void drawRect(Point, Vector2);

;)

[Catfish3]

Using 'auto' is verbose - it is specifically telling a reader that you don't care to know the specific type of the object you're dealing with, and that the type is dependent on the value of an expression.

It's not "verbose", it's ambiguous not explicit. And it's the reason why I don't use it in range based for() loops, if I can help it.

I have one example of what I consider fair usage:

for (const auto &p: m);
// where m is an std::map 

Anyway, apart from the political aspect of changing the meaning of a legacy keyword, I don't see why it would've been difficult to add this feature in C++03.

[LB]

How will you deal with the return value of functions such as std::bind and other functions for which the standard does not specify a solid return type? This is what I was talking about, plus your example in certain cases where "using m_t = std::map<x<y<z>>>;" isn't already done for you.

[chrisname]

Verbosity means having a high ratio of syntax to semantics, i.e., something is verbose if it requires a lot of syntax to express a certain amount of semantics. So, auto is really the opposite of verbose. It expresses the same amount of semantics as an explicit type with less syntax (compare const std::vector<std::string>& and const auto&). Implicit typing may be less obvious, but certainly not more verbose, than explicit typing.