public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
From: "Saffi Hartal" <shartal@artemis.globaloop.com>
To: <c++-embedded@cygnus.com>
Subject: static init function
Date: Wed, 26 Aug 1998 07:32:00 -0000	[thread overview]
Message-ID: <011301bdd106$ce18e970$6cdfcbc7@shartal.ariadnaweb.com> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

I wrote : 

I sometimes use that way to init my modules.
 if I want to init the arrays and variables i use (i 
don't always create a class which supply the interface cause the people around 
me use C routines instead of C++ ), what do you think about it.
 
static int 
init_module(void) {     /* code to init the module 
*/     return(0); }
 
static int init_var=init_module();
    Saffi
 
Danny answered :
One problem surely exists with this solution: static functions are now 
considered deprecated according to the C++ standard. Danny 
 
I didn't really understood so i asked him for more ...
we answerd :
Here's a more detailed account: In standard C, a function declared 
static has an internal linkage, i.e., it is accessible only from within 
the translation unit (source file) in which it was declared. Though 
still supported in C++, this convention is now considered deprecated. 
Therefore, future releases of your C++ compiler may issue a warning message 
when finding a static function that is not a member of a class. In 
order to make a function accessible only from within the translation unit 
in which it is declared, you should use a nameless namespace instead.  
//File hidden.cpp namespace { //nameless int init(); 
//accessible only from within this file } The keyword 'static' was 
already used in excess in C++ for various purposes. With the introduction of 
namespaces to the language, it seemed more plausible to use that mechanism 
to confine the access to identifires which otherwise would be 
global. I hope that answers your questions, and sorry if that urges 
you to consider revising your existing programs. Of course, you can post 
my previous reply as well as this one. Best, Danny 
Kalev System analyst and software engineer J16
 
    I hope that it was also interesting for you.
 
            
thanks
                    
by Saffi

                 reply	other threads:[~1998-08-26  7:32 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='011301bdd106$ce18e970$6cdfcbc7@shartal.ariadnaweb.com' \
    --to=shartal@artemis.globaloop.com \
    --cc=c++-embedded@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).