Who here doesn't use C and why?

[Craze Frog]

The point is that C allows hex numbers with exponents.

It clearly doesn't do it very well, since this elsewhere perfectly valid e-notated number is refused: 0x5e-1. Either they should support hex numbers with e notation or they shouldn't. They can't just refuse some of them.

Or actually, they can if they want to annoy me.

Edit: So what you're saying that e-notated hex numbers are impossible to parse? I have to think about that.

[JamesM]

The compiler allows these two things, just not at the same time, which was not a stated requirement.

You're quite right. I didn't state the requirement properly. I saw that too when I reread my post but decided not to edit it. However in order to read and understand my previous comments in context, assume that requirement to be true.

I'm going to wrap it up here now. I've already said that I agree with you on this point, I can't see exactly what it is you're expecting to hear.

Cheers,

James

[Craze Frog]

Edit: So what you're saying that e-notated hex numbers are hard to parse? I have to think about that.

If that was was you said, then that was not what I wanted to hear, because it's simply not true. Parsing them correctly is almost trivial. The C authors simply decided against it.

[JamesM]

Edit: So what you're saying that e-notated hex numbers are hard to parse? I have to think about that.

If that was was you said, then that was not what I wanted to hear, because it's simply not true. Parsing them correctly is almost trivial. The C authors simply decided against it.

Not quite. E-notated hex numbers are OK to parse. It's resolving the ambiguity between an exponent-notated hexadecimal number and an expression involving subtraction (with no whitespace to resolve the ambiguity) [that is hard].

The problem is difficult because the resolution is hard even for a human. Person A may want to write an E-notated hex number. Person B may want to subtract from a hex number. How do you decide what to do?

As far as I can see you can:

(a) Default to E-notated hex number.
(b) Default to expression.
(c) Error and request extra whitespace to resolve ambiguity.

Cheers,

James

[froggey]

1) Pointers behave the way they do because the semantics of "++ptr" is "point to the next element". If ptr points to an integer, that means "point to the next integer". Not the second half of the current one, the next one. There is nothing "wrong" or "right" about this behaviour compared to what you would prefer, it's just the way C works. It ain't "broken", it's just not what you liked, so it's a matter of dislike, not breakage.

While you didn't reply to me, I must say that it is indeed not breakage, but that does not make it less horrible.
Apart from that, the semantics of the increment and decrement operators of C++ are very clearly described in the C++ ANSI standard. Sorry to disappoint you, but here it is: "The operand of prefix ++ is modified by adding 1, or set to true if it is bool (this use is deprecated)."

It does not mention special cases for pointers. So what you said is actually wrong. There are no such semantics defined for that operator.

You're right, the semantics are clearly defined, so why are you misrepresenting it? Quoting from the C++ standard:

The operand of prefix ++ is modified by adding 1, or set to true if it is bool (this use is deprecated).
The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer
to a completely-defined object type. The value is the new value of the operand; it is an lvalue. If x is not
of type bool, the expression ++x is equivalent to x+=1. Note: see the discussions of addition (5.7) and
assignment operators (5.17) for information on conversions.

This quite clearly tells us that ++ is is equivalent to using the addition operator, so even though there's no special casing for pointers here (and on that note, no special casing for any other type apart from bool) we have to check the sections on addition and assignment.

So 4+1 = 8 must come from the binary + operator (we assume they use the semantics of + when they said "adding", because else using ++ for pointer arithmetic would be a violation of the standard).

Why assume anything? It says right there. And didn't you say that the semantics were well defined?

The semantics of + is described as following: "The result of the binary + operator is the sum of the operands".

Did you completely miss the rest of the section describing semantics for +/- on pointers? I'd quote it, but it's huge

And after that, they contract themselves by making an exception for arrays, and defining non-array pointers to behave like they point to the first element of an array with 1 element.

I guess you didn't and just ignored bits of it. This is not a contradiction, it's defining additional behaviour for an operator under certain conditions (for example: while and do...while, while is used both times, but behaves differently in a well-defined way. Hardly a contradiction)

Did you catch that? Arrays are defined in terms of pointers (elsewhere), and pointers are defined in terms of arrays.

Hmm, no they're not.

For the purposes of these operators, a pointer to a nonarray object behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type.

They behave the same way "for the purposes of these operators", a bit different than the way you seem to be representing it.

[Craze Frog]

You have another standards document than me.

[Solar]

My version of the docs says the same as froggey's.

But I don't really get what this argument is about. The way C handles pointers is the way C handles pointers. You can take it or leave it, but long experience and copying of the semantics by many other languages should serve as proof that there's nothing "broken" about it.

[esa]

Who here doesn't use C (or it's derivatives like C++) and why did you make that choice?

My programming background is mainly in C, C++, Java, PHP, Common Lisp, FASM and Python. From that perspective I can say the following things about C...

1) The syntax is too complex.

Writing a parser for C would be a pain which stops me from writing programs that process and transform C source code.

2) The preprocessor is not powerful enough.

I can't use it for generating complex pieces of code. I would need something equivalent in power with Common Lisp macros.

3) Not extensible enough.

If you wanted to change something in the language you would have to go and modify the compiler itself which is a definite no-no. How easy would it be to extend C to support continuations?

4) Code and data distinctly separate entities.

And in addition C is not homoiconic.

5) Too high level.

C's way of abstracting things gets in my way. In the name of portability it hides things that IMHO should not be hidden. What if I really do need to check for overflow when adding two integers? Is there really no portable way of doing this? C imposes on me a set of limitations that force me to write workarounds.

6) Too low level.

I consider manual memory management a form of optimization and I don't want to optimize my programs until it is necessary.

[Combuster]

4) Code and data distinctly separate entities.

And in addition C is not homoiconic.

Oh, is it really?

[esa]

@Combuster

You just proved my point. C is obviously not homoiconic if that is the best C has.

However as a hack that piece of code is interesting. I'd never have thought that something like that could work.

http://en.wikipedia.org/wiki/Homoiconicity

The point being that C programs are not normally written like that i.e., the primary representation of C programs is not an array of short ints but C code e.g., function definitions, etc.

[Solar]

Just wanted to point out a tiny distinction again to reinforce my previous point.

esa doesn't like C because he would prefer a homoiconic language with a more powerful preprocessor, simpler syntax and different abstraction decisions (GC by default, overflow flag exposed to program).

If suddenly a language just perfectly suiting esa's demands would solidify out of thin air, esa would prefer it.

That still wouldn't make C "worse than esaLang" or "broken". It would simply be two different languages, each with its own pro's and con's in other people's eyes.

Which is why language bashing is such a waste of time. Lisp, Haskell, ASM, Pascal, C, C++, Java, Perl, Python, Groovy, Jython, C#, ... all of them have different aims, different scopes, focus on different things. None of them is "better" in a blanket way. Some are better for teaching beginners, some are better for RAD, some are better for one-shot tools, some give better control, some give better abstraction, yadda yadda.

What makes such threads as these result in flame wars every time is the thin line between saying "I don't like C because I prefer ..." and saying "C is bad because ...".

I'll quit now.

[esa]

@Solar

You are absolutely right and I was merely answering the original question of why I don't prefer C. That being said I actually do use C whenever it is necessary even though it isn't perfect... I don't believe that any language is.

If suddenly a language just perfectly suiting esa's demands would solidify out of thin air, esa would prefer it.

Which is why I'm making such a language. Its better to have a go at it than to simply whine about others not having already made such a language for me, isn't it?

[DeletedAccount]

After reading this thread more twice , it appears to be going nowhere . Each person adamant with his own views . May i ask, which all languages are worth learning (I mean HLL's ) other than C ? Language which i have atleast a reading familarity is C , C++ , Java , C# , Pascal , Basic , Python , Perl and i plan to learn Lisp , Prolog , Lua , Scala , SmallTalk . Which all other languages are worth learning?. I think learning a lot of languges is important coz each language has a different programing model , A concept which is natural is one language may be alien to other . Thinking in a different way sometimes makes problem solving much easier . When it comes tests most of them seem to test your problem solving skill than anything else .

Regards
Sandeep Mathew

[esa]

@SandeepMathew

Was it supposed to go somewhere?
After all it is pretty much a matter of taste...
Of course it is important to minimize one's required effort to produce something by choosing the right tool/language/library/etc for the job but other than that it is pointless to argue.

Prolog will definitely broaden your horizons (assuming that you can find a decent implementation with enough documentation) but you could also take a look at FORTH. FORTH is funny in the sense that it is stack based, low level and yet it is still simple enough to allow one to cook up one's own implementation in a reasonably short amount of time... definitely a learning experience.

[Combuster]

You just proved my point. C is obviously not homoiconic if that is the best C has.

IMO I just disproved that first part of your claim - there's no real distinction between code and data. (in formal logic that means that I disproved your entire claim as you say both to be true ) I give you the second one but only because of its ambiguous definition - you can use a function as an data structure (program code can be referred to as an array of bytes or anything) and vice versa (an array can represent code) but you are expected to use only one representation.