"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ao0mr5$124s$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:anh2vv$9jb$1@digitaldaemon.com...
> >
> > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > > Consider passing a value as "inout" parameter to a function.
> > > Then both the caller and the called functions continue to use the same
> > > value, by multithreading.
> > > Now when will the changes of the inout parameter be incorporated into
> the
> > > original variable?
> > > Immediately, or when the called function returns?
> >
> > When the called function sets it to a value. I'm not sure why it
matters.
> >
> > > The specification does not tell. (Walter: please put it in)
> > > The "inout" name suggests the later, but the first happens (i hope).
> > > Therefore the name "inout" is not really intuitive. I would rather
> suggest
> > > "ref", because what is happening is passing a parameter by reference.
> >
> > True, but I like the consistency with "in" and "out" parameters.
>
>
> Lets consider you are passing a 1000 byte structure to a function. You
don't
> wan't to change it, but you don't wan't to make a copy of it either,
because
> that is slow. Passing by pointer is complex, and unnecessary. You specify "inout" to enable pass by reference. But conceptually this is not an
"inout"
> parameter 'cause it is never changed. It is a constant reference, as in
C++.
> You still have to use the keyword "inout" ruining the whole concept of
*self
> documentation*.

I agree, but you mean reference to a constant,
a constant reference would be a reference that can not be changed to refer
toanything else (like a C++ reference, some languages allow references to be
"re-referenced")
I find it odd that D does not support "read only" parameters as many
compilers use this to perform optimisations
such as register cacheing of structure values in non leaf functions in
callee save registers.

>
> struct large {
>   int f[1000];
> }
>
> void fn(inout large a, int i)
> {
>   printf("%d", a.f[i]);  // "a" is never changed
> }
>
> Sandor
>
>

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:ao10nf$1cqf$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ao0mr5$124s$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:anh2vv$9jb$1@digitaldaemon.com...
> > >
> > > "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:angu34$4ba$1@digitaldaemon.com...
> > > > Consider passing a value as "inout" parameter to a function. Then both the caller and the called functions continue to use the
same
> > > > value, by multithreading.
> > > > Now when will the changes of the inout parameter be incorporated
into
> > the
> > > > original variable?
> > > > Immediately, or when the called function returns?
> > >
> > > When the called function sets it to a value. I'm not sure why it
> matters.
> > >
> > > > The specification does not tell. (Walter: please put it in)
> > > > The "inout" name suggests the later, but the first happens (i hope).
> > > > Therefore the name "inout" is not really intuitive. I would rather
> > suggest
> > > > "ref", because what is happening is passing a parameter by
reference.
> > >
> > > True, but I like the consistency with "in" and "out" parameters.
> >
> >
> > Lets consider you are passing a 1000 byte structure to a function. You
> don't
> > wan't to change it, but you don't wan't to make a copy of it either,
> because
> > that is slow. Passing by pointer is complex, and unnecessary. You
specify
> > "inout" to enable pass by reference. But conceptually this is not an
> "inout"
> > parameter 'cause it is never changed. It is a constant reference, as in
> C++.
> > You still have to use the keyword "inout" ruining the whole concept of
> *self
> > documentation*.
>
> I agree, but you mean reference to a constant,

Hmm. It was C++ terminology. A reference to a constant would mean creating a reference to an otherwise constant object.

> a constant reference would be a reference that can not be changed to refer toanything else (like a C++ reference, some languages allow references to
be
> "re-referenced")

In D some references can be rereferenced (references to Object), and some references cannot be rereferenced: (inout parameters). If you pass an Object as inout, it is a two level reference, of which only the second level can be rereferenced.

> I find it odd that D does not support "read only" parameters as many
> compilers use this to perform optimisations
> such as register cacheing of structure values in non leaf functions in
> callee save registers.

IMHO, for most programmers, "read only" parameters and objects are not performace issues, but they increase the expressive power, and foolproofness of the language. And yes, I think they would be usefull in D. I can recall Walter telling he don't like them, but I don't remember why. But the thing I wanted to point out in the first place, was not "create read only parameters", but that the "inout" keyword is not properly named.

> >
> > struct large {
> >   int f[1000];
> > }
> >
> > void fn(inout large a, int i)
> > {
> >   printf("%d", a.f[i]);  // "a" is never changed
> > }
> >
> > Sandor
> >
> >
>
>

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ao34k0$fqs$1@digitaldaemon.com...
> IMHO, for most programmers, "read only" parameters and objects are not performace issues, but they increase the expressive power, and
foolproofness
> of the language. And yes, I think they would be usefull in D. I can recall Walter telling he don't like them, but I don't remember why.

The C++ notion of a const reference parameter:

1) adds a lot of clutter to function prototypes
2) is useless for optimization, since you can still change it
3) adds a lot of complexity to the overload rules and typing system
4) in my experience, it has never found a bug for me

In other words, it's benefit/cost ratio is too small.

"Walter" <walter@digitalmars.com> wrote in message news:aooksv$1ftm$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ao34k0$fqs$1@digitaldaemon.com...
> > IMHO, for most programmers, "read only" parameters and objects are not performace issues, but they increase the expressive power, and
> foolproofness
> > of the language. And yes, I think they would be usefull in D. I can
recall
> > Walter telling he don't like them, but I don't remember why.

>
> The C++ notion of a const reference parameter:
>
> 1) adds a lot of clutter to function prototypes
> 2) is useless for optimization, since you can still change it
it is a common complaint about gcc -O3 which assumes when you say const you mean const and are not going to cast within your function and abuse the item.

> 3) adds a lot of complexity to the overload rules and typing system
and does not go far enought,  for simple pointers to simple items, its fine,
const item * i; I can't change item
item * const i; I can change item but not the pointer.
const item * const i; I can't change either
but if 'item' contained a pointer to another item, then I can change what
that points to.
currently been writing some graphical device code, and what to be able to
make sure that images
(struct with a pointer to the image data) are not written to, unless they
are 'offscreen' images rather than ROM'ed images.

> 4) in my experience, it has never found a bug for me
I have found it very useful, i.e.
void myFunc( Item * dest, const Item * src );
stop you trying to write to ROM locations when doing embedded dev.
but that's about it.

> In other words, it's benefit/cost ratio is too small.
agree, BUT
how would 'D' be ROM-able on resource limited platforms without being able
to put static data into read only memory ?
in C
static int stuff[] = { .... } // allocated RAM space puts copy in ROM
static const int stuff[] = { .... } // allocated ROM only.

I personally feel that immutablility is more often a runtime property of an item rather than a compile time property and IF D every has immutable items, then the contracts need to allow the programmer to define the range and depth of the effect.

Rather than const,final like types, I think meta-classes that allow the
programmer to define the way an Object can be used, so your parameter are
declared as meta-class types not the Object type
(the meta class would have revered inheritance rules, because it starts from
the unrestricted and becomes more restrictive, and obviously a less
restricted meta is passable as a more restrictive meta)

so you could define the object public interface contract with a syntax like
( public/private are part of the objects access control list and are not
relevent here, this just defines which if any of the objects members are
immuatble and how far reaching the effect)
meta MyObj : MyObjImpl
{
    const field1;   // field1, and any child fields or items referenced by
this field are immutable via this interface
    final field2; // field2 is immutable BUT items referenced by this field
are mutable
}

meta MyObjImmutable : MyObj
{
    const field2;    // final fields in sub-meta-class can be make MORE
restricted but never less
    default final;    // all non mentioned fields are immutable
}

int readObj( MyObjImmutable readme ) { ... }
void writePartObj( MyObj canmodifyme_partly ) {
    int i;
    i = readObj( canmodifyme_partly ); // allowed : meta-classes have
reverse polymorpic rules.
.....
}

MyObjImpl imp = new MyObjImpl();
writePartObj( imp ); // allowed meta classes have reverse polymorphic
semantics

the compiler could either perform compile time only checks or runtime checks
too
(in which case a meta is a pointer to obj + ptr to meta-info).
if you allow casts then you need the runtime checks too
with templating and sensible use, I do not see a need to allow casts on
meta-classes.

Mike.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:aop2g5$1taf$1@digitaldaemon.com...
> > The C++ notion of a const reference parameter:
> > 1) adds a lot of clutter to function prototypes
> > 2) is useless for optimization, since you can still change it
> it is a common complaint about gcc -O3 which assumes when you say const
you
> mean const and are not going to cast within your function and abuse the item.

There's another problem with const precluding optimizations - suppose one object is pointed to by both a regular and a const pointer (perfectly legal C++). The former changes the latter behind its back, so to speak.

> how would 'D' be ROM-able on resource limited platforms without being able
> to put static data into read only memory ?
> in C
> static int stuff[] = { .... } // allocated RAM space puts copy in ROM
> static const int stuff[] = { .... } // allocated ROM only.

That will work in D because const is a storage class.

> I personally feel that immutablility is more often a runtime property of
an
> item rather than a compile time property and IF D every has immutable
items,
> then the contracts need to allow the programmer to define the range and depth of the effect.
>
> Rather than const,final like types, I think meta-classes that allow the
> programmer to define the way an Object can be used, so your parameter are
> declared as meta-class types not the Object type
> (the meta class would have revered inheritance rules, because it starts
from
> the unrestricted and becomes more restrictive, and obviously a less restricted meta is passable as a more restrictive meta)
>
> so you could define the object public interface contract with a syntax
like
> ( public/private are part of the objects access control list and are not
> relevent here, this just defines which if any of the objects members are
> immuatble and how far reaching the effect)
> meta MyObj : MyObjImpl
> {
>     const field1;   // field1, and any child fields or items referenced by
> this field are immutable via this interface
>     final field2; // field2 is immutable BUT items referenced by this
field
> are mutable
> }
>
> meta MyObjImmutable : MyObj
> {
>     const field2;    // final fields in sub-meta-class can be make MORE
> restricted but never less
>     default final;    // all non mentioned fields are immutable
> }
>
> int readObj( MyObjImmutable readme ) { ... }
> void writePartObj( MyObj canmodifyme_partly ) {
>     int i;
>     i = readObj( canmodifyme_partly ); // allowed : meta-classes have
> reverse polymorpic rules.
> .....
> }
>
> MyObjImpl imp = new MyObjImpl();
> writePartObj( imp ); // allowed meta classes have reverse polymorphic
> semantics
>
> the compiler could either perform compile time only checks or runtime
checks
> too
> (in which case a meta is a pointer to obj + ptr to meta-info).
> if you allow casts then you need the runtime checks too
> with templating and sensible use, I do not see a need to allow casts on
> meta-classes.
>
> Mike.
>
>

If you have this situation you should use volatile on things you want changes to show up immediately on.  Then the change will take effect on all copies immediately, but everything else can use the old values.

If you think something might change, don't keep a const reference to it.

Just because something might break isn't a good enough reason not to do the optimization.  Just needs enough language warnings and good support for volatile too.

In many cases you use const when you don't expect something to change and/or don't care if it changes.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ap08fe$75h$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:aop2g5$1taf$1@digitaldaemon.com...
> > > The C++ notion of a const reference parameter:
> > > 1) adds a lot of clutter to function prototypes
> > > 2) is useless for optimization, since you can still change it
> > it is a common complaint about gcc -O3 which assumes when you say const
> you
> > mean const and are not going to cast within your function and abuse the item.
>
> There's another problem with const precluding optimizations - suppose one object is pointed to by both a regular and a const pointer (perfectly
legal
> C++). The former changes the latter behind its back, so to speak.
>
> > how would 'D' be ROM-able on resource limited platforms without being
able
> > to put static data into read only memory ?
> > in C
> > static int stuff[] = { .... } // allocated RAM space puts copy in ROM
> > static const int stuff[] = { .... } // allocated ROM only.
>
> That will work in D because const is a storage class.
>
> > I personally feel that immutablility is more often a runtime property of
> an
> > item rather than a compile time property and IF D every has immutable
> items,
> > then the contracts need to allow the programmer to define the range and depth of the effect.
> >
> > Rather than const,final like types, I think meta-classes that allow the programmer to define the way an Object can be used, so your parameter
are
> > declared as meta-class types not the Object type
> > (the meta class would have revered inheritance rules, because it starts
> from
> > the unrestricted and becomes more restrictive, and obviously a less restricted meta is passable as a more restrictive meta)
> >
> > so you could define the object public interface contract with a syntax
> like
> > ( public/private are part of the objects access control list and are not
> > relevent here, this just defines which if any of the objects members are
> > immuatble and how far reaching the effect)
> > meta MyObj : MyObjImpl
> > {
> >     const field1;   // field1, and any child fields or items referenced
by
> > this field are immutable via this interface
> >     final field2; // field2 is immutable BUT items referenced by this
> field
> > are mutable
> > }
> >
> > meta MyObjImmutable : MyObj
> > {
> >     const field2;    // final fields in sub-meta-class can be make MORE
> > restricted but never less
> >     default final;    // all non mentioned fields are immutable
> > }
> >
> > int readObj( MyObjImmutable readme ) { ... }
> > void writePartObj( MyObj canmodifyme_partly ) {
> >     int i;
> >     i = readObj( canmodifyme_partly ); // allowed : meta-classes have
> > reverse polymorpic rules.
> > .....
> > }
> >
> > MyObjImpl imp = new MyObjImpl();
> > writePartObj( imp ); // allowed meta classes have reverse polymorphic
> > semantics
> >
> > the compiler could either perform compile time only checks or runtime
> checks
> > too
> > (in which case a meta is a pointer to obj + ptr to meta-info).
> > if you allow casts then you need the runtime checks too
> > with templating and sensible use, I do not see a need to allow casts on
> > meta-classes.
> >
> > Mike.

>
> There's another problem with const precluding optimizations - suppose one object is pointed to by both a regular and a const pointer (perfectly
legal
> C++). The former changes the latter behind its back, so to speak.
>
as pointed out the const should have been a const volatile, you can't change it but someone else can.

I would still like to be able to mark a parameter as immutable, which I
guess in C would be const volatile
in that it does not say that the object/item can not be altered by another
thread or h/w, but that I can not modify it.
to gain the optimisability, you could add a "theadsafe" modifier, I agree
the default behaviour should err on the side of caution (all class methods
virtual etc) but it should be possible to get back the performance in most
cases.

as an aside, have you though about changing the build from a 2 stage
compile, link into a 3 stage build
so it is compile,gather,link, where the gather stage, pulls in all the
objects, and then with a full view of the final codebase can convert  some
calls to non-virtual and perform optimisations on immutable items etc, in a
similar fashion to Java/CLR dynamic compilers.

> > how would 'D' be ROM-able on resource limited platforms without being
able
> > to put static data into read only memory ?
> > in C
> > static int stuff[] = { .... } // allocated RAM space puts copy in ROM
> > static const int stuff[] = { .... } // allocated ROM only.
>
> That will work in D because const is a storage class.
>
My mistake, and I agree const is constant for all time.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap0mop$oka$1@digitaldaemon.com...
> If you have this situation you should use volatile on things you want changes to show up immediately on.  Then the change will take effect on
all
> copies immediately, but everything else can use the old values.

What do you mean by "all copies"? Copies do not change.

> If you think something might change, don't keep a const reference to it.

You do. Const reference means you (this module/function/object) are not authorized to change it. But it doesn't mean it can never be changed by anyone. So if a value can be changed I should give permission to everybody to change it?

> Just because something might break isn't a good enough reason not to do
the
> optimization.  Just needs enough language warnings and good support for volatile too.

I don't want to see a compiler warning me about having an object with both const and non-const references. I do that deliberately, as part of good design, using a valid language feature.

> In many cases you use const when you don't expect something to change
and/or
> don't care if it changes.

Can you show an example when you "use const when you don't care if it changes", please?

> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:ap08fe$75h$1@digitaldaemon.com...
> >
> > "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:aop2g5$1taf$1@digitaldaemon.com...
> > > > The C++ notion of a const reference parameter:
> > > > 1) adds a lot of clutter to function prototypes
> > > > 2) is useless for optimization, since you can still change it
> > > it is a common complaint about gcc -O3 which assumes when you say
const
> > you
> > > mean const and are not going to cast within your function and abuse
the
> > > item.
> >
> > There's another problem with const precluding optimizations - suppose
one
> > object is pointed to by both a regular and a const pointer (perfectly
> legal
> > C++). The former changes the latter behind its back, so to speak.
> >
> > > how would 'D' be ROM-able on resource limited platforms without being
> able
> > > to put static data into read only memory ?
> > > in C
> > > static int stuff[] = { .... } // allocated RAM space puts copy in ROM
> > > static const int stuff[] = { .... } // allocated ROM only.
> >
> > That will work in D because const is a storage class.
> >
> > > I personally feel that immutablility is more often a runtime property
of
> > an
> > > item rather than a compile time property and IF D every has immutable
> > items,
> > > then the contracts need to allow the programmer to define the range
and
> > > depth of the effect.
> > >
> > > Rather than const,final like types, I think meta-classes that allow
the
> > > programmer to define the way an Object can be used, so your parameter
> are
> > > declared as meta-class types not the Object type
> > > (the meta class would have revered inheritance rules, because it
starts
> > from
> > > the unrestricted and becomes more restrictive, and obviously a less restricted meta is passable as a more restrictive meta)
> > >
> > > so you could define the object public interface contract with a syntax
> > like
> > > ( public/private are part of the objects access control list and are
not
> > > relevent here, this just defines which if any of the objects members
are
> > > immuatble and how far reaching the effect)
> > > meta MyObj : MyObjImpl
> > > {
> > >     const field1;   // field1, and any child fields or items
referenced
> by
> > > this field are immutable via this interface
> > >     final field2; // field2 is immutable BUT items referenced by this
> > field
> > > are mutable
> > > }
> > >
> > > meta MyObjImmutable : MyObj
> > > {
> > >     const field2;    // final fields in sub-meta-class can be make
MORE
> > > restricted but never less
> > >     default final;    // all non mentioned fields are immutable
> > > }
> > >
> > > int readObj( MyObjImmutable readme ) { ... }
> > > void writePartObj( MyObj canmodifyme_partly ) {
> > >     int i;
> > >     i = readObj( canmodifyme_partly ); // allowed : meta-classes have
> > > reverse polymorpic rules.
> > > .....
> > > }
> > >
> > > MyObjImpl imp = new MyObjImpl();
> > > writePartObj( imp ); // allowed meta classes have reverse polymorphic
> > > semantics
> > >
> > > the compiler could either perform compile time only checks or runtime
> > checks
> > > too
> > > (in which case a meta is a pointer to obj + ptr to meta-info).
> > > if you allow casts then you need the runtime checks too
> > > with templating and sensible use, I do not see a need to allow casts
on
> > > meta-classes.
> > >
> > > Mike.
>
>
>

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ap2q48$30o2$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap0mop$oka$1@digitaldaemon.com...
> > If you have this situation you should use volatile on things you want changes to show up immediately on.  Then the change will take effect on
> all
> > copies immediately, but everything else can use the old values.
>
> What do you mean by "all copies"? Copies do not change.

I meant all volatile const items.  Oh well I probably made Walter hurl with this suggestion.

> > If you think something might change, don't keep a const reference to it.
>
> You do. Const reference means you (this module/function/object) are not authorized to change it. But it doesn't mean it can never be changed by anyone. So if a value can be changed I should give permission to everybody to change it?
>
> > Just because something might break isn't a good enough reason not to do
> the
> > optimization.  Just needs enough language warnings and good support for volatile too.
>
> I don't want to see a compiler warning me about having an object with both const and non-const references. I do that deliberately, as part of good design, using a valid language feature.

Right.

> > In many cases you use const when you don't expect something to change
> and/or
> > don't care if it changes.
>
> Can you show an example when you "use const when you don't care if it changes", please?

struct workstruct
{
    int a,b,c;
};

void dowork(const workstruct& mat, workstruct& result)
{
    // here I likely don't give a crap if some thread is busy updating mat.a
while I'm working
    result.a += mat.a;
    result.b += mat.a;
    result.c += mat.a;
}

If I did care, I'd use volatile like so:

void dothreadsafework(const volatile workstruct& mat, workstruct& result)
{
    // this will "work" even if some thread is updating mat.  If that's what
you want.
    result.a += mat.a;
    result.b += mat.a;
    result.c += mat.a;
}

Of course when you leave the function and come back, sure you'll probably want to refresh the view of the struct.

class worker
{
    const workstruct& mat;
    worker(const workstruct& amat) : mat(amat) {}
    void dowork(workstruct& result)
    {
        result.a += mat.a;
        result.b += mat.a;
        result.c += mat.a;
    }
}

The compiler has to make a few assumptions in order to generate good code (at very least cache things in registers).  I'm willing to give up a lot of knowledge about what's going on in other threads in order to get that speed. That's what volatile is for... for those times when you need the absolute latest values all the time.  95% of the time, you don't.  And I don't want my compiler dumping registers to the stack and reloading registers if it doesn't absolutely have to.

Sean

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap0mop$oka$1@digitaldaemon.com...
> If you have this situation you should use volatile on things you want changes to show up immediately on.  Then the change will take effect on
all
> copies immediately, but everything else can use the old values.
> If you think something might change, don't keep a const reference to it.
> Just because something might break isn't a good enough reason not to do
the
> optimization.  Just needs enough language warnings and good support for
> volatile too.
> In many cases you use const when you don't expect something to change
and/or
> don't care if it changes.

Unfortunately, I can't implement compiler optimizations that assume const means const, because it doesn't and too many programs break. This is one of the reasons why const is useless as a type modifier.