Just wanted to give a counter to Walter's recent const propaganda.

const in C++ is an incredibly useful tool, and can be used - both in its intended/designed way, and in unforeseen ways - as a very powerful compile-time design enforcement mechanism. For anyone willing to brave all 628 pages, I discuss many of these in Imperfect C++.

Sure, it has its flaws. No-one pretends that that's not so. Indeed, my latest "Flexible C++" instalment, called "Beware Logical Constness" (http://www.cuj.com/documents/cujexp0502wilson/), discusses how logical constness + multithreading is a dangerous combination.

What Walter seems never to acknowledge with C++, or, at best, to couch in terms of irrelevance, is that const is (or at least has become) primarily important for communicating design constraints.

Almost without exception, I couldn't give a flying fig whether the compiler puts my const variables in ROM, nor whether the compiler is prevented from making certain optimisations for fear of my constness being logical and not physical. I value const as a design enforcement mechanism. And, for that purpose, I have a hard time not considering anyone who stipulates it to be valueless as either dishonest or ignorant, because it is so manifestly demonstrable to be extremely useful.

Let me lay out what I think is the crucial difference between mine and Walter's positions, and why you should all be wary of believing either of us to be 100% correct on this subject. Walter is first and foremost a compiler writer, and as such he sees const as a flawed idea because of (i) the fact that it is useless for optimisation, and (ii) it adds a lot of complexity. He (apparently) couldn't care less about its usefulness in helping the compiler to enforce the programmer's design.

I am first and foremost a library writer, and as such see const to be a *hugely* successful idea because (i) it allows me to express highly important semantics to the users of my code, and (ii) it allows me to protect my code against misuse. I (admittedly) couldn't give a stuff about its ROMifications, and am largely unconcerned by the ability to subvert physical constness for logical constness (though I remain mindful of the dangers therein when I need to; hence the recent "Flexible C++" instalment mentioned above.)

Now, what I've recently asked for is a small, specific subset of C++'s const, namely in the enforcement of explicit instantiation of members. This has got NOTHING to do with truely const things that can go in ROM. It has got NOTHING to do with any type of physical / logical const subversion. And, unless I'm a complete moron, it will add VERY LITTLE complexity into the compiler.

But what it _will_ do is prevent errors of omission in the initialisation of the members of types in non-trivial constructors, and thereby make D a better language than it currently is for producing robust code. (That'd be a good thing, no?).

And do you know how I know this to be true, rather than just conjecture and pro-const propaganda? Because I made precisely that error of omission in the writing of Database.this() in std.openrj!!

If it helps people keep away from all the irrelevant arguments I've covered above, let's call it the 'explicit' keyword. It would be used as in the following example:

class X
{
public
    this(int i)
    {
        y = i;
        z = 1;
    } // y == i, z == 1

    this(long i)
    {
        z = 1;
    } // y == 0, z == 1

    this(short s)
    {
        y = s;
    } // COMPILE ERROR: explicit member 'z' not explicitly initialised

private:
    int                y;
    explicit int    z;
}


Now, please please please can we have on-point opinions on this particular facet of C++'s multifaceted const facility? I challenge anyone to demonstrate how having this facility will not be a manifest improvement in code correctness.


(Note: adding the 'explicit' keyword will not be a waste at all. I have several other plans for it, the seeds of which may be found dotted throughout Imperfect C++ <g> ...)



-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)

Synesis Software Pty Ltd
P.O.Box 125
Waverley
New South Wales, 2024
Australia

-----------------------------------------------------

Does the compiler also complain if you assign an explicit more than once? If so, then this could be considered similar to 'final' variables in other languages. I've often found a need for the latter in D (particularly with singletons), and had to fudge it through various means.

If this is not the same thing, then I'd like to ask for a 'final' ... in /addition/ to what you're describing. They are related, and they do catch implementation errors at compile-time.

- Kris


In article <d0nua5$di5$1@digitaldaemon.com>, Matthew says...
>
>Just wanted to give a counter to Walter's recent const propaganda.
>
>const in C++ is an incredibly useful tool, and can be used - both in its intended/designed way, and in unforeseen ways - as a very powerful compile-time design enforcement mechanism. For anyone willing to brave all 628 pages, I discuss many of these in Imperfect C++.
>
>Sure, it has its flaws. No-one pretends that that's not so. Indeed, my latest "Flexible C++" instalment, called "Beware Logical Constness" (http://www.cuj.com/documents/cujexp0502wilson/), discusses how logical constness + multithreading is a dangerous combination.
>
>What Walter seems never to acknowledge with C++, or, at best, to couch in terms of irrelevance, is that const is (or at least has become) primarily important for communicating design constraints.
>
>Almost without exception, I couldn't give a flying fig whether the compiler puts my const variables in ROM, nor whether the compiler is prevented from making certain optimisations for fear of my constness being logical and not physical. I value const as a design enforcement mechanism. And, for that purpose, I have a hard time not considering anyone who stipulates it to be valueless as either dishonest or ignorant, because it is so manifestly demonstrable to be extremely useful.
>
>Let me lay out what I think is the crucial difference between mine and Walter's positions, and why you should all be wary of believing either of us to be 100% correct on this subject. Walter is first and foremost a compiler writer, and as such he sees const as a flawed idea because of (i) the fact that it is useless for optimisation, and (ii) it adds a lot of complexity. He (apparently) couldn't care less about its usefulness in helping the compiler to enforce the programmer's design.
>
>I am first and foremost a library writer, and as such see const to be a *hugely* successful idea because (i) it allows me to express highly important semantics to the users of my code, and (ii) it allows me to protect my code against misuse. I (admittedly) couldn't give a stuff about its ROMifications, and am largely unconcerned by the ability to subvert physical constness for logical constness (though I remain mindful of the dangers therein when I need to; hence the recent "Flexible C++" instalment mentioned above.)
>
>Now, what I've recently asked for is a small, specific subset of C++'s const, namely in the enforcement of explicit instantiation of members. This has got NOTHING to do with truely const things that can go in ROM. It has got NOTHING to do with any type of physical / logical const subversion. And, unless I'm a complete moron, it will add VERY LITTLE complexity into the compiler.
>
>But what it _will_ do is prevent errors of omission in the initialisation of the members of types in non-trivial constructors, and thereby make D a better language than it currently is for producing robust code. (That'd be a good thing, no?).
>
>And do you know how I know this to be true, rather than just conjecture and pro-const propaganda? Because I made precisely that error of omission in the writing of Database.this() in std.openrj!!
>
>If it helps people keep away from all the irrelevant arguments I've covered above, let's call it the 'explicit' keyword. It would be used as in the following example:
>
>class X
>{
>public
>    this(int i)
>    {
>        y = i;
>        z = 1;
>    } // y == i, z == 1
>
>    this(long i)
>    {
>        z = 1;
>    } // y == 0, z == 1
>
>    this(short s)
>    {
>        y = s;
>    } // COMPILE ERROR: explicit member 'z' not explicitly initialised
>
>private:
>    int                y;
>    explicit int    z;
>}
>
>
>Now, please please please can we have on-point opinions on this particular facet of C++'s multifaceted const facility? I challenge anyone to demonstrate how having this facility will not be a manifest improvement in code correctness.
>
>
>(Note: adding the 'explicit' keyword will not be a waste at all. I have several other plans for it, the seeds of which may be found dotted throughout Imperfect C++ <g> ...)
>
>
>
>-- 
>Matthew Wilson
>
>Author: "Imperfect C++", Addison-Wesley, 2004
>    (http://www.imperfectcplusplus.com)
>Contributing editor, C/C++ Users Journal
>    (http://www.synesis.com.au/articles.html#columns)
>Director, Synesis Software
>    (www.synesis.com.au)
>STLSoft moderator
>    (http://www.stlsoft.org)
>
>Synesis Software Pty Ltd
>P.O.Box 125
>Waverley
>New South Wales, 2024
>Australia
>
>-----------------------------------------------------
>
>
>

Matthew wrote:

> If it helps people keep away from all the irrelevant arguments I've covered above, let's call it the 'explicit' keyword. It would be used as in the following example:
> 
> class X
> {
> public
>     this(int i)
>     {
>         y = i;
>         z = 1;
>     } // y == i, z == 1
> 
>     this(long i)
>     {
>         z = 1;
>     } // y == 0, z == 1
> 
>     this(short s)
>     {
>         y = s;
>     } // COMPILE ERROR: explicit member 'z' not explicitly initialised
> 
> private:
>     int                y;
>     explicit int    z;
> }

This sounds a lot like how "final" works in Java:

> class X
> {
>     public X (int i)
>     {
>         y = i;
>         z = 1;
>     } // y == i, z == 1
> 
>     public X (long i)
>     {
>         z = 1;
>     } // y == 0, z == 1
> 
>     public X (char s)
>     {
>         y = s;
>     } // COMPILE ERROR: explicit member 'z' not explicitly initialised
> 
>     private int          y;
>     private final int    z;
> }

And it actually does give an error similar to what you describe:

> *** Semantic Error: The blank final field "z" must be initialized in
> this and every constructor which does not call a form of this(); or
> else once in an instance initializer block or instance field initializer.

BTW; I normally use Jikes for compiling my Java (doesn't everyone ?)
Javac says a more boring: "variable z might not have been initialized"

--anders

Matthew wrote:

> Almost without exception, I couldn't give a flying fig whether the compiler puts my const variables in ROM, nor whether the compiler is prevented from making certain optimisations for fear of my constness being logical and not physical. I value const as a design enforcement mechanism. And, for that purpose, I have a hard time not considering anyone who stipulates it to be valueless as either dishonest or ignorant, because it is so manifestly demonstrable to be extremely useful.

I think "const" in the meaning of "readonly" could help with the
string literals blowing up in your face when you assign to them ?
(not happening on Windows, unless the compiler uses string pooling)

Like this change in a certain C++ compiler:
http://msdn.microsoft.com/library/en-us/vclang/html/
vclrfstringliteralshavepropertypeofconstchar%5B%5D.asp

> String literals now have the type const char [] and are now placed in a
> read-only section of memory. Changing that memory will now cause an
> access violation. Code compiled in previous versions using /GF will also
> cause the access violation.

It could also help with "remembering" to use Copy-on-Write ?

Like in C++ terms:

> #define READONLY const
> 
> char *upperstr(READONLY char *str)
> {
>   // Copy-on-Write
>   char *copy = strdup(str);
>   assert(copy != NULL);
>   return upperstr(copy);
> }
> 
> char *upperstr(char *str)
> {
>   int i, len;
> 
>   len = strlen(str);
>   for (i = 0; i < len; i++)
>   {
>     char c = str[i];
>     str[i] = toupper(c);
>   }
> 
>   return str;
> }

So that it would use the correct version, with string literals ?

With D, there's no difference between the two routines - except
that the bottom one forgets to .dup, and thus can't handle ""...

It might even help people to stay off the toString() value ?
Little things like that. Name it "readonly" if const is bad...


Some suggested using "in" vs. "out" here, but that would apply
to the value of str - right? (as in the pointer, not the chars)

--anders

"Kris" <Kris_member@pathlink.com> wrote in message news:d0nvsl$fn7$1@digitaldaemon.com...
> Does the compiler also complain if you assign an explicit more than
> once? If so,
> then this could be considered similar to 'final' variables in other
> languages.
> I've often found a need for the latter in D (particularly with
> singletons), and
> had to fudge it through various means.
>
> If this is not the same thing, then I'd like to ask for a 'final' ...
> in
> /addition/ to what you're describing. They are related, and they do
> catch
> implementation errors at compile-time.
>
> - Kris


Very good point.

Being as how I prefer to make the decisions when it comes to writing my code, I'd maybe suggest that we can have permutations of

    int    x;
    explict int    x;
    final int    x;
    explicit final int    x;

But that may be deemed overly complex.

Most certainly this issue needs to be resolved. I have no clear idea how, and suspect that it needs the wisdom and insight of big-W to come up with the solution.

One thing I do know: all operating systems should have identical behaviour in this regard.



"Anders F Björklund" <afb@algonet.se> wrote in message news:d0o1p4$hf5$1@digitaldaemon.com...
> Matthew wrote:
>
>> Almost without exception, I couldn't give a flying fig whether the compiler puts my const variables in ROM, nor whether the compiler is prevented from making certain optimisations for fear of my constness being logical and not physical. I value const as a design enforcement mechanism. And, for that purpose, I have a hard time not considering anyone who stipulates it to be valueless as either dishonest or ignorant, because it is so manifestly demonstrable to be extremely useful.
>
> I think "const" in the meaning of "readonly" could help with the string literals blowing up in your face when you assign to them ? (not happening on Windows, unless the compiler uses string pooling)
>
> Like this change in a certain C++ compiler: http://msdn.microsoft.com/library/en-us/vclang/html/ vclrfstringliteralshavepropertypeofconstchar%5B%5D.asp
>
>> String literals now have the type const char [] and are now placed in
>> a
>> read-only section of memory. Changing that memory will now cause an
>> access violation. Code compiled in previous versions using /GF will
>> also
>> cause the access violation.
>
> It could also help with "remembering" to use Copy-on-Write ?
>
> Like in C++ terms:
>
>> #define READONLY const
>>
>> char *upperstr(READONLY char *str)
>> {
>>   // Copy-on-Write
>>   char *copy = strdup(str);
>>   assert(copy != NULL);
>>   return upperstr(copy);
>> }
>>
>> char *upperstr(char *str)
>> {
>>   int i, len;
>>
>>   len = strlen(str);
>>   for (i = 0; i < len; i++)
>>   {
>>     char c = str[i];
>>     str[i] = toupper(c);
>>   }
>>
>>   return str;
>> }
>
> So that it would use the correct version, with string literals ?
>
> With D, there's no difference between the two routines - except that the bottom one forgets to .dup, and thus can't handle ""...
>
> It might even help people to stay off the toString() value ? Little things like that. Name it "readonly" if const is bad...
>
>
> Some suggested using "in" vs. "out" here, but that would apply to the value of str - right? (as in the pointer, not the chars)
>
> --anders

On Wed, 9 Mar 2005 23:12:22 +0000 (UTC), Kris <Kris_member@pathlink.com> wrote:
> Does the compiler also complain if you assign an explicit more than once? If so,
> then this could be considered similar to 'final' variables in other languages.
> I've often found a need for the latter in D (particularly with singletons), and
> had to fudge it through various means.
>
> If this is not the same thing, then I'd like to ask for a 'final' ... in
> /addition/ to what you're describing. They are related, and they do catch
> implementation errors at compile-time.

Doesn't 'final' (in those languages) require that the variable be given a value where it's declared i.e.

class A {
  final int a = 5;
}

of course we could diverge from this and allow

class A {
  final int a;
  this() {
    a = 5; //omit this and get an error.
  }
}

which is what Matthew is after.

Regan

> - Kris
>
>
> In article <d0nua5$di5$1@digitaldaemon.com>, Matthew says...
>>
>> Just wanted to give a counter to Walter's recent const propaganda.
>>
>> const in C++ is an incredibly useful tool, and can be used - both in its
>> intended/designed way, and in unforeseen ways - as a very powerful
>> compile-time design enforcement mechanism. For anyone willing to brave
>> all 628 pages, I discuss many of these in Imperfect C++.
>>
>> Sure, it has its flaws. No-one pretends that that's not so. Indeed, my
>> latest "Flexible C++" instalment, called "Beware Logical Constness"
>> (http://www.cuj.com/documents/cujexp0502wilson/), discusses how logical
>> constness + multithreading is a dangerous combination.
>>
>> What Walter seems never to acknowledge with C++, or, at best, to couch
>> in terms of irrelevance, is that const is (or at least has become)
>> primarily important for communicating design constraints.
>>
>> Almost without exception, I couldn't give a flying fig whether the
>> compiler puts my const variables in ROM, nor whether the compiler is
>> prevented from making certain optimisations for fear of my constness
>> being logical and not physical. I value const as a design enforcement
>> mechanism. And, for that purpose, I have a hard time not considering
>> anyone who stipulates it to be valueless as either dishonest or
>> ignorant, because it is so manifestly demonstrable to be extremely
>> useful.
>>
>> Let me lay out what I think is the crucial difference between mine and
>> Walter's positions, and why you should all be wary of believing either
>> of us to be 100% correct on this subject. Walter is first and foremost a
>> compiler writer, and as such he sees const as a flawed idea because of
>> (i) the fact that it is useless for optimisation, and (ii) it adds a lot
>> of complexity. He (apparently) couldn't care less about its usefulness
>> in helping the compiler to enforce the programmer's design.
>>
>> I am first and foremost a library writer, and as such see const to be a
>> *hugely* successful idea because (i) it allows me to express highly
>> important semantics to the users of my code, and (ii) it allows me to
>> protect my code against misuse. I (admittedly) couldn't give a stuff
>> about its ROMifications, and am largely unconcerned by the ability to
>> subvert physical constness for logical constness (though I remain
>> mindful of the dangers therein when I need to; hence the recent
>> "Flexible C++" instalment mentioned above.)
>>
>> Now, what I've recently asked for is a small, specific subset of C++'s
>> const, namely in the enforcement of explicit instantiation of members.
>> This has got NOTHING to do with truely const things that can go in ROM.
>> It has got NOTHING to do with any type of physical / logical const
>> subversion. And, unless I'm a complete moron, it will add VERY LITTLE
>> complexity into the compiler.
>>
>> But what it _will_ do is prevent errors of omission in the
>> initialisation of the members of types in non-trivial constructors, and
>> thereby make D a better language than it currently is for producing
>> robust code. (That'd be a good thing, no?).
>>
>> And do you know how I know this to be true, rather than just conjecture
>> and pro-const propaganda? Because I made precisely that error of
>> omission in the writing of Database.this() in std.openrj!!
>>
>> If it helps people keep away from all the irrelevant arguments I've
>> covered above, let's call it the 'explicit' keyword. It would be used as
>> in the following example:
>>
>> class X
>> {
>> public
>>    this(int i)
>>    {
>>        y = i;
>>        z = 1;
>>    } // y == i, z == 1
>>
>>    this(long i)
>>    {
>>        z = 1;
>>    } // y == 0, z == 1
>>
>>    this(short s)
>>    {
>>        y = s;
>>    } // COMPILE ERROR: explicit member 'z' not explicitly initialised
>>
>> private:
>>    int                y;
>>    explicit int    z;
>> }
>>
>>
>> Now, please please please can we have on-point opinions on this
>> particular facet of C++'s multifaceted const facility? I challenge
>> anyone to demonstrate how having this facility will not be a manifest
>> improvement in code correctness.
>>
>>
>> (Note: adding the 'explicit' keyword will not be a waste at all. I have
>> several other plans for it, the seeds of which may be found dotted
>> throughout Imperfect C++ <g> ...)
>>
>>
>>
>> --
>> Matthew Wilson
>>
>> Author: "Imperfect C++", Addison-Wesley, 2004
>>    (http://www.imperfectcplusplus.com)
>> Contributing editor, C/C++ Users Journal
>>    (http://www.synesis.com.au/articles.html#columns)
>> Director, Synesis Software
>>    (www.synesis.com.au)
>> STLSoft moderator
>>    (http://www.stlsoft.org)
>>
>> Synesis Software Pty Ltd
>> P.O.Box 125
>> Waverley
>> New South Wales, 2024
>> Australia
>>
>> -----------------------------------------------------
>>
>>
>>
>
>

Regan Heath wrote:
> 
> Doesn't 'final' (in those languages) require that the variable be given a  value where it's declared i.e.
> 
> class A {
>   final int a = 5;
> }
> 

I also always thought that "final" in Java was a replacement for "const" (besides meaning not virtual).

> of course we could diverge from this and allow
> 
> class A {
>   final int a;
>   this() {
>     a = 5; //omit this and get an error.
>   }
> }
> 
> which is what Matthew is after.
> 

Right now, "final" isn't documented (AFAIK), so I think that's a reasonable idea (I mean, it's not like it's set in stone what it does).

> Regan
> 

_______________________
Carlos Santander Bernal

Well, as far as Java goes, if you declare something as final, you need to set it in all constructors (if it's not already set within the declaration). If a constructor calls another constructor that initializes it, it's also fine.. If there is no constructor, it's an invalid class, if a constructor doesn't initialize it, it's an invalid constructor.

So this is not exactly what you'd like (because it includes the var being a constant), but I guess there are few cases where you'd both like to definitely initialize something and to also have it changeable (because if it's not final, you can simply uninitialize it later, so you again have no guarantee), so perhaps a solution is to simply adopt those final semantics (it would also make Java people switching to D happier :).


xs0


Matthew wrote:
> "Kris" <Kris_member@pathlink.com> wrote in message news:d0nvsl$fn7$1@digitaldaemon.com...
> 
>>Does the compiler also complain if you assign an explicit more than once? If so,
>>then this could be considered similar to 'final' variables in other languages.
>>I've often found a need for the latter in D (particularly with singletons), and
>>had to fudge it through various means.
>>
>>If this is not the same thing, then I'd like to ask for a 'final' ... in
>>/addition/ to what you're describing. They are related, and they do catch
>>implementation errors at compile-time.
>>
>>- Kris
> 
> 
> 
> Very good point.
> 
> Being as how I prefer to make the decisions when it comes to writing my code, I'd maybe suggest that we can have permutations of
> 
>     int    x;
>     explict int    x;
>     final int    x;
>     explicit final int    x;
> 
> But that may be deemed overly complex.
> 
> 
> 

How about

func(int[in] arr); // I won't touch the contents

func(int[inout] arr); // I may, same as the default

func(int[out] arr); // I won't read them, but will write

The last one is different from "out int[]" because it still gets the length and allocated memory, and is useful for declaring that the contents of the array don't influence the result.

Then there's the fun with

func(out int[in] arr); // illegal, can't have read-only to null :)
func(out int[inout] arr); // illegal, can't read from null
func(out int[out] arr); // the [out] has no effect, so prolly illegal
                        // too


func(inout int[in] arr); // I won't touch the original array,
                         // but may return a different one (cool
                         // when the original is sliced somewhere
                         // else) (CoW, basically)

func(inout int[inout] arr); // I may do anything

func(inout int[out] arr); // I may reuse the array or not (perhaps
                          // to avoid reallocation), but I don't
                          // care about its contents


Thoughts?


xs0


Matthew wrote:
> Most certainly this issue needs to be resolved. I have no clear idea how, and suspect that it needs the wisdom and insight of big-W to come up with the solution.
> 
> One thing I do know: all operating systems should have identical behaviour in this regard.
> 
> 
> 
> "Anders F Björklund" <afb@algonet.se> wrote in message news:d0o1p4$hf5$1@digitaldaemon.com...
> 
>>Matthew wrote:
>>
>>
>>>Almost without exception, I couldn't give a flying fig whether the compiler puts my const variables in ROM, nor whether the compiler is prevented from making certain optimisations for fear of my constness being logical and not physical. I value const as a design enforcement mechanism. And, for that purpose, I have a hard time not considering anyone who stipulates it to be valueless as either dishonest or ignorant, because it is so manifestly demonstrable to be extremely useful.
>>
>>I think "const" in the meaning of "readonly" could help with the
>>string literals blowing up in your face when you assign to them ?
>>(not happening on Windows, unless the compiler uses string pooling)
>>
>>Like this change in a certain C++ compiler:
>>http://msdn.microsoft.com/library/en-us/vclang/html/
>>vclrfstringliteralshavepropertypeofconstchar%5B%5D.asp
>>
>>
>>>String literals now have the type const char [] and are now placed in a
>>>read-only section of memory. Changing that memory will now cause an
>>>access violation. Code compiled in previous versions using /GF will also
>>>cause the access violation.
>>
>>It could also help with "remembering" to use Copy-on-Write ?
>>
>>Like in C++ terms:
>>
>>
>>>#define READONLY const
>>>
>>>char *upperstr(READONLY char *str)
>>>{
>>>  // Copy-on-Write
>>>  char *copy = strdup(str);
>>>  assert(copy != NULL);
>>>  return upperstr(copy);
>>>}
>>>
>>>char *upperstr(char *str)
>>>{
>>>  int i, len;
>>>
>>>  len = strlen(str);
>>>  for (i = 0; i < len; i++)
>>>  {
>>>    char c = str[i];
>>>    str[i] = toupper(c);
>>>  }
>>>
>>>  return str;
>>>}
>>
>>So that it would use the correct version, with string literals ?
>>
>>With D, there's no difference between the two routines - except
>>that the bottom one forgets to .dup, and thus can't handle ""...
>>
>>It might even help people to stay off the toString() value ?
>>Little things like that. Name it "readonly" if const is bad...
>>
>>
>>Some suggested using "in" vs. "out" here, but that would apply
>>to the value of str - right? (as in the pointer, not the chars)
>>
>>--anders 
> 
> 
>