In article <da9716$1knv$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <da88rb$ruj$1@digitaldaemon.com>, Walter says...
>>
>>Consider the following C++ function:
>>
>>    int foo(const int *p, int *q)
>>    {
>>        int i = *p;
>>        *q = 3;
>>        return *p;
>>    }
>>
>>At the return statement, could we replace *p with i, thereby saving ourselves a dereference operation? After all, p points to "const" data, right? Wrong. Consider calling foo() this way:
>>
>>    int a[3];
>>    ...
>>    foo(a, a);
>>
>>Since p and q now hold the same value, *q = 3; will change the contents of what p points to.
>>
>>This code is perfectly legal C++, and is "const-correct". It happens often enough in real code, too, as I discovered when trying to implement this optimization.
>
>Why do I suddenly feel like we're moving towards defining 'restrict' in D? :)
>
>
>Sean
>
>

Take a peek in the archives on that subject - I don't think you need to worry about that <g>

- Dave

"Walter" <newshound@digitalmars.com> wrote in message news:da99a9$1n0q$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da93ap$1g54$1@digitaldaemon.com...
>> Walter, it is enough for me to know that
>>
>> int foo(const int *p, int *q)
>>    {
>>        int i = *p;
>>        *q = 3;
>>
>>        .... 200 lines of code
>>
>>        return *p;
>>    }
>>
>> will not change *p. I am not asking for optimization here. Optimization happened before - when I wrote this fucntion declaration using const parameters.
>>
>> I understand that you focused on optimiziation as compiler and
> codegenerator
>> writer. This is perfectly good and thank you for that.
>
> The optimization issue is a symptom of the problem with const, not the
> problem itself. The inability to make *any* use of const for the compiler
> to
> learn something about the program is, to me anyway, indicative that the
> semantic value of const is not there.
>
> Optimizers work by being able to prove certain properties of code to be
> true. At a higher level, being able to prove certain things about a
> program
> is important for all kinds of code analysis tools, like verifiers, etc.
> Being able to prove something about a program is also useful for the
> programmer, as knowing something that must be true about a piece of code
> is
> the first step to debugging it.
>
> C++ const doesn't enable proving anything about the const reference. The
> optimizer can't prove the values won't change, and *neither can the
> programmer* rely on it. If I see a const reference in C++ code, I don't
> know
> if it really is constant or not. As a programmer looking at someone else's
> code, it offers no value.

True.
Except of the last statement:
"As a programmer looking at someone else's code, it offers no value."

When I am looking on:

char[] toStringz(const char[] s)

I can tell that:

1) function designed to do not change 's'
2) body of the function passed through compiler -
    it not contains stupid mistakes inside.

Currently I am looking on

char* toStringz(char[] s)

and trying to guess - what a hell it is doing with my 's'?
And finally I can see there memcpy from my friend - C runtime
which I know declared as memcpy(void* dst, const void* src, size_t sz)...

Could you please do the same?
Without it DbC is not full in D.

>
>> But const is a matter of language design and not about optimization. Well not exactly as if I will write both:
>>
>> int foo(const int *p, int *q)
>> int foo(int *p, int *q)
>>
>> then I will make an act of optimization on the design level.
>>
>> Again: from the point of optimization 'public', 'private' attributes are
>> almost worthless.
>> But despite of that they are in the language. const is the same - it is a
>> contract.
>> Any argument that you can *intentionally* break constness are true.
>> The same apply to visibility attributes.
>
> My point (with the example given) is you are NOT breaking const. The code
> is
> legal, supported and is const-correct. It's not like const_cast, which is
> known to be an escape from const, can be grepped for, and can be warned
> about. There is no commonly accepted C++ convention that says such code is
> bad form, undefined, etc.
>
> And yes, these things do appear in real, working, production code, as I found out when attempting to use const in the optimizer.
>
> The only way "const" can be constant in C++ is if you follow an informal
> convention for your own code that is not enforced by the compiler or the
> language or by any third party whose code you might wish to use. You
> cannot
> assume that const is constant..

Exactly! And this is huge.
If *you* will write:
int foo(const char[] s)

then I will trust you - Walter made as much as possible
to ensure that foo is not changing s. So I don't
need to waste my time digging inside *each* string function
in Phobos. Ben propose to use 'to' for that...
Is it better or what? Will you also implement
"if function name starts from 'to' then ..."?

Trying to optimize everything is good but close to
"Road to hell is paved by good wishes".

Andrew.

Stefan Zobel wrote:

>>And you could still peek and poke it by casting to char* and
>>changing the memory inside, but that's besides the point here.
> 
> void main ()
> {
> String mutableString = new String("immutable!");
> writefln(mutableString);
> char[] ref = mutableString.toString();
> ref[9] = '?';
> writefln(mutableString);
> }
> 
> No "peeking and poking" here, just a realistic use case. But I'm
> convinced you know that. So, presumably I simply didn't get your point?

I simply meant that even when you *do* have "const char[]" (or similar),
you can still (implicitly?) cast it to a pointer in D and change away...

Then again, introducing such a new thing would probably be accompanied
by "const char*" too, which any "const char[]" would return for .ptr ?

> Agreed, we wouldn't need a string class (could save on all that duping)
> if we had a way to declare const/immutable/... references in D. Just wanted
> to remark that String.d isn't immutable, nothing more. No offense intended :)

As pointed out by others, could take toString out - making it useless.

And this is not only "toString", but also toCodePoints and opSlice -
and probably most other similar member functions returing arrays... ?

They are all read-only and "protected" by the Copy-on-Write convention.

--anders

In article <daali1$5mn$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Stefan Zobel wrote:
>
>>>And you could still peek and poke it by casting to char* and changing the memory inside, but that's besides the point here.
>> 
>> void main ()
>> {
>> String mutableString = new String("immutable!");
>> writefln(mutableString);
>> char[] ref = mutableString.toString();
>> ref[9] = '?';
>> writefln(mutableString);
>> }
>> 
>> No "peeking and poking" here, just a realistic use case. But I'm convinced you know that. So, presumably I simply didn't get your point?
>
>I simply meant that even when you *do* have "const char[]" (or similar),
>you can still (implicitly?) cast it to a pointer in D and change away...
>
>Then again, introducing such a new thing would probably be accompanied by "const char*" too, which any "const char[]" would return for .ptr ?
>
>> Agreed, we wouldn't need a string class (could save on all that duping)
>> if we had a way to declare const/immutable/... references in D. Just wanted
>> to remark that String.d isn't immutable, nothing more. No offense intended :)
>
>As pointed out by others, could take toString out - making it useless.
>
>And this is not only "toString", but also toCodePoints and opSlice - and probably most other similar member functions returing arrays... ?
>
>They are all read-only and "protected" by the Copy-on-Write convention.
>
>--anders

Ok, point taken. It's a COW string intended to be used as such. Thanks for the clarification.

Best regards,
Stefan

Andrew Fedoniouk wrote:
> 
> OT: this 'to' in Russian is one letter and sometimes looks funny combined
> with camelCase.
> 

Emmmm... All speaking russian use english for variables/methods/classes as well as in comments. So this is no matter how such things are translated to native language, you will never find constructions ala

stroka kStroke();

:)

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da9sbs$29to$1@digitaldaemon.com...
> True.
> Except of the last statement:
> "As a programmer looking at someone else's code, it offers no value."
>
> When I am looking on:
>
> char[] toStringz(const char[] s)
>
> I can tell that:
>
> 1) function designed to do not change 's'
> 2) body of the function passed through compiler -
>     it not contains stupid mistakes inside.

I will argue that you cannot tell that - especially if you are looking for bugs. The language offers no guarantees about const, so when you're going bug hunting, const is not helpful.

> Currently I am looking on
>
> char* toStringz(char[] s)
>
> and trying to guess - what a hell it is doing with my 's'?

I understand it can be helpful there, but I don't think it is as helpful as you do. I think there's a better way here somewhere, if we can find it.

"Walter" <newshound@digitalmars.com> wrote in message news:dach1f$1u8t$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:da9sbs$29to$1@digitaldaemon.com...
>> True.
>> Except of the last statement:
>> "As a programmer looking at someone else's code, it offers no value."
>>
>> When I am looking on:
>>
>> char[] toStringz(const char[] s)
>>
>> I can tell that:
>>
>> 1) function designed to do not change 's'
>> 2) body of the function passed through compiler -
>>     it not contains stupid mistakes inside.
>
> I will argue that you cannot tell that - especially if you are looking for bugs. The language offers no guarantees about const, so when you're going bug hunting, const is not helpful.

const helps me to do not do bugs. To change what is not
designed to be changed. From the very beginning - at planning level.

Hunting is a different story. But again such simple (well, from external
look)
preventive method can narrow the bug field a lot.

DbC methods in D are good, but if code designer will not cover all
conditions
carefully then they at least meaningless if not worse...

>
>> Currently I am looking on
>>
>> char* toStringz(char[] s)
>>
>> and trying to guess - what a hell it is doing with my 's'?
>
> I understand it can be helpful there, but I don't think it is as helpful
> as
> you do. I think there's a better way here somewhere, if we can find it.
>

Yep, so far I can see three methods only. Hope somebody will add more.

First is straightforward reproduction of const in C++ with all bells and
whistles.
Second is already defined in "Round III. Brainstrom...."  (Explicit
contsness, variant I)
Third one I've already mentioned somewhere here and going to formalize today
also.

I like explicit contsness variants as more I would say D-ish (grammatically
pure) and easily implementable - read reliable.
But again it is my personal opinion only - means can be not perfect.

Andrew.

Well, now, I have a question.  What does this say:

char* toStringz(in char[] s)

As compared to:

char* toStringz(char[] s)

Or:

char* toStringz(inout char[] s)

Since the in is explicitly specified (even if it is implicit) you can easily tell that the argument is meant not to modify the data pointed to.  If it says inout, then you can assume it returns and modifies the string.

It may not mean that it CAN'T change s, but there's only so much you can get out of stupid programmers.  In some cases, it's just a simple matter of knowing what you're doing.

-[Unknown]


> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message
> news:da9sbs$29to$1@digitaldaemon.com...
> 
>>True.
>>Except of the last statement:
>>"As a programmer looking at someone else's code, it offers no value."
>>
>>When I am looking on:
>>
>>char[] toStringz(const char[] s)
>>
>>I can tell that:
>>
>>1) function designed to do not change 's'
>>2) body of the function passed through compiler -
>>    it not contains stupid mistakes inside.
> 
> 
> I will argue that you cannot tell that - especially if you are looking for
> bugs. The language offers no guarantees about const, so when you're going
> bug hunting, const is not helpful.
> 
> 
>>Currently I am looking on
>>
>>char* toStringz(char[] s)
>>
>>and trying to guess - what a hell it is doing with my 's'?
> 
> 
> I understand it can be helpful there, but I don't think it is as helpful as
> you do. I think there's a better way here somewhere, if we can find it.
> 
> 

"Stefan Zobel" <Stefan_member@pathlink.com> wrote in message news:da7jlk$dtk$1@digitaldaemon.com...
> In article <da7i52$cv9$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>
>>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:da7fo5$bje$1@digitaldaemon.com...
>>
>>"Java and C# don't have const"
>>
>>Umm...
>>
>>Java has 'final' keyword. You define an entity once and cannot change it
>>or
>>derive from it later. More specifically: a final class cannot be
>>subclassed,
>>a final method cannot be overridden and a final variable cannot change
>>from
>>its initialized value. Function parameters can also be declared as final.
>>
>>C# has 'readonly' keyword. It can be used in declaration of class fields
>>and
>>in declaration of function parameters.
>>C# has also const keyword which is pretty much D keyword except of
>>C#::const
>>is protecting also references. E.g. you cannot
>>say "hello"[0] = 'b';
>>
>>And more regarding strings in these systems:
>>
>>Java/.NET String "package" consist of
>>
>>1) String class (immutable) and
>>2) StringBuffer (mutable) class
>>
>>Literal strings there are instances of String class
>>which is immutable, sic!
>>
>>I would like to highlight this again:
>>
>>In modern programming systems string implementation is a bundle
>>of friendly value classes (immutable) and buffer (mutable) classes.
>>
>>D currently has only StringBuffer (sort of).
>>
>>Only char#[] and char[] *together* can be considered as "string in D" by C++, Java or C# programmers.
>>
>
> Hi Andrew,
>
> hhm, I agree with most of your points here.
>
> You once said in this discussion that it is impossible to
> implement something like Java String in D. Apart from
> D string literals (char[]), I fail to see why.
> Could you please explain?
>
> Kind regards,
> Stefan
>
> (Of course, I think, we all agree that unnecessary dup'ing is undesirable, but that doesn't render it "impossible").
>

(Sorry, missed your message initially)

Strictly speaking it is possible to define String in D with exact set of methods and behavior as Java string. Mea culpa - I was not exact in terms.

I mean it is almost impossible to use such String effectively.
System and OS functions demands char* which you cannot get
from String by its specification. Powerfull mechanism of slices is
also lost here.  Yes, as you mentioned, you can dup on each
opSlice call but this is not a practical option.

Again beg my pardon.

Andrew.