From Programming Language Pragmatics by Michael Scott
Modern versions of C and C++ include a namespace mechanism
that provides module-like data hiding
Does C have namespaces similar to C++?
Are the "identifier name spaces" mentioned in C in a Nutshell the "namespaces" mentioned in Scott's book, and similar to namespaces in C++?
Thanks.
No, C does not have a namespace mechanism whereby you can provide “module-like data hiding”.
book quality
I do not know anything about the book you cited, but the word “namespaces” is one of those that gets overloaded to a lot of different meanings, just like “window”. (I question the validity of anything the author says for getting such a major point about one of the world’s oldest and most widespread computer languages so brazenly wrong.)
name spaces in C
“Name spaces” in C are a completely different mechanism, working for a completely different purpose. These are the name spaces discussed in “C in a Nutshell”. The words mean something different than C++ namespaces. Since David Rankin bothered to lookup chapter and section referencing the C11 Standard, these are the name spaces used in C:
label names
struct/union/enum tags
struct/union members
everything else (including enum values)
a quick blurb about scope
Keep in mind that this says nothing about scope, which is a separate mechanism. For example, a global variable and a variable local to a function may have the same name; nevertheless they share the same name space. The difference is that the global’s visibility is obscured by the local variable.
value of namespaces in C++
It is still unclear whether namespaces were a very useful extension to C++, and the argument as to its righteousness continues. The C crowd (mostly) agrees that the headache that adding namespaces would involve doesn’t justify the ends. I couldn’t find anything particularly useful on the interwebs right off the top of my keyboard, except for a couple of bland blurbs about emulating them using structs or (even worse) using macro abuse. If you really want to dig, you could probably find some useful discussions archived on the comp.lang.c newsgroup.
No, C has nothing like C++ namespaces. Most people have to fake what C++ does using a kind of underscore notation at best. This is at least what I do instead of trying to pack things into structs. Your IDE will still help with code assists, you just have to get used to using the underscore instead of a . for everything
C++
MyNamespace::MyObject.myMethodOrVar ...
Ends up looking like this in C
MyNamespace_MyObject_myMethodOrVar
May not be as smooth as C++ or Java, but it works and still helps avoid name collision. It's just a pain in the ass.
And yes, this doesn't give you syntactic devices like use. It is what it is I'm afraid.
Related
Why did the original C language not support initial declarations in for loop initializations?
Obviously the original creators, and then the pre-C99 standardizations, didn't specify it that way. But I can't seem to find any rationale for why that design choice was made.
The closest thing to an answer I seem to find is this answer explaining how mixing declarations and code was prohibited in order to allow for compilers to be single-pass back when that was important. At first glance it makes sense that declarations in a for loop statement would have the same/similar problems as declarations mixed with code.
But, pre-C99 C did support declarations at the start of blocks:
{
unsigned int i;
for(i = 0; i < WHATEVER; i += 1)
{
/* ... */
}
}
I don't personally see how the compiler logic for that is substantially different than for this:
for(unsigned int i = 0; i < WHATEVER; i += 1)
{
/* ... */
}
Seems to me that if a compiler can do the former single-pass, it could also do the latter. It might require that a for statement always create a scope block (even if followed by just one statement and not a { ... } block of statements), but I can't think of a way for such semantics to break any other pre-C99 C code (either the for statement is followed by a block in which case it's already "scoped", or it's followed by a single statement, in which case a new declaration wouldn't have been allowed in that single statement anyway).
So, why was this syntax "feature" initially omitted? Am I wrong in thinking that it would've been trivial to support without violating performance goals of the time? Did known language parser/compiler techniques at the time make it seem harder? Did it just get omitted because of minimalist design/mentality, since functionally it was possible to do the same thing (block around for loop)? Or was there an explicit language design reason against it (e.g. how Go initially excluded exceptions because the designers thought that made for a better language)?
Where I've looked
I've tried finding an answer to this here and through general web-search-fu, with no luck: all search terms I thought of seem to be saturated with confused questions about C for loop initial declarations, the "used outside of C99 mode" error message, etc. (Except the search term "rationale", which guided me to useful information, but nothing that answered this specifically).
I searched over this article by Dennis Ritchie himself on developing the language, and didn't spot anything.
I searched through my copy of The C Programming Language (2nd Edition), first reading the actual for loop explaining section, then checking the index for other mentions of the "for"/"for loop". I've read over a couple of other places I thought might mention it, but found nothing.
I don't believe there was any specific decision to exclude such features, nor rationale mounted to do so.
As romantic as it may seem to believe the designers (Kernighan, Ritchie, etc) thought of all the possibilities, and excluded features only after deep and meaningful consideration, the reality is that the early years of designing C (like quite a few other programming languages) followed a much more humble philosophy something like "Start small, don't sweat about adding features unless programmers are being PREVENTED from doing something".
Features like variable initialisation in for loops are programmer convenience - their absence didn't stop things being done. So, even if there was someone begging or campaigning for such a feature (which there probably wasn't), it probably went down in the priority order.
As to how things evolved .....
Before 1999, variable declarations were at the start of blocks in C (code commenced with { and ending at the closing }), not within other statements. This is the way things originally worked in pre-standard (K&R) C, and preceding languages like B (which was actually a cut-down derivative of preceding languages).
Variable declaration/initialisation within a for loop was introduced first into C++. It appeared pretty early on (e.g. Section 19 in the ARM), and was eventually introduced in the first C++ standard that was ratified in late 1998.
There was some discussion in the C standard committee, during the process of drafting the C++ standard (which took a decade) about adopting some features of C++ into C. That discussion was often mostly along the lines of "would anything else in C break if we added this?". A number of compiler vendors had already implemented several such features into their C compilers as optional extensions (or their C compilers were actually C++ compilers, with settings to disable C++ features incompatible with C), so discussion about adding those features was pretty brief. Therefore, those features easily added to C from C++ appeared in the 1999 C standard. Variable declaration/initialisation within a for loop was one of those features.
From that history, there is no evidence of any particular decision or rationale to exclude such features from early C - in short, it probably simply wasn't thought of.
Today i was presented with a wiered fact (or not)
it was said:
"At it is disallowed to write long, descriptive identifier names, and forbidden to write Comments for Linux Drivers written in ANSI C."
When i asked "WTF? Why?" i was told it caused performence issues and errors of such...
not many details there.
I am supprised, but have to ask...
Can this be real?
knowing that Comments are stripped by the compilation pre-processor,
and that Identifiers are either way converted to adresses.
so... Can it cause Problems ?
Well, ANSI C is a standard, and a standard is something itself that everyone must follow (I mean compiler designers and programmers, if they decide to support it).
ANSI C standard states that exported identifiers (yeah, exported identifiers are stored as symbols in symbols table as is, not just addresses) must not be longer than 6 characters, and non-exported identifiers are ok to be not longer than 31 character.
On commenting. Except some obvious pitfalls like accidental code swallowing by multi-line commenting, I recommend you to read Coding Style article for Kernel developers which explains what kind of comments are not encouraged.
Absolutely not. Whatever identifier you used in your code, they will be translated to symbols by compiler.
Also, all comments will be ignored by the compilation pre-processor.
The only effect of comments are help you understand code more quickly .
The only performance impact comments can have is during compile time, though I would say it is neglectable, unless you write whole books as comments.
The identifer names are translated to symbols, so there is also, at best, a performance impact at compiletime, which again is neglectable. Identifer names might hit a maximum limit, but to be honest, I never encountered a problem because of to long identifier names.
No, the first step in the compilation is pre-process your source code to remove comments and do other tricks like expanding macros.
Identifiers are often translated into pointers (to symbol table entries).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the most common naming conventions in C?
Is there a official (or widely used) naming convention for the C language after all? One like Java's naming convention (UpperCamelCase case for classes, lowerCamelCase for methods, etc)?
I've seen many different conventions, like variable_name, variableName, variablename, etc. Is there one that is used by most C programmers?
EDIT: Just to make it clearer, the question is if there is or there is not mostly used naming convention. Like one that programmers don't have to think about (like Java's, or C#'s).
In the style of the C standard:
Variable, function and struct naming schemes are undefined.
Use whatever style you prefer for your own new projects, keep consistent style within other codebases.
Personally I use camelCase - less use of shift and no annoying type encoding into variables, any decent IDE should be able to tell me what type a variable is.
Depends, e.g. if you write code in the linux kernel use snake_case.
See coding guidelines for the kernel.
If you're working on existing code, follow the existing naming convention used in that code. The only thing worse than a bad naming convention is a mixture of inconsistent naming conventions. (The same applies to brace styles, indentation level, and so forth.)
If you're writing new code, I'd personally recommend looking at the sample code in K&R and the C standard, but it's up to you.
Looking at mutter source code and evince source code, both still use C89 style of declaring all variables at the very beginning of the function, instead of where it is first used (limited scope is good). Why don't they use C99? GNOME 3 was launch recently and mutter is quite new, so that could have been a good opportunity to switch, if the reason was compatibility with old code style.
Does that mean that contributing code to GNOME needs to be written in C89?
The rationale can be linked to the same rationale behind Glib and GTK+:
No C99 comments or declarations.
Rationale: we expect GLib and GTK+ to
be buildable on various compilers and
C99 support is still not yet
widespread.
Source: http://live.gnome.org/GTK+/BestPractices
Speaking of scope, I guess you can still do this:
if (condition)
{
int temporary = expression();
trigger_side_effect(temporary);
}
In other words, each actual brace-enclosed scope can contain new variable declarations, even in C89. Many people seem surprised by this; there's no difference from this perspective between a function's top-level scope and any other scope contained therein. Variables will be visible in all scopes descending from the one that declared them.
Note that I don't know if this is supported by the GNOME style guide, but it's at least supported by C89, and a recommended technique (by me) to keep things as local as possible.
Many people consider declaring variables all over the place, as opposed to at the beginning of the block, bad style. It makes it mildly more work to look for declarations, and makes it so you have to inspect the whole function to find them all. Also, for whatever reason, declarations after statements were one of the last C99 features GCC implemented, so for a long time, it was a major compatibility consideration.
One of the classes I'm taking in college is where we are doing a ton of programming in C. We are supposed to use 'C' style naming conventions in the assignments or get docked marks (eg a variable is named like int line_counter, a function clear_array() ) I find this convention really really annoying esp coming after a year of Java where such things are named more conviniently like lineCounter or clearArray(). Underscores are annoying, a hassle to type and increase the amount of syntax errors. Why should this convention be followed? Is there some logic to it or some point behind it? Or is it just another trick to make 'C' even harder to write code in?
Style naming conventions are a matter of tradition, local agreement and uniformity. You have to get used to a different style because there's no guarantee, once out in the job market, that you will use the code convention you like. In this sense, the point is that you have to learn that the Java style is not the only style you will ever deal with.
On regard if it's a good decision or not, it's hard to decide. I am annoyed by styling violations as you are, even if I have tens of year of experience in programming, but you cannot really pretend to reform an old code to new conventions. It takes a lot of non-productive time and screws everything for the other programmers.
You can mitigate the problem of slow-to-type-underscore using tab-completion in your editor (e.g. vim). Writing a method will just become typing a few letters and pressing tab. It's unlikely you will hit an underscore in the first letters.
Getting used to a specific style convention is just a question of the number of lines of code you have written. In this case, that that you find annoying in C because you were used to Java, is also a convention in Python: Contrarily to you (I program mostly in Python), I like better the underscored variable names (although I understand the java ones are also very clear to read)
On the other hand, and as a curiosity, you probably know that the difficulty to write a given character depends on the local distribution of your keyboard. Many of the symbols used in C are a hell to write with, for example, a Spanish keyboard.
What I think it is a really bad idea, is not to use the standard conventions for the language and develop a custom convention. This is really bad for others and also for you because all the documentation, code etc you have to study or interact with will be written in the standard style for the language
There is no such thing as "C-style naming conventions"; you will find quite a number of different styles both in C code and in C++ code. That said, you will just have to suck it up and go with the convention required by your professor. The purpose of style conventions, in general, is to reduce errors and to make it easy to infer information about a symbol without needing to look up its declaration. That said, there are many differences about which style or styles are best. Having a consistent style, though, is important for the understanding of the code base as a whole, and it is probably easier for your professor to grade and understand the homework if it is all written using the same, consistent style.
Pretty much any company you work for will require you to adhere to the company's coding convention, so it is not unreasonable for your professor to have similar requirements. Although it took some getting used to Google's C++ coding conventions when I first started, it is undoubtedly a boon to the code's readability to be in a consistent style. Nothing is more unintelligible than a mix of different styles.
I disagree with your teacher's decision to dock points for capitalization, but you're going to have to follow his or her instructions.
Grades are intended to reflect understanding of the material. I personally found it sufficient when teaching introductory C courses to grade on understanding. Beginners have enough difficulty mastering language constructs. It is unnecessary and cruel to dock points for trivialities.
The merits of your teacher's particular style, or of following a corporate style, are separate questions.