Talk:C Programming/Particularities of C

VLA - variable lengh arrays
It think there is some confusion about arrays on this page. I like to reminde everboda that C99 has introduced VLAs - variable length arrays. And they do allow to pass the bounds to a function:

long Fu(int n, int m, long a[n][m]) long Fu(int n, int m, long a[*][*]); long Fu(int n, int m, long a[ ][*]); long Fu(int n, int m, long a[ ][m]);

Sadly the ISO Standart is not available online but cost $18 - so many of us (not me - I got one) have never seen it. And compiler vendors are not keen to tell us what they can't do.

I move the problem down to C89.

--Krischik T 07:14, 23 October 2006 (UTC)

This module is very biased. It was obviously written by someone who loves Java.

All the "real" weaknesses of C listed here refer to the fact that C does no run time checking of anything, such as array bounds. This is left for the programmer to do when necessary because it introduces overhead.

Saying that memory allocation is "tedious" or function pointers are "ugly" is very subjective. It is not a good argument at all. What is tedious or ugly to one person may be fun or beautiful to another.

"Not object-oriented" is a weakness? So, object-oriented is better than procedural? Once again, very subjective.

C is a language for experienced programmers. It is better suited for them because it gives them all the power they need to make high performance programs. If you are a beginner programmmer, other languages, such as Java, are better for you. Those languages force you to program "the right way", preventing programmer's mistakes and cleaning up the mess left behind.

So, to say that a language is better or worse than another, or to say that something is a weakness or strenght, depends on the programmer and the program beeing created.

Italo Tasso 23:05, 12 June 2007 (UTC)

3D arrays
I won't try to speak for the C99 changes, only the traditional behaviour.

In the first function, sizeof returns pretty much what you would expect -- the size of the object on the stack.

In the second function, the type intarray becomes int** (or equivalently int[][]) and sizeof returns the size of the pointer. This, dare I say, goofy behaviour comes from the very beginnings of the language and is a common cause of bugs for novices.

Is it possible for a function to accept the built-in 2D or 3D arrays of arbitrary size? For example, a function that accepts int a[5][4][3]; on one call, and later accepts int b[10][10][10]; in a later call?

My understanding is that it is not -- that is why programmers who need dynamic multidimensional arrays often don't use the build-in 2D or 3D arrays, but instead use Iliffe vectors or some other implementation.

If you think it is possible, please improve this book by telling us how to do it. What is the next step in improving the "lonely_count_sum" function in the following program to support arbitrary-size 3D arrays? --DavidCary (talk) 21:03, 10 September 2008 (UTC)


 * My direct attempt at doing so (using a type cast to int[x][y][z]) wasn't successful - gcc doesn't seem to like that cast even if xyz contain specific integers. One other common workaround besides the one you mentioned so far involves creating a 1-dimentional array to emulate a 3-dimentional one, which requires multiplication.   Because of this, I removed the accurracy tag from that section, but added a comment saying how it can be worked around.
 * However, based on reading of the rest of the article, I do question the POV. In particular, the "broken abstraction" implies that there's an actual deficiency by combining the concept of arrays and pointers, and when combined with other aspects within the module, I feel that there is a definate bias.  --Sigma 7 (talk) 04:01, 3 February 2009 (UTC)

NPOV
I recommend the following be removed:
 * 1) Broken abstraction between pointers and arrays
 * 2) Order of operations not totally intuitive sometimes
 * 3) Not object-oriented
 * 4) No overloading of operators
 * 5) No built in way of handling exceptions
 * 6) Requires use of macros and careful information-hiding and abstraction for code portability

1 is questionable, aside from variable length multi-dimensional arrays there's not much issue. 2 is questionable, since most other programming languages I've seen also have order of operations that appear when you factor in everything. 3 is claiming a whole paradigm is substandard. 4 is pointless, since you can emulate operators using function calls (plus not all languages support overloading those operators either). 5 is incorrect, you can use the signal function from the C89 library - most implementations that raise the SIGSEGV exception would most likely have it available to catch, and any other exception type not handleable by longjmp is generally for an operating system that has it's own exception handling libraries. I question 6, since you don't "require" macros for code portability (although you may need something similar for OS or library compatibility).

These items should be bunched together - if you can or should keep these, it makes the article look less like buckshotting.
 * Arrays do not keep track of their own length (as in Java for example)
 * No automatic array bounds checking
 * No garbage collection
 * Variables are not zero-ed at declaration
 * Tedious memory allocation

Also, the first bit in Tedious memory allocation implies that VLS can't exist, even though it's both supported in C99 as standard, and was allowed by most C89-style compilers as an extension.

Now, any comments? --Sigma 7 (talk) 04:17, 3 February 2009 (UTC)
 * I took up the challenge; the section no longer reads like it was written by a guy with a chip on his shoulder and now emphasizes the low-level nature of C and how it causes the weaknesses. I accidentally removed the C89 section, although I'm not entirely sure it should be restored. Finally, is implementing a real string type even feasible without an object-oriented language? BioTube (talk) 23:11, 14 March 2009 (UTC)
 * That was caused by a faulty closing comment tag. HTML Comment tags are   and  .  In any case, I removed a few others, since they aren't exactly weaknesses or duplicates.  As of now, I feel the NPOV tag can be removed.  --Sigma 7 (talk) 18:43, 16 March 2009 (UTC)
 * "is implementing a real string type even feasible without an object-oriented language?" Yes. Some versions of BASIC and Pascal somehow manage to have a real string type without being object-oriented. --DavidCary (talk) 12:26, 20 March 2009 (UTC)


 * The built-in 2D and 3D arrays have the flaws discussed earlier on this talk page. I think this page should help our readers by giving a link to a discussion of work-arounds. Even though one could argue that "the fact that work-arounds exist means that that isn't a "weakness" of the C programming language as a whole".
 * --DavidCary (talk) 13:16, 20 March 2009 (UTC)

rename of the page and rewording of "weaknesses"
I propose renaming this page as "Particularities of C" and do away of characterizing all the listed characteristics as weaknesses, those simple steps would address the non-NPOV issue. Any objections ? --Panic (talk) 06:51, 23 November 2009 (UTC)
 * I quite agree. The points mentioned in the section are not necessarily "weaknesses", they are just things found in a large amount of languages but are not present in C. Intermediate-Hacker (discuss • contribs) 18:01, 7 November 2011 (UTC)

Proposal to Remove "Lack of Garbage Collection"
I propose that we remove lack of garbage collection as a weakness, as it is really an optional component, and comes with a power.


 * In place of removal, provide valid content about positive reasons for not including it. --Panic (discuss • contribs) 05:35, 16 December 2011 (UTC)

Power of No Garbage Collection
The lack of garbage collection removes an unneeded overhead. I know I personally have never had to use GC in order to create a functioning program. As long as you are capable enough of figuring out when appropriate to free memory without any chance of zombifying it, the lack of GCs makes your code much more efficient.

There Is Optional Garbage Collection
All you have to do is use a library such as Boehm's Garbage Collector and you can start collecting! It is not that hard, just start using GC_MALLOC instead of malloc. Most high-level programming languages actually use Boehm's Garbage Collector, including Portable.NET, Mono, and GNU's D compiler.

Memory Leaks can be Detected
It is possible to use leak detectors, which will notify you when a leak is detected so that you can fix it during the debugging phase. As long as developers use good coding practices, they will not find memory leaks to scourge their code.

It would be useful, however, to find a place in the book to reference garbage collection libraries.

--Topsfield99 (talk) 20:26, 5 July 2010 (UTC)


 * In place or obscurity take the chance to not only state that memory leaks are easy to occur and provide methodologies and reference tools that will ease the burden of fixing those bugs. Take the chance also to explain some security concerns. --Panic (discuss • contribs) 05:35, 16 December 2011 (UTC)

Neutrality
The article starts with the statement that C has some weaknesses. While I agree that C has terse syntax and lacks some features found in more modern languages, the term "weaknesses" is prejudicial. C was designed in an earlier age when memory was dear and CPUs were slow. It was designed for a specific task. It was designed for experienced, skilled programmers. It is a testament to the insights of Brian Kernighan and Dennis Ritchie that it has survived and evolved to today.

As I recall the original title of this entire section was "Weakness of C" and some readers objected. Although the title of the section has changed, the bias of this section remains in the first sentence.

I am not suggesting that the issues discussed here are not important. They are, users of the C language need to be aware of them.

However, I am suggesting that many of the issues discussed here were the result of specific decisions by Kernighan and Ritchie. Revising this section so that it reflects the decisions and tradeoff would improve the objectivity of the section and be more informative.

Thanks. Dmp47 (discuss • contribs) 18:16, 31 December 2011 (UTC)DMP47


 * I've taken a new shot in solving the problem see if you agree and if not you can yourself attempt to address it. Panic (discuss • contribs) 20:19, 31 December 2011 (UTC)