Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > is this declaration correct

Thread Tools

is this declaration correct

Tim Rentsch
Posts: n/a
Phil Carmody <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Seungbeom Kim <(E-Mail Removed)> writes:
>> > On 2012-07-21 13:53, Tim Rentsch wrote:
>> >>
>> >> Actually what he wants is to _limit_ the visibility to something
>> >> smaller than file scope. To do that, it is necessary to declare
>> >> printf() directly, since doing a #include has defined behavior only
>> >> outside of all external defintions (and in particular, outside of
>> >> any function body).
>> >
>> > Why would anyone want to limit the visibility of library entities
>> > to something smaller than file scope? What benefits would it bring
>> > to make printf() visible to a function but not to anything else?

>> For the same reason that limiting visibility is always done, or
>> at least one of the same reasons, namely, to make sure it isn't
>> accidentally referenced somewhere it shouldn't be.
>> > It's not as if you'd want to hide printf() from clients and expose
>> > it only through some controlled interface so that it could be modified
>> > without affecting the clients -- it's a part of the interface already!

>> Can you not imagine any scenario when someone might want to call
>> printf() from one function, or a small number of functions, but
>> not elsewhere? Try this one: you're writing a set of library
>> functions, let's set a compacting storage allocator. The source
>> includes some test code (suitably ifdef'able) in the same source
>> files as the library functions. For test purposes we would like
>> to print out some information, eg, call printf(). But printf()
>> should never be used in the actual library functions; indeed,
>> maybe it cannot be because the program is supposed to run on an
>> embedded system. Using local declarations, the test functions
>> can call printf(), but there is no contamination of the general
>> file-level scope. Granted, this may not be a common use case,
>> but it seems like a perfectly reasonable one.

> Why is printf at file scope considered such an undesirable
> "contamination" in the case where the #if'ed test code is active?
> You've contaminated the library with all the test functions already,
> and even with local declarations you still cause the linker to link
> your lib file to the stdio implementation library. I can't see why a
> file-scope printf symbol would be a straw that breaks any particular
> camel's back.

It's one motivation. I'm sure some people would find it sufficiently
compelling, and others not. Personally I like to limit the scope of
"dangerous" access as much as can be done practically; in this case
I don't see any significant downside to restricting the availability
(given the limited number of places where access is needed), so using
local declarations might seem like the right tradeoff. I accept that
other people might decide a different tradeoff is better. I guess
the point I'm trying to make is that there are weights on both sides
of the scale.
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can a static function declaration conflict with a non-static declaration? C Programming 4 12-12-2006 10:26 PM
maxplusII error: a deferred constant declaration without a full declaration is not supported Noah VHDL 5 04-07-2006 02:34 PM
"virtual outside class declaration" and "declaration does not declare anything" kelvSYC C++ 6 05-17-2005 08:58 AM
Function declaration in class declaration Ovidesvideo C++ 4 12-10-2004 06:36 PM
Intel C++ 8.0 : declaration hides declaration Alex Vinokur C++ 4 04-05-2004 09:49 PM