> No flame intended, but it sounds as if you have never written a device
> driver.

> MANY hardware registers found on MANY ICs which arc eommon on
> motherboards, video cards, I/O cards, network cards, you name it contain
> such things as write-only registers and dual-access registers.  It is
> ILLEGAL, IMMORAL, and FATTENING to attempt to read from such a
> write-only register; the result will be a bus error, or some other
> undefined behavior. ...

As a matter of fact, I have; but even if a 'writeonly' modifier existed, I
would never trust a high-level language compiler not to generate code that
reads the register anyway.  Device drivers, or at least parts this critical,
should be written in assembler.  Otherwise you're asking for trouble.

The original poster pointed out in e-mail that writeonly would be useful as a
modifier for pointer or reference types, especially when used in the argument
list of a function.  But an actual writeonly object would be useless.

Personally I think it is more important (now, while it may still be possible)
to remedy the loss of functionality of the 'const' modifier.  'const' was
supposed to be a guarantee that the system will protect the programmer from
accidentally clobbering the 'const' object, or having a user of his library
code do so; it was the system's job, not the programmer's, to enforce this
(unless the programmer grossly broke rules, such as by casting a pointer to
int and back again).  const_cast<>, which blows away this guarantee, is an
abomination and should be removed from the language.  If it's too late for
that, then I suggest we add a 'readonly' modifier to do the job that 'const'
used to do.

John David Galt
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 20 Aug 96 04:54:42 GMT, John_David_Galt@cup.portal.com wrote:

>const_cast<>, which blows away this guarantee, is an
>abomination and should be removed from the language.

While I can sympathise with this ideal, I can't agree until all
library vendors and all application code writers produce 100%
const-correct code. :-)  Until then, I must use casts to use code that
is missing legitimate const qualifiers, and const_cast<> is at least
better (more visible and self-documenting i.t.o. intent) than an
old-style cast.

True, like any language feature, const_cast<> can be badly abused.
But wouldn't you agree it serves a useful purpose?

---
Herb Sutter (herbs@cntc.com)

Current Network Technologies Corp.
3100 Ridgeway, Suite 42, Mississauga ON Canada L5L 5M5
Tel 416-805-9088  Fax 905-608-2611
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <m0urysM-00GSrqC@7.kurahaupo.gen.nz>, martin@kcbbs.gen.nz (Martin D Kealey) writes:
|> Ok, given that volatile already embodies both read & write
|> synchronization, then there isn't any point in separating them (I'd
|> thought it was just the reads which had to be synchronized).

Volatile does indeed imply both.  *Writes* to volatile objects are
classed as side effects, and as such must be completed at every sequence point.
Volatile writes are *also* classed as "observable behavior", along with
"calls to library I/O functions" and volatile reads, and observable behavior
is required to be preserved by any optimization. (Section 1.8 - Program execution,
paras 5 thru 7 in the April draft).

[Actually, para 7 makes *reading* a volatile object a side effect as well!]


Hmm, odd, I cannot find any place in the standard that requires the compiler
to assume the value of a volatile object may change between access. Sigh.

--
swf@elsegundoca.ncr.com  sarima@ix.netcom.com

The peace of God be with you.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <153001@cup.portal.com>,  <John_David_Galt@cup.portal.com> wrote:
>>> The readonly type is, of course, in C++ (and in C).  We call it "const".
>>> But what happened to writeonly?????  Having writeonly in the language
>>> would be VERY useful to writers of device drivers.  As well as a few
>>> other things.
>
>The last time I saw this silly concept was in Intel's April Fools' Day ad for
>a write-only memory chip.
>
>Why is it a silly concept?  Imagine any computer that has write-only memory
>installed.  If you were to pull out the WOM and throw it away, or replace it
>with a chip made of wood, no one using the machine would ever see any
>difference.

No flame intended, but it sounds as if you have never written a device
driver.

MANY hardware registers found on MANY ICs which arc eommon on
motherboards, video cards, I/O cards, network cards, you name it contain
such things as write-only registers and dual-access registers.  It is
ILLEGAL, IMMORAL, and FATTENING to attempt to read from such a
write-only register; the result will be a bus error, or some other
undefined behavior.  A dual access register is one with independent
meanings for read and write--the values read and written will have nothing
to do with each other.  And that, my friend, is just the tip of the
iceberg in device driver writing.

(There's also wonderful hardware hacks like registers which must be
programmed SERIALLY, hardware bank selection (which allows the hardware
designer to implement a large virtual register space witha  small physical
register space), "read-strobe" registers (registers which actually affect
hardware when READ, rather than quietly returning a value to the CPU and
doing nothing else), registers which behave differetnly for byte, word,
and longword access, and numerous others too disgusting and unbelievable
to mention.

So no, the concept of "write only" memory is NOT a silly idea, as those of
us who write device drivers for a living can attest to.

Scott

--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Scott A Johnson  <scottjoh@mdhost.cse.tek.com> wrote:
>The readonly type is, of course, in C++ (and in C).  We call it "const".
>But what happened to writeonly?????  Having writeonly in the language
>would be VERY useful to writers of device drivers.  As well as a few
>other things.

No, it would be almost useless.  Even less useful than volatile.  Its
only reasonable use would be in very low-level inherently unportable
code that needs to use a write-only memory-mapped I/O register.  Even
then, its only effect would be to warn the programmer if e accidentally
tries to read it.  I don't think that's worth another keyword, and the
baggage of another type qualifier.

>(While we are at it, we could add "readable" to the mix, which would serve
>the same purpose with writonly that mutable serves with const.)

For that to be useful, there would have to be some reason to have a
writeonly class object.  What semantics would that have?

>Is there a good idea (besides the obvious one that it wasn't voted in)
>that writeonly (or some similar keyword) ain't in the language???

Quite simply, it's useless.

-zefram


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Scott Johnson wrote:
: MANY hardware registers found on MANY ICs which arc eommon on
: motherboards, video cards, I/O cards, network cards, you name it contain
: such things as write-only registers and dual-access registers.  It is
: ILLEGAL, IMMORAL, and FATTENING to attempt to read from such a
: write-only register; the result will be a bus error, or some other
: undefined behavior.  A dual access register is one with independent
: meanings for read and write--the values read and written will have nothing
: to do with each other.  And that, my friend, is just the tip of the
: iceberg in device driver writing.

Yes, WOM exists and is useful.  However, I question whether a C++
writeonly keyword will solve any problems related to WOM.  My question
is, "Does writeonly (the keyword) state only that the C++ programmer
cannot read from the memory or does it also mean that the compiler cannot
generate code that reads from the memory?"

Normally, you wouldn't expect the compiler to generate code that
randomly reads from memory.  However, many architectures have
read-modify-write instructions.  If you make an object writeonly, would
that mean that the compiler would have to refrain from using such
instructions?  My guess is no.  Therefore, you'd still be in a bind.
When you write,

 writonly byte i;
 i = 0;

You wouldn't know if the compiler is going to use a write-only MOVE
instruction or a read-modify-write CLEAR instruction:
 (I'm not saying that all clear instructions on all architectures
 are read modify write.  It's just an examply that exists on some
 architectures).

   MOVE  0, DESTINATION
or
 CLEAR DESTINATION

My question is not about assembly language, but about the writeonly
keyword.  What exactly would it mean?

--
Mark Dancho      "You may be disappointed if you fail,
Dancho@asu.edu    but you are doomed if you don't try." --Beverly Sills



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <153001@cup.portal.com> John David Galt wrote:

> The last time I saw this silly concept was in Intel's April Fools' Day
> ad for a write-only memory chip.

Reminds me of Peter Gutmann's ultimate "compression algorithm" - reduces
all known types of data by at least 100%.  Unfortunately it's a bit
lossy, so the decompression works better in concert with a Ouija Board.

> Why is it a silly concept?  Imagine any computer that has write-only
> memory installed.  If you were to pull out the WOM and throw it away,
> or replace it with a chip made of wood, no one using the machine would
> ever see any difference.

> Wouldn't the same be true of a write-only C++ object?
> If not, please explain.

An actual writeonly object would be useless to anyone except a
device-driver writer; however a writeonly *reference* could refer to a
"normal" object which someone else is going to read; for instance, a
writeonly reference parameter on a function could not be read by the
function, but the object it refers to probably would be read by the
calling function to extract some result.  Given than nobody can see the
object via the reference, the compiler could potentially defer all
updates until just before the function returns; of course, dataflow
analysis gives similar results, but is usually limited in scope to just
the current function.

"writeonly" would of course be more useful in conjunction with a "pure"
function attribute (which would assert that the function doesn't rely on
anything beyond what can be accessed via its parameters), in much the
same way that "const" would be more useful in conjunction with a "clean"
function attribute (which would assert that the function doesn't modify
anything beyond what can be accessed via its parameters).

    -=*=-

I think there was an earlier proposal that "in" and "out" parameters
could be expressed with a notation somewhat like

   void foo_to_bar( Foo << in, Bar >> out );

but I think this lacks generality - there is no way to take a reference
or pointer to one of the parameters, and retain the attribute
information.

    -=*=-

So, would anyone like to take up the cudgels for the complete orthogonal set:

    const       (cannot be written to)
    writeonly   (cannot be read from)

    pure        (does not read anything except parameters and autos)
    clean       (does not change anything except parameters and autos)

    volatile    (can be changed at any time - reads must be synchoronised)
    inspectable (can be inspected at any time - updates must be synchoronised)

And what should they be called?

- Martin.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

From: Chelly Green <chelly@eden.com>
Newsgroups: comp.std.c++
Subject: Re: Whatever happened to writeonly?
Date: Fri, 16 Aug 1996 07:42:38 -0600
Organization: -
Lines: 84
Message-ID: <32147ACE.50A4@eden.com>
References: <320BC045.4DAD@eden.com> <4umc0r$dau@shelob.aracnet.com>
<153001@cup.portal.com> <4usrhl$cen@shelob.aracnet.com>
Reply-To: chelly@eden.com
NNTP-Posting-Host: net-1-041.austin.eden.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (Macintosh; I; PPC)

Scott Johnson wrote:
>
> In article <153001@cup.portal.com>,  <John_David_Galt@cup.portal.com> wrote:
> >>> The readonly type is, of course, in C++ (and in C).  We call it "const".
> >>> But what happened to writeonly?????  Having writeonly in the language
> >>> would be VERY useful to writers of device drivers.  As well as a few
> >>> other things.
> >
> >The last time I saw this silly concept was in Intel's April Fools' Day ad for
> >a write-only memory chip.
> >
> >Why is it a silly concept?  Imagine any computer that has write-only memory
> >installed.  If you were to pull out the WOM and throw it away, or replace it
> >with a chip made of wood, no one using the machine would ever see any
> >difference.
>
> No flame intended, but it sounds as if you have never written a device
> driver.

I haven't, but if I were, I would see how I could extend the language
with some classes of my own.

> MANY hardware registers found on MANY ICs which arc eommon on
> motherboards, video cards, I/O cards, network cards, you name it contain
> such things as write-only registers and dual-access registers.  It is
> ILLEGAL, IMMORAL, and FATTENING to attempt to read from such a
> write-only register; the result will be a bus error, or some other
> undefined behavior.  A dual access register is one with independent
> meanings for read and write--the values read and written will have nothing
> to do with each other.  And that, my friend, is just the tip of the
> iceberg in device driver writing.

So use a class that enforces this interface.

> (There's also wonderful hardware hacks like registers which must be
> programmed SERIALLY, hardware bank selection (which allows the hardware
> designer to implement a large virtual register space witha  small physical
> register space), "read-strobe" registers (registers which actually affect
> hardware when READ, rather than quietly returning a value to the CPU and
> doing nothing else), registers which behave differetnly for byte, word,
> and longword access, and numerous others too disgusting and unbelievable
> to mention.

    template<class T,class Bank,long addr>
    class BankSelectedWriteonlyRegister {
    public:
        BankSelectedWriteonlyRegister& operator = ( T v )
        {
            Bank::select();
            *reinterpret_cast<volatile T*> (addr) = v;
            return *this;
        }
    };

Usage:

    struct OurBankSelector {
        static void select() { *(volatile char*) 0xF8 = 3; }
    };

    BankSelectedWriteonlyRegister<short,OurBankSelector,0xF0>
the_register;

    void f()
    {
        the_register = 0x14;
    }

> So no, the concept of "write only" memory is NOT a silly idea, as those of
> us who write device drivers for a living can attest to.

Yes, you're correct, and the above implements your concept. In fact, it
is certainly easier to use than manually keeping the bank select and set
operations together.

--
Chelly Green | mailto:chelly@eden.com | http://www.eden.com/~chelly


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John David Galt wrote:

> I also have one thing I would add to the language, and that is some
> mechanism for the programmer to promise no pointer aliasing, so that
> loops like this can be optimized as well as they are in FORTRAN

You're in luck.  It is very likely that the next version of the
C standard will include a `restrict' keyword which is similar in
intent to `noalias' (though different in detail -- solving many
of the objections to `noalias' that kept `noalias' out of the first
C standard).  It is also quite likely that this will migrate from C
compilers to C++ compilers and to eventually be incorporated in the
second C++ standard.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Scott A Johnson wrote:
>
> Whatever happened to writeonly?????

I assume it was considered for addition into the language, but found not
to
be useful enough to add.

> In Bjarne's book, _The Design and Evolution of C++_, he mentions that there
> was a proposal for readonly and writeonly type modifiers.  A readonly type
> was one that could not be assigned to, a writeonly type was one that could
> ONLY be assigned to.
>
> The readonly type is, of course, in C++ (and in C).  We call it "const".
> But what happened to writeonly?????  Having writeonly in the language
> would be VERY useful to writers of device drivers.  As well as a few
> other things.

C++ is a general-purpose language. Adding specific features just for one
group
of programers ("device driver writers") is not in the interest of the
general
user. C++ is meant for high-level programming in general, while the
writeonly
would only be for low-level programming "on the metal". Even if you only
consider the feature's usefulness for direct hardware access, it isn't
*that*
useful. If you want a write-only register, why not use a simple class?

    template<class T>
    class WriteOnly {
        volatile T& val;
    public:
        WriteOnly( unsigned long addr ) :
            addr( *reinterpret_cast<volatile T&> (addr) { }
        void operator = ( T v ) { val = v; }
    };

To use:

    static WriteOnly<char> uart_s_reg( 0xE0000008 );

    void uart_interrupt() { uart_s_reg = 0; }

Hehe, I guess that gets to another reason: The user can implement that
feature themselves (without modifying the compiler). If you read the
above
book thoroughly (which you may have), I think you would be able to make
a
good guess as to why writeonly wasn't added. Maybe someone who actually
knows why writeonly wasn't added can comment.

> (While we are at it, we could add "readable" to the mix, which would serve
> the same purpose with writonly that mutable serves with const.)

Add something that will benefit device driver writers even less, not
even considering the general user community?

> The following shows how writeonly would interact with const and "normal"
> variables.

Have fun incorporating this into the overloading rules!

...


--
Chelly Green | mailto:chelly@eden.com | http://www.eden.com/~chelly


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <320BC045.4DAD@eden.com>, Chelly Green  <chelly@eden.com> wrote:
>Scott A Johnson wrote:
>>
>> Whatever happened to writeonly?????
>I assume it was considered for addition into the language, but found not
>to be useful enough to add.
>
>> In Bjarne's book, _The Design and Evolution of C++_, he mentions that there
>> was a proposal for readonly and writeonly type modifiers.  A readonly type
>> was one that could not be assigned to, a writeonly type was one that could
>> ONLY be assigned to.
>>
>> The readonly type is, of course, in C++ (and in C).  We call it "const".
>> But what happened to writeonly?????  Having writeonly in the language
>> would be VERY useful to writers of device drivers.  As well as a few
>> other things.
>
>C++ is a general-purpose language. Adding specific features just for one
>group of programers ("device driver writers") is not in the interest of
>the general user. C++ is meant for high-level programming in general,
>while the writeonly would only be for low-level programming "on the
>metal". Even if you only consider the feature's usefulness for direct
>hardware access, it isn't *that* useful. If you want a write-only
>register, why not use a simple class?

[example deleted]

If it were only for device driver writers, I would agree with you 100%.
But it might be useful for other things, as well.  From a strictly
theoretical viewpoint, being able to declare a parameter writeonly would
further augment the interface specification capabilities of the language.
(Not by much, admittedly.)  The compiler might well in certain
circumstances be able to optimize based on it.

If a parameter to a function is guaranteed not to be modified by the
function, that can be expressed with const.  There is no way currently to
express in a function declaration the case in which a parameter is used
for output only (and thus the function has no dependence on the value
"passed in".)

>Hehe, I guess that gets to another reason: The user can implement that
>feature themselves (without modifying the compiler). If you read the
>above book thoroughly (which you may have), I think you would be able to
>make a good guess as to why writeonly wasn't added. Maybe someone who
>actually knows why writeonly wasn't added can comment.

The book never says directly.  No argument against writeonly is given, at
least not that I found.   Of course, lots of useful (and trivial to
implement) features that aren't part of the language are discussed.

>> (While we are at it, we could add "readable" to the mix, which would serve
>> the same purpose with writonly that mutable serves with const.)
>Add something that will benefit device driver writers even less, not
>even considering the general user community?

That suggestion was 1) for orthogonality, and 2) because writeonly AIN'T
just for device driver writers.  Just as mutable gives virtual constness,
readable could give virtual writeonlyness...or something like that.
readable may well be not needed.

>> The following shows how writeonly would interact with const and "normal"
>> variables.
>Have fun incorporating this into the overloading rules!

Seems to me that it would be incorporated in a fashion similar to how
const is incorporated.  Of course, I must plead ignorance of C++ compiler
internals........


Scott


--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Scott Johnson wrote:
>
> In article <320BC045.4DAD@eden.com>, Chelly Green  <chelly@eden.com> wrote:
> >Scott A Johnson wrote:
> >>
> >> Whatever happened to writeonly?????
> >
> >I assume it was considered for addition into the language, but found not
> >to be useful enough to add.
> >
> >> In Bjarne's book, _The Design and Evolution of C++_, he mentions that there
> >> was a proposal for readonly and writeonly type modifiers.  A readonly type
> >> was one that could not be assigned to, a writeonly type was one that could
> >> ONLY be assigned to.
> >>
> >> The readonly type is, of course, in C++ (and in C).  We call it "const".
> >> But what happened to writeonly?????  Having writeonly in the language
> >> would be VERY useful to writers of device drivers.  As well as a few
> >> other things.
> >
> >C++ is a general-purpose language. Adding specific features just for one
> >group of programers ("device driver writers") is not in the interest of
> >the general user. C++ is meant for high-level programming in general,
> >while the writeonly would only be for low-level programming "on the
> >metal". Even if you only consider the feature's usefulness for direct
> >hardware access, it isn't *that* useful. If you want a write-only
> >register, why not use a simple class?
>
> [example deleted]
>
> If it were only for device driver writers, I would agree with you 100%.
> But it might be useful for other things, as well.  From a strictly
> theoretical viewpoint, being able to declare a parameter writeonly would
> further augment the interface specification capabilities of the language.

True, and the compiler could issue better warnings (see below).

> (Not by much, admittedly.)  The compiler might well in certain
> circumstances be able to optimize based on it.

Hmmm, I can't think of any places where it could optimize. OK, well, if
a particular architecture's cache could operate more efficiently if
it was told that a cache line would never be re-read after written, then
the compiler could take advantage of this  :-)

> If a parameter to a function is guaranteed not to be modified by the
> function, that can be expressed with const.  There is no way currently to
> express in a function declaration the case in which a parameter is used
> for output only (and thus the function has no dependence on the value
> "passed in".)

Yes, good point. Often (well, OK, rarely :-) you pass a reference to
multiple parameters you want set, but whose initial value is uninitialized.
A compiler would then be able to warn that a non-writeonly reference to an
uninitialized value was passed to a function.

I wonder if a reference-type class could constructed that referenced a
value and could only write it. Having an actual writeonly value would
be pretty useless :-)

    writeonly int i = 10;
    i = 20;
    i = 30;
    // joy!

OK, let's see if a class as described will work:

    template<class T>
    class writeonly_ref {
        T& v;
        void operator = ( writeonly& ); // references can't be re-bound
    public:
        writeonly( T& t ) : v( t ) { }
        writeonly& operator = ( T t ) { v = t; return *this; }
    };

Usage:

    void f( writeonly_ref<int> x, writeonly_ref<int> y )
    {
        x = 10;
        y = 20;
    }

    void user()
    {
        int i, j, k;
        f( i, j );
    }

...
> The book never says directly.  No argument against writeonly is given, at
> least not that I found.   Of course, lots of useful (and trivial to
> implement) features that aren't part of the language are discussed.

Just re-read that section, and I see what you mean, Bjarne just goes on
about readonly being named const, but no more mention of writeonly.
Maybe he could comment directly? Wonder if he's watching  :-)

> >> (While we are at it, we could add "readable" to the mix, which would serve
> >> the same purpose with writonly that mutable serves with const.)
> >
> >Add something that will benefit device driver writers even less, not
> >even considering the general user community?
>
> That suggestion was 1) for orthogonality, and 2) because writeonly AIN'T
> just for device driver writers.  Just as mutable gives virtual constness,
> readable could give virtual writeonlyness...or something like that.
> readable may well be not needed.
...
> /--------------------------------------------------------------------------\
> |Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
> |I don't speak for nobody but myself, which everyone else is thankful for  |
> \--------------------------------------------------------------------------/

Uhhh, yeah... I guess I see, if it's a reference to a writeonly struct,
some members would still be readable. Now what are some other uses of
writeonly that would actually justify this much stiff?!?

It is an interesting idea, since it gives us a mirror-image of const, but
I'm not sure it gives us a mirror-image of the usefulness of const (hey,
mirror-images don't have to be consistent!).
--
Chelly Green | mailto:chelly@eden.com | http://www.eden.com/~chelly


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>> The readonly type is, of course, in C++ (and in C).  We call it "const".
>> But what happened to writeonly?????  Having writeonly in the language
>> would be VERY useful to writers of device drivers.  As well as a few
>> other things.

The last time I saw this silly concept was in Intel's April Fools' Day ad for
a write-only memory chip.

Why is it a silly concept?  Imagine any computer that has write-only memory
installed.  If you were to pull out the WOM and throw it away, or replace it
with a chip made of wood, no one using the machine would ever see any
difference.

Wouldn't the same be true of a write-only C++ object?  If not, please explain.

John David Galt
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> The last time I saw this silly concept was in Intel's April Fools' Day ad
> for a write-only memory chip.
>
> Why is it a silly concept?  Imagine any computer that has write-only memory
> installed.  If you were to pull out the WOM and throw it away, or replace it
> with a chip made of wood, no one using the machine would ever see any
> difference.
>
Actually I dont think writeonly would be a silly consept. Globally writeonly
chip or C++ object would be bad ofcourse, but think about memory chip in
external device like a scsi card or vga-card. It'd be very convinient to have
the memory in the external device as writeonly for the processor and readonly
for the external device.

> Wouldn't the same be true of a write-only C++ object?

Yes, it would, and that means, it might be convinient to have one too in C++.

But I wouldnt go adding a new keyword for writeonly because you can do
exactly the same thing with C++ classes already.

--
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Whatever happened to writeonly?????

In Bjarne's book, _The Design and Evolution of C++_, he mentions that there
was a proposal for readonly and writeonly type modifiers.  A readonly type
was one that could not be assigned to, a writeonly type was one that could
ONLY be assigned to.

The readonly type is, of course, in C++ (and in C).  We call it "const".
But what happened to writeonly?????  Having writeonly in the language
would be VERY useful to writers of device drivers.  As well as a few
other things.

(While we are at it, we could add "readable" to the mix, which would serve
the same purpose with writonly that mutable serves with const.)


The following shows how writeonly would interact with const and "normal"
variables.

void foo( int *bar 1, writeonly int *bar2, const int *bar3 )
{
    int *baz1;
    writeonly int *baz2;
    const int *baz3;
    int grolsch;

    baz1 = bar1; // OK
    baz1 = bar2; // Not OK--violates writeonlyness of bar2
    baz1 = bar3; // Not OK--violates constness of bar3

    baz2 = bar1; // OK
    baz2 = bar2; // OK
    baz2 = bar3; // Definitely not OK--violates constness of bar3

    baz3 = bar1; // OK
    baz3 = bar2; // Not OK--violates writeonlyness of bar2
    baz3 - bar3; // OK

    grolsch = *bar1; // OK
    grolsch = *bar2; // Not OK, *bar2 is being used as rvalue
    grolsch = *bar3; // OK

    *bar1 = 5;  // OK
    *bar2 = 5;  // OK
    *bar3 = 5;  // Not OK, *bar3 is const

    *bari += 1;  // OK
    *bar2 += 1;  // Not OK
    *bar3 += 1;  // Not OK

}


Is there a good idea (besides the obvious one that it wasn't voted in)
that writeonly (or some similar keyword) ain't in the language???


Scott

--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]