Easy to read, good standard C
Your code sucks
Ok... one more thing....
This is really just a text formatting nit but putting the return type on a separate line above your function declaration is rather coufusing since it's not really done anymore. It's coding style circa 1980 and may result in "Old style declaration" warnings on some compilers.Code:static void set_text (struct Buffer_Info *const buffer, char *const text) { buffer->text = text; }
Since all functions are static by definition, that keyword is superfluous in this case.
Last edited by CommonTater; 04-27-2011 at 11:30 AM.
Although I am do not use this style myself, I do not consider it confusing, especially if the style is consistent, but of course this is indeed a matter of subjective style. As for the warnings: that should not happen because the extra whitespace in this context is not significant.Originally Posted by CommonTater
I recall pointing out to you that this is false: functions are not "static by definition".
Last edited by laserlight; 04-27-2011 at 11:38 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
To follow up what laserlight said, and clarify a little:
The static keywords is used for two purposes, to modify the storage duration of an object, and to modify thelinkage of a symbol. This dual usage is something I found very confusing at first, and think it was a dumb thing for the language to do. One more reserved word wouldn't really hurt the language or it's usability, and would make this issue much clearer. But it is what it is.
When applied to local variables, it serves to modify the storage duration. This makes static variables exist (and retain value) for the entire duration of the program, including between funciton calls, when other local variables in that function would fall out of scope. Since you can't have a "local funciton", or a funciton within a function, static doesn't make sense in this regard.
When applied to global symbols (global variables and functions), it serves to modify the linkage of the symbol. Specifically, using static for global variables and functions makes them visible only within that translation unit (roughly, a .c file). This provides some sort semblance of "private" members and functions, and can help keep you from cluttering up your global namespace.
Thanks anduril... I pretty much knew that and I happen to agree it was a really dumb decision to use the same keyword in completely opposite ways... I don't, however, see much value in declaring *every* function static... especially when you're about to prototype them in a header file.
But, it does explain this, found in the top of a header file from some old code I had to update (comments mine)...
Code:#define persist static // used with variables #define private static // used with functions
Last edited by CommonTater; 04-27-2011 at 12:02 PM.
Agreed. It should be used for helper functions that are not part of the interface of the library.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
This is still the style used by the BSDs, and there is a very good reason for it: you can easily grep for a function definition using the beginning-of-line metacharacter ^.
I've found this extremely helpful in searching through FreeBSD's source code. It may not be all that useful for those using IDEs, of course.
Yeah those of us using actual editors just use the "find" function....
It's not a matter of "find", it's a matter of "find the definition". Your editor can only do this if it has indexed the files you're interested in. If it's your current project, that's not too tough (vim and, I presume, emacs, are able to do this, too); but if you're searching through a large tree, being able to grep for function definitions is very handy. You might not have needed to do this before, but I have.
I'm not sure I understand the reason for sniping at environments that differ from yours.
That is silly reasoning.
"Hey guys, YOUR environment only works if you do this one specific thing, whereas MY environment only works if I do this one specific thing, so mine is better!"
Besides, MSVC++ has been able to show you a tool tip popup as you start to type function names, showing you all of their arguments, since I don't even remember when.
Quzah.
Hope is the first step on the road to disappointment.
I'm not sure how you took that to be my argument at all. I never claimed that an editor is poor because it can only complete identifiers in files that it knows about. That's simply a limitation of editors in general.
The point wasn't that "your editor can't do this". The point is that there is a valid reason for putting a function's return type on one line and its name on another.
I've found this useful when searching through FreeBSD's source tree (as in, the whole source code, kernel + userland). That doesn't mean I think that text-completion in an editor is a bad thing, or (I'm really not sure how you got this idea) that Visual C++ cannot do that.
Not everything on the Internet is a competition. The fact that a function name at the beginning of a line makes it easy to grep through a large tree--one that you don't have loaded into your editor--is not an argument against text completion in editors. It's not an argument that one method of programming is better than another. It just gives you a potential benefit at almost no cost (one line of vertical space per function and, I suspect, one extra byte per function on Windows since newlines cost two bytes).
But I'm not trying to say this is the method to use. I'm just pointing out why it's used. Saying there are reasons to use one method doesn't automatically mean that other methods are worse!
Last edited by cas; 04-27-2011 at 05:16 PM. Reason: Clear up some wording.
Oh horsecrap ... I have several different editors here that can find text in the middle of a line as well as searching in files.
Want to find the definition of MyFancyFunc() ... just search for it...
@quzah... it's not about showing call tips... it's about doing a simple text search in a windows editor... or for that matter with windows desktop search itself...
I didn't say it was about that. His reasoning was "It's hard to find out what a function is supposed to take for arguments, so if you do this, it's easy!" He backed it up by saying that you had to do all this work to get it to work right, and that he could just grep. I pointed out that in MSVC++ you don't even need to do that, because as soon as you start to type the function name it tells you what the function takes for arguments.
I didn't say there was anything wrong with CTRL+F.
Quzah.
Hope is the first step on the road to disappointment.
Pelles and CodeBlocks also have calltips... the little pop up descriptions... for most things, as do most IDEs.
Makes me wonder what kind of primative tools they're using.
IOW... there is a reason these IDEs exist...
Yes, once you've loaded (and/or indexed) the files, you can search. Now, you may prefer loading 10000 files at once and searching them, but I don't. I'm not saying you're wrong, but I am saying there are people who prefer a tool like grep to search through thousands of files. And it's not a matter of searching in the middle of a line for a function name, obviously, because grep could easily do that. Such a search would find all uses of the function, not just the definition. By putting function names at the beginning of a line, it's easy to find only the definition.
I said nothing about finding out the parameters of a function. I talked about finding a function definition (on multiple occasions I've wanted to see the implementation of a function whose whereabouts were unknown). But that's neither here nor there, because, again, it's not about searching in the current file. I never said you have to do a lot of work, either. You are really misrepresenting what I'm saying. The argument is simple: you can search through arbitrary files for function definitions if the names of functions are at the beginning of a line. The side note was that editors can only do text-completion in files they know about. That's it.
I think you're hung up on the idea that you have a project loaded into your IDE and, why would you use anything other than the IDE to search for functions? But there are many times I want to search through either multiple source trees, or a source tree not geared toward an IDE build (many open source projects are like this). So if I want to simply find a function definition, I could either import the source into an IDE and index it, or do a grep. You may prefer the former, and that's fine with me; but I prefer the latter. It's not a matter of "this is better", but "this fits my workflow better."
I really don't understand why you think this is an either/or situation I'm presenting. I never said "if you use grep, you must never use an IDE that can do completion", or "if you use an IDE, you're using an inferior tool." Why must this be taken as a zero-sum game? It's simple: if you put function names at the beginning of a line, there's this additional benefit that some people find useful.
It's ugly. I don't like ugly code. Besides, you can just grep the name of a function and grep will tell you what line in what file it is on anyway, so you don't have to force it onto its own line. I know why it is done, it's just ugly, and I've never had any reason to do it that way.Why do you keep saying "well you have to load it into your IDE to know!" - What do you think grep is doing? It's loading each file to find out what you asked it to find. It's no different than loading them and having your IDE find them for you.
Quzah.
Last edited by quzah; 04-27-2011 at 06:42 PM.
Hope is the first step on the road to disappointment.
