ee163ahj@sdcc13.UUCP (PAUL VAN DE GRAAF) (05/03/85)
[ Frobozz magic bug repellent ]
Overview:
I'm sure most of you (like me) find the method of information hiding
in C a bit excentric, but learn to live with it. Some code I've seen uses
macros like LOCAL, EXPORT, and IMPORT to make it more logical. I still don't
think this completely solves the problem. Since C doesn't allow nested
functions, you must resort to using global variables when functions need to
share variables. Of course you can put the related functions in a separate
file and declare the globals static, or depend on the order of declaration of
the globals, but these tricks are not always explicit and can cause problems
with maintainance and revision later.
Proposal:
Allow blocks (modules) at the outermost (global) level of scope.
The code inside of these blocks is treated as if it were in a separate file.
I think global variables within a module should be implied to be of "static"
type within the module, and functions implied to be of "extern" type within
the file that includes the module. This explicitly shows which variables are
shared within the module. [A minor point, I'll leave to language sematicians]
Modules, of course, could be nested with the expected results.
Simple example: (just a demonstration off the top of my head, don't flame it.)
===============================================================================
int global_var;
{ /* <--- start of module */
char buffer[BUFSIZE];
int buf_index = 0; /* <--- these vars are static. */
/* putch(): buffered putchar() aproximation, an extern int outside module */
putch(c)
char c;
{
buffer[buf_index++] = c;
if (buf_index >= BUFSIZE)
return(write(1, buffer, BUFSIZE));
else
return(1);
}
/* flush(): flushes the buffer for putch() similar to fflush of stdio. */
flush()
{
return(write(1, buffer, buf_index + 1));
}
} /* <--- end of module */
main()
{
putch('f'); putch('o'); putch('o'); putch('!');
flush();
}
===============================================================================
Analysis:
Implementing this change to the language is relatively painless. All
that is necessary is to treat modules as separate files. Nested modules and
my suggestion that a modules's globals be static may complicate things a bit,
but not unduly. As far as I can tell, only extra production need be added to
the grammar (IE. whatever -> '{' file '}').
Furthermore, it is downwardly (is this a word?) compatible to old C, and
a logical extension of the blocks availiable within functions.
Questions:
Does anyone see anthing wrong with this? I just came up with this idea
this morning, and have not thought it out too much, but the concept seems so
simple that I decided to post anyway. More importantly, do you think this
belongs in the language? Or is it one of those things that will inspire
religious discussions about how much of a travesty this is to the language etc.
[ I must say I am growing weary of indentation and if (10 == foo) articles! ]
Comments are welcome...
Paul van de Graaf sdcsvax!sdcc13!ee163ahj U. C. San Diego thau@h-sc1.UUCP (robert thau) (05/04/85)
> Overview: > I'm sure most of you (like me) find the method of information hiding > in C a bit excentric, but learn to live with it... > > Proposal: > Allow blocks (modules) at the outermost (global) level of scope. > The code inside of these blocks is treated as if it were in a separate file. The syntax proposed is: int really_global_var; /* To set up context for the example ... */ { /* Begin module */ int module_var_1; /* Variables invisible outside the module */ char module_buffer[MAGICNUMBER]; ... functions using the variables ... } This leaves int externfunc(); { /* module here */ } looking too much like int externfunc() { /* Because of the missing ;, this becomes a function defn. */ } A new reserved word seems called for. > I think global variables within a module should be implied to be of "static" > type within the module, and functions implied to be of "extern" type within > the file that includes the module. This explicitly shows which variables are > shared within the module. [A minor point, I'll leave to language sematicians] > Modules, of course, could be nested with the expected results. I admit that this would make most module code a bit neater. The problem is that declarations in C are already a mess. Function arguments declared array are automatically coerced to pointer; variables declared in a compound statement are of storage class auto by default, except if they're functions, in which case the default is external, and so on. The last thing the language needs is yet another special case; my own humble opinion is that it would be better to keep the default 'extern' of files, so as not to drive everybody nuts. Aside from these gripes, I think the idea is a good one. Robert Thau rst@tardis.ARPA h-sc1%thau@harvard.ARPA
alexis@reed.UUCP (Alexis Dimitriadis) (05/05/85)
In article <224@sdcc13.UUCP> ee163ahj@sdcc13.UUCP (PAUL VAN DE GRAAF) writes: > I'm sure most of you (like me) find the method of information hiding >in C a bit excentric, but learn to live with it. >Proposal: > Allow blocks (modules) at the outermost (global) level of scope. >The code inside of these blocks is treated as if it were in a separate file. >I think global variables within a module should be implied to be of "static" >type within the module, and functions implied to be of "extern" type within >the file that includes the module. This explicitly shows which variables are >shared within the module. [A minor point, I'll leave to language sematicians] >Modules, of course, could be nested with the expected results. > >Analysis: > Implementing this change to the language is relatively painless. All >that is necessary is to treat modules as separate files. Nested modules and >my suggestion that a modules's globals be static may complicate things a bit, >but not unduly. As far as I can tell, only extra production need be added to >the grammar (IE. whatever -> '{' file '}'). > Furthermore, it is downwardly (is this a word?) compatible to old C, and >a logical extension of the blocks availiable within functions. Regardless of style, and (not very subtle) complications in implementing this change so that it actually does something useful: What about letting functions in DIFFERENT files share hidden data? That is, for me, the major stumbling block with the current semantics of external statics. The 'block' approach does not help any. (Unless you can leave a block open at the end of the file!! :-)). If you want strict NESTING of data hiding, you are still limited by being unable to declare a function inside a function. And what about joe() sharing data with fred(), and sharing OTHER data with bob(), without fred() and bob() sharing anything? If block structure is particularly applicable to a task, maybe you should use Pascal. (hee, hee). (But not :-). I think block structure is one of the few genuine advantages of Pascal). For a general environment for data hiding, wait for C++. It has all sorts of things like structures with "private" parts, which can be accessed only by "friend" functions. (hmmm). Alexis -- _______________________________________________ As soon as I get a full time job, the opinions expressed above will attach themselves to my employer, who will never be rid of them again. alexis @ reed ...ihnp4! - tektronix!reed ...decvax! /
mwherman@watcgl.UUCP (Michael W. Herman) (05/05/85)
Bascially what you're asking for has already been incorporated into a language called C++ developed by Bjarne Stroustrup at Bell Labs. References: 1. B. Stroustrup, "Classes: An Abstract Data Type Facility for the C Language", ACM-SIGPLAN Notices, 17, No. 1 (January 1982), pp.42-52. 2. B. Stroustrup, "Adding Classes to C: An Exercise in Language Evolution", Software Practice and Experience, 13 (1983), pp. 139-61. 3. B. Stroustrup, "Data Abstraction in C", AT&T BLTJ, 63, No. 8 (October 1984), pp. 1701-32.
gupta@asgb.UUCP (Yogesh K Gupta) (05/08/85)
> Bascially what you're asking for has already been incorporated into > a language called C++ developed by Bjarne Stroustrup at Bell Labs. > > References: > ... [ References to three papers by B. Stroustrup ] > The original posting suggested adding modules to C, thus departing from the language's concept that a "file" is a "module". C++, as described in the papers referred, does provide data abastraction but does not provide the concept of a module. Also, C++ is not available. Yogesh Gupta -- Yogesh Gupta Advanced Systems Group, {sdcrdcf, sdcsvax}!bmcg!asgb!gupta Burroughs Corp., Boulder, CO. -------------------------------------------------------------------- All opinions contained in this message are my own and do not reflect those of my employer or the plant on my desk.