danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0306291819.57515c8b@posting.google.com>...
>
> PROBLEM - Face B:
> [...]
> PROPOSED SOLUTION:
>      explicit    parameter variable modifier
> The above could be written as
>
> int f(explicit myGlobalData);
>
> says "I   m a honest function: I   m advising you that I   ll use the global
> variable".
>
> Implicances:
>  1 - the caller is obbligged to pass THAT variable, no matter of its
> type.
>  2 - it will not occupy stack space. (similar to implicance A.3)
>  3 - signatures are different (refer to implicance A.4)

It would be very confusing to have in the parameter list what does
not occupy the stack space nor have to be passed by the callers.
I'd rather write it like this:

    int f() explicit(myGlobalData);

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com> wrote in...
>
> PROPOSAL:
>  -   explicit    variable declarator modifier.
> +
>  - parameter name = explicit variable (typeless parameter declaration)
>
> SEMANTIC: an    explicit    declared variable will never be used but
> passing it as a parameter.
> Indirect implicance: it will not be passed thu the stack, as far as
> it   s not necessary because it   s scope-accessable.
>
> EXAMPLE:
>
> explicit int myGlobalData;
>
> void f(int a, myGlobalData)
> {
>   ...
> }
>
> void g()
> {
>   myGlobalData = 1; //error: not accessible since it   s not declared in
> the signature.
> }


I disagree. Where global variables exist, hiding them behind a function
or two is probably good practice, so I'd dispute whether your proposal
has much effect on well written code.

Still, if I read your proposal correctly, the following are well-formed
and allow any number of other routines to use the global data without
advertising the fact.

    int& MyGlobalData(myGlobalData)
    {
        return myGlobalData;
    }

    int GetGlobalData(myGlobalData)
    {
        return myGlobalData;
    }

    int GetSubtleData(myGlobalData)
    {
        int disguise = myGlobalData;
        return (((disguise+2)*3)-6)/3;
    }


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

K.Hagan@thermoteknix.co.uk ("Ken Hagan") wrote in message news:<3f027537$0$962$cc9e4d1f@news.dial.pipex.com>...
Hi,

>
> I disagree. Where global variables exist, hiding them behind a function
> or two is probably good practice, so I'd dispute whether your proposal
> has much effect on well written code.

Well, actually, it   s not intended to have effect on well-written code,
but prevent bad-written code.

It   s a tool a designer may count for prventing other people to mess
the code.
Let   s jump to your samples, they are interesting to the point:
>
> Still, if I read your proposal correctly, the following are well-formed
> and allow any number of other routines to use the global data without
> advertising the fact.

Yes, you are absolutely right, but, remember the in order to invoke
your functions:

>
>     int& MyGlobalData(myGlobalData)
>     {
>         return myGlobalData;
>     }
>
>     int GetGlobalData(myGlobalData)
>     {
>         return myGlobalData;
>     }
>
>     int GetSubtleData(myGlobalData)
>     {
>         int disguise = myGlobalData;
>         return (((disguise+2)*3)-6)/3;
>     }
>

the caller has still to receive the explicit-declared variable:

void caller(myGlobalData)
{
   int x = GetSubtleData(myGlobalData);
}

then the protection mechanism is still applicable. Moreover, it forces
a stub to receive the parameter not as a global var: let me rewrite
the latter:

void caller(myGlobalData)
{
  callee(GetSubtleData(myGlobalData);
}

void callee(int somethingNotGlobal);

see what I mean?

the    globality    factor still remain hidden (or protected).
Since a global var. is explicit-declared, there   s no wrapping function
or trick to un-explicit it, unless you assign it to a non-explicit
declared global variable, what I would consider malicious and beyond
the scope of this proposal.

  Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<danielgutson@hotmail.com> wrote...
>
> Yes, you are absolutely right, but, remember the in order to invoke
> your functions:
>
> > [snip]
>
> the caller has still to receive the explicit-declared variable:
>
> void caller(myGlobalData)
> {
>    int x = GetSubtleData(myGlobalData);
> }

Then I've misunderstood your proposal, and it looks like marking
a variable "explicit" prevents anyone from even indirectly using
it without naming the variable.  I can't imagine ever wanting to
mark a variable explicit under these rules.

I also don't see how such variables can be accessed, since they
can only be mentioned by procedures that were "given" them by
their caller. Where does this "bottom out"? How do we get to
mention the variable in the first place?

Either you can use such variables without your caller knowing
or you can't. The first lets you hide the fact and the second
makes them unusable. No?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi all,
 I   d like to share this idea and see your opinions.

[Note: same coin problem is splitted in two faces]

PROBLEM - Face A:
 When we see a function   s or method   s declaration, we can only ensure
that AT LEAST the parameters are the input data set.
But we have no way of knowing what other data it may use (such as
global vars, or even data members).
There is no way of    protecting    a datum (a variable) from being
   hiddenly    used in the same scope it   s defined.

In other words, what I want to have is a mechanism of warranting that
the usage of such datum will be ALWAYS visible.

PROPOSAL:
 -   explicit    variable declarator modifier.
+
 - parameter name = explicit variable (typeless parameter declaration)

SEMANTIC: an    explicit    declared variable will never be used but
passing it as a parameter.
Indirect implicance: it will not be passed thu the stack, as far as
it   s not necessary because it   s scope-accessable.

EXAMPLE:

explicit int myGlobalData;

void f(int a, myGlobalData)
{
  ...
}

void g()
{
  myGlobalData = 1; //error: not accessible since it   s not declared in
the signature.
}

void h(const myGlobalData)
{
  int x = myGlobalData + 1; //ok
}

void use(myGlobalData)
{
   f(1, myGlobalData);
   h(myGlobalData);
}

Implicances:
 1 - explicit-declared global variables are only accessable by
declaring them (with no type, just their name) in the parameters list
[same for class members]
 2 - explicit-declared global variables [/members] may have the
   const    modifier in the parameters list (see sample function    h   )
 3 - explicit-declared global vars/members do not occupy stack space
during function call (they have no bytecode generation implicances;
its a matter of accessibility only)
 4 - The signature of a function receiving an explicit-declared
variable is NOT the same as the analog signature with the type:
        (int a, myGlobalData)
is not the same as
        (int a, typeof(myGlobalData) )

 5 - [needs to be expanded in a later message] An explicit-declaration
is transitive to the data members of the object:
      struct S { int a; int b; };
      explicit S s; //s.a and s.b are explicit-declared.

      int sum(s) { return s.a + s.b; }

 6 - enhances    const    granularity for methods: explicit-declared data
members can be const-declared individually, in contrast with the
   const    method-modifier.
   6.1 - a    const    method must accept the explicit-declared data
members as const too:
   class C
   {
      explicit int data;
      int calc1(data) const; //error
      int calc2(const data) const; // ok
   };

 - 7 There   s no need to pass the parameter in the function call if it
is at the end (similar as a    default parameter   ). [refer to FACE B
below]


PROBLEM - Face B:
 While declaring a function that uses a global variable, there is no
way of expliciting it in the declaration (unless you pass it as a
parameter, with a performance penalty, despite a compiler may optimize
it).

int myGlobalData;

int f()
{
  int x = myGlobalData + 1;
}

There are two ways of doing it:
  - adding a comment:
int f(); // reads myGlobalData

  - receiving it as parameter:
int f(int theGlobalData);

PROPOSED SOLUTION:
     explicit    parameter variable modifier
The above could be written as

int f(explicit myGlobalData);

says "I   m a honest function: I   m advising you that I   ll use the global
variable".

Implicances:
 1 - the caller is obbligged to pass THAT variable, no matter of its
type.
 2 - it will not occupy stack space. (similar to implicance A.3)
 3 - signatures are different (refer to implicance A.4)

CONCLUSIONS of both faces:
 - Both faces are part of the same problem, and can be combined.
 - Program understanding is easier
 - Self documentation is enhanced.

The resulting implicances of combining both explicit declarations, is
that implicance B.1 overwrites implicance A.7

I   d be glad to show some motivations of this proposal, but the message
would become too large. Feel free to ask for them for a later message.
Let   s say that I   m an offuscated bug-fixer and legacy code maintainer
:)

Thanks, sorry because of the extension of this message, and thanks for
your comments.

   Daniel.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]