View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2005
Re: Writing C in D
Walter wrote:

> A C++ reference parameter gives no clue whether it is in, out, or inout. The
> situation is such that Microsoft went ahead and invented IDL (Interface
> Description Language), the sole point of which is to add that missing bit of
> information. IDL is irrelevant for D.

I prefer the "in/out" parameters. Reminds me of Ada or something...

> As has been debated here many times <g>, const as a type modifier in C++ is
> so semantically weak it is fairly useless. (Many disagree.) C and C++ are
> the only languages I've ever heard of that use const as a type modifier.
> Java and C# show no signs of adopting it. The C++ community has not
> convinced the larger programmer community that const as a type modifier has
> a place.

The only place for "const" seems to be protecting read-only attribute ?

> I'd argue that C++ is less complete, since it relies so heavilly on STL to
> do things that are built in to most languages. Doing a general purpose
> foreach with C++ is fiendishly difficult. It's for free in D.

I think I'll just let you fight that one out with Matthew ;-)
I never liked C++, so I went straight to Java. D changes that.

--anders
March 07, 2005
Re: Writing C in D
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message
news:d0h20f$1r88$1@digitaldaemon.com...
>
> "Anders F Björklund" <afb@algonet.se> wrote in message
news:d0gu9k$1n20$2@digitaldaemon.com...
> > Walter wrote:
> >> As a *language*, what does C++ have over D?
> >> Implicit function template instantiation. It's hard to find much else.
>
>     const

Discussed in great depth elsewhere!

>     references

See my response to Anders on that.

>     bool

I'm not seeing it, Matthew!

>     namespaces

I really see nothing in C++ namespaces that has anything over D modules.
Namespaces are a failed attempt to add module like semantics to C++, and I
say failed because several experts told me that exported templates were
needed in order to provide "coding hygiene", i.e. prevent the names in one
source file from stepping on those in another. I found that interesting
because that was exactly the problem that namespace was supposed to solve.

>     compile-time testing (none of that hideous runtime generic comparison
filth)

?? D has static asserts.

>     TMP

??

>     macro pre-processor

You can use the C preprocessor with D, if you want.

>     'using'

Replaced with 'alias'.

>     operators that look like operators

Sorry, but that's a bug in C++.

>     compilers that warn

Thrashed that one to death <g>.

>     proper cast operators,

I know there's a thread on that, but I haven't gotten to it yet.

> and the ability to fill the gaps in the spectrum with user defined types

?? D has full UDT support.

>     support for shims (implicit template instantiation coupled with
ability to manipulate names in global/specific
> namespaces)

Agreed.

>     lack of GC

Lack of GC is a feature? How? One can program D just like you can in C,
strictly using malloc/free. Nary a GC object. D does not require GC.

>     ability to produce extremely small applications (i.e. supports
extremely low coupling, and allows one to dispense
> with C/C++ Runtime Library)

Phobos is a part of D, just like the C/C++ runtime library is a part of
C/C++. In both languages, you can stub out what you don't want, or provide
some minimal alternative. Phobos is certainly not a VM that must be dragged
around for the trivialest apps.


>     etc. etc. etc.

? ? ?

> (For the record, I'm writing std.openrj right now, in 100% D, and enjoying
it for the most part. But it is *not* > unalloyed tra-la-la-ing in
wonderland ...)

I predict that once you write enough D code, you'll discover that C++ is the
incomplete language <g>. Try supporting UTF in the C++ version of openrj.
March 07, 2005
Re: Writing C in D
"Anders F Björklund" <afb@algonet.se> wrote in message
news:d0hu4o$2orp$1@digitaldaemon.com...
> The only place for "const" seems to be protecting read-only attribute ?

I like "const" as meaning it really is constant. Read-only is a side effect
of that. C++ const stuff may be read only, but it isn't constant. Other
threads, and other references to the same data can change it at any time,
which is why the C++ const is overrated.
March 07, 2005
Re: Writing C in D
>> simplified const handling (storage instead of type),
>
> As has been debated here many times <g>, const as a type modifier in C++ is
> so semantically weak it is fairly useless. (Many disagree.)

This is hugely disingenuous. _You_ don't think const has any use. But then _you_ don't use const. Maybe they're related?

I find const *enormously* useful, both for its intended uses and for the unforeseen tricks one can put it to. The
absence of such is the largest common failing in other languages that I use, including C, Java, .NET *and* D, and a
significant part of the reason why I don't tend to use those languages for serious development.

>C and C++ are
> the only languages I've ever heard of that use const as a type modifier.
> Java and C# show no signs of adopting it. The C++ community has not
> convinced the larger programmer community that const as a type modifier has
> a place.

How can you conclude that? One might just as well surmise that the implementation complexity is what deters these other
'communities'. After all, these other languages - Java, .NET, D - are all far more allied to specific vendors, and are
therefore far more likely to be swayed by what's good for the vendor rather than what's good for the programmer.

That you don't recognise/acknowledge this shows that either you're trying to hoodwink us, or that you've succeeded too
well in hoodwinking yourself.

> I'd argue that C++ is less complete, since it relies so heavilly on STL to
> do things that are built in to most languages. Doing a general purpose
> foreach with C++ is fiendishly difficult. It's for free in D.

As a general point, I must observe that you are far too prone these days to counter criticisms of D's feature X by
saying feature Y is great. This is just stupid.

Yes, D has many marvellous features. This is a big part of why I am excited about D, and why I've stuck with it these
last 2.5 years.

But D also has some serious flaws, omissions, and howling stinkers.

The absence of some/all of const in D is a flaw. Period! The only debate is where the some/all point is drawn. To
counter
by saying that Java and .NET haven't followed C++ is (i) not true, and (ii) disingenuous. IIRC, Java does use final on
members, so one of the *fabulous powers of const in C++* has been aped. That D has not followed this particular facet
is a manifest flaw, and cannot be explained away by 'the complexity of using/implementing const'. It's nothing more than
an extension of your personal uninformed (since you don't use const) prejudices.

So, Walter, I say stop telling us about the great things in D. We all know and love them. No other language I know of
can do slices, and the combination of slices, GC and auto is unparalleled. (FGI: Walter and I are doing an article on
this "Not Your Father's Resource Management" for DDJ just as soon as I get my fingers out of all the other pies and do
my half of it. The article shows how D is an optimal mix of C++'s and Java/.NET's resource management paradigms, and is
superior to them all.)

What's going to stop D prospering is not failure-to-recognise-its-many-significant-virtues, but
all-too-ready-recognition-of-its-many-significant-flaws.

Sheesh! If I went to a psychologist to get help in sorting out my many personality flaws, I wouldn't waste her time and
my money in long and fatuous discussions about my many admirable traits!!!
March 07, 2005
Re: Writing C in D
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message
news:d0idln$97o$1@digitaldaemon.com...
> >> simplified const handling (storage instead of type),
> > As has been debated here many times <g>, const as a type modifier in C++
is
> > so semantically weak it is fairly useless. (Many disagree.)
> This is hugely disingenuous. _You_ don't think const has any use.

Right - many disagree - and I was thinking specifically of you!

> But then _you_ don't use const. Maybe they're related?

I used to use const as a type modifier. I gave it up after becoming
disenchanted with it. I use const as a storage class all the time. (The two
uses are very different,  although they look the same in C++. I wish to
emphasize the difference, as sometimes in these threads they incorrectly get
referred to interchangeably.)

> That you don't recognise/acknowledge this shows that either you're trying
to hoodwink us, or that you've succeeded too
> well in hoodwinking yourself.

I understand that you made a convincing argument. I respectfully suggest,
however, that doesn't necessarilly mean I was convinced and am therefore
trying to argue things I secretly believe to be false.

I know exactly how to implement const as a type modifier. If I believed it
was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
C++ compilers under active development, and they know how to do it, too.
They've both poured incredible resources in developing C# and Java. I have
no idea exactly how the decision came about not to use const as a type
modifier (as distinct from const as a storage class), but you can bet your
last dollar that if they felt it had high value, it'd be implemented. This
is one reason why I don't think I am way out of step in my opinion on const
as a type modifier.

> > I'd argue that C++ is less complete, since it relies so heavilly on STL
to
> > do things that are built in to most languages. Doing a general purpose
> > foreach with C++ is fiendishly difficult. It's for free in D.
> As a general point, I must observe that you are far too prone these days
to counter criticisms of D's feature X by
> saying feature Y is great. This is just stupid.

The thread is about whether C++ and D are "complete" languages or not, and I
wrote that comment should in that context.

> The absence of some/all of const in D is a flaw. Period! The only debate
is where the some/all point is drawn. To
> counter
> by saying that Java and .NET haven't followed C++ is (i) not true, and
(ii) disingenuous. IIRC, Java does use final on
> members, so one of the *fabulous powers of const in C++* has been aped.
That D has not followed this particular facet
> is a manifest flaw, and cannot be explained away by 'the complexity of
using/implementing const'.

Java's 'final' is a storage class, not a type modifier. Its use on a field
does not require the constructor to have an initializer for it. In fact, it
is illegal to set 'final' fields inside a constructor. The initializer for
the 'final' field must appear immediately after the declaration of the
field, outside of any constructor. Therefore, constructor parameters cannot
influence the setting of 'final' fields. Also, if one has multiple
constructors in Java, and one 'forgets' to initialize one of the fields, no
diagnostic is issued. The field gets default initialized. I'd argue it is a
fairly different beast in Java than in C++, since it is not aping the C++
feature of getting diagnostics from the constructor about uninitialized
const fields.

What Java's 'final' does share with C++ const fields is that the compiler
will diagnose attempts to modify the field after it is set. Java did it
right, though, as Java doesn't allow casting away of constness, or non-const
references to the same field modifying it out from under you. 'final' fields
in Java are solid enough that the compiler can optimize based on it, and
they have meaning in multithreaded apps, which is not the case in C++.

I have no issue with const and final as a storage class, I believe they are
valuable and useful, and const is implemented as a storage class in D (its
use could probably be profitably extended to more contexts). I don't agree
with its value as a type modifier, for oft stated reasons that I will
summarize as being that in legal, standard conforming C++ code the value of
the presumably 'const' data can change at any moment. Const things ought to
be, dagnamit, constant.
March 07, 2005
Re: Writing C in D (OT)
Amen. 

It's exactly this kind of thing that has so often worn me down to the bone [and
why my sometimes inappropriate commentary joins the party; for which I do
apologize] 

I believe we should understand that D belongs to all of us. Everyone who has
contributed in one form or another (through adopted ideas, through NG posts,
through being a D evangelist, through writing supporting libraries, through
examples, tutorials, and wiki's, through providing supporting web-services such
as dsource.org and this NG, etc. etc.) *own* a piece of D. I don't think Walter
could, or would, claim that D is his own thing at this time (in fact, our
combined little bits of ownership probably amount to something rather
significant). 

As such, we kinda' owe it to ourselves to ensure the development of "our"
language is 'managed' more effectively. After all, D requires a grass-roots
approach to language adoption (in contrast to the marketing and financial clout
of a .NET approach); it's people like us who will ultimately push for adoption
of D within our own spheres of influence.


I'm noting this for three reasons: 

1) you should realize that D is /your/ language ~ not someone else's. It will
become mainstream not when D matures per se, but when each and all of us urge
our development groups to consider adopting it. Walter has never spelt this out,
but he's fully dependent upon each of us for the success of D (unless it's
perhaps just a jolly wheeze instead). 

When I see people talking about "Walter's language" it suggests either "Walter
is a shallow and hollow individual" or "I can't personally accept the
responsibility for making this better". There's probably plenty of room between,
but you get the drift? We, each of us, is expected to do the hard work of local
adoption. So we should get used to the ownership idea.

2) we deserve, and should expect more in terms of a transparent development
process. Right now, it's almost completely opaque (save for the rare and
occasional glimmer of a proactive request, such as the recent "$ or length?"
topic initiated by Walter himself). I mean, at this point, a rational and
constructive discourse over how to improve D in specific areas is the exception,
rather than the norm. Instead, what's attached below typifies the reaction. This
is surely a bad sign, and it is something that (IMO) Walter should reflect
heavily upon. 

3) Historically, there's been a lot of talk with very little action. For
example, people have often lamented over the weaknesses of the D libraries.
However, how many of you are willing to do something about changing that? We've
got to take some responsibility ourselves to change things; be a bit more
constructive and a lot more cooperative. Talk is cheap. There are perhaps one or
two dozen people who are /really/ trying to contribute to D in this particular
manner ... they can always use a bit of help! If you want good libraries for D,
write them yourselves, or better, get some momentum going with others via the
Ares project (over at dsource).

Something to think about.

- Kris


(p.s. please forgive me for hijacking your post, Matthew; but for a moment there
you sounded just like me)



In article <d0idln$97o$1@digitaldaemon.com>, Matthew says...
>
>>> simplified const handling (storage instead of type),
>>
>> As has been debated here many times <g>, const as a type modifier in C++ is
>> so semantically weak it is fairly useless. (Many disagree.)
>
>This is hugely disingenuous. _You_ don't think const has any use. But then _you_ don't use const. Maybe they're related?
>
>I find const *enormously* useful, both for its intended uses and for the unforeseen tricks one can put it to. The
>absence of such is the largest common failing in other languages that I use, including C, Java, .NET *and* D, and a
>significant part of the reason why I don't tend to use those languages for serious development.
>
>>C and C++ are
>> the only languages I've ever heard of that use const as a type modifier.
>> Java and C# show no signs of adopting it. The C++ community has not
>> convinced the larger programmer community that const as a type modifier has
>> a place.
>
>How can you conclude that? One might just as well surmise that the implementation complexity is what deters these other
>'communities'. After all, these other languages - Java, .NET, D - are all far more allied to specific vendors, and are
>therefore far more likely to be swayed by what's good for the vendor rather than what's good for the programmer.
>
>That you don't recognise/acknowledge this shows that either you're trying to hoodwink us, or that you've succeeded too
>well in hoodwinking yourself.
>
>> I'd argue that C++ is less complete, since it relies so heavilly on STL to
>> do things that are built in to most languages. Doing a general purpose
>> foreach with C++ is fiendishly difficult. It's for free in D.
>
>As a general point, I must observe that you are far too prone these days to counter criticisms of D's feature X by
>saying feature Y is great. This is just stupid.
>
>Yes, D has many marvellous features. This is a big part of why I am excited about D, and why I've stuck with it these
>last 2.5 years.
>
>But D also has some serious flaws, omissions, and howling stinkers.
>
>The absence of some/all of const in D is a flaw. Period! The only debate is where the some/all point is drawn. To
>counter
>by saying that Java and .NET haven't followed C++ is (i) not true, and (ii) disingenuous. IIRC, Java does use final on
>members, so one of the *fabulous powers of const in C++* has been aped. That D has not followed this particular facet
>is a manifest flaw, and cannot be explained away by 'the complexity of using/implementing const'. It's nothing more than
>an extension of your personal uninformed (since you don't use const) prejudices.
>
>So, Walter, I say stop telling us about the great things in D. We all know and love them. No other language I know of
>can do slices, and the combination of slices, GC and auto is unparalleled. (FGI: Walter and I are doing an article on
>this "Not Your Father's Resource Management" for DDJ just as soon as I get my fingers out of all the other pies and do
>my half of it. The article shows how D is an optimal mix of C++'s and Java/.NET's resource management paradigms, and is
>superior to them all.)
>
>What's going to stop D prospering is not failure-to-recognise-its-many-significant-virtues, but
>all-too-ready-recognition-of-its-many-significant-flaws.
>
>Sheesh! If I went to a psychologist to get help in sorting out my many personality flaws, I wouldn't waste her time and
>my money in long and fatuous discussions about my many admirable traits!!!
>
>
>
>
March 07, 2005
Re: Writing C in D
In article <d0iiqi$emd$1@digitaldaemon.com>, Walter says...
>
>
>"Matthew" <admin.hat@stlsoft.dot.org> wrote in message
>news:d0idln$97o$1@digitaldaemon.com...
>> >> simplified const handling (storage instead of type),
>> > As has been debated here many times <g>, const as a type modifier in C++
>is
>> > so semantically weak it is fairly useless. (Many disagree.)
>> This is hugely disingenuous. _You_ don't think const has any use.
>
>Right - many disagree - and I was thinking specifically of you!
>
>> But then _you_ don't use const. Maybe they're related?
>
>I used to use const as a type modifier. I gave it up after becoming
>disenchanted with it. I use const as a storage class all the time. (The two
>uses are very different,  although they look the same in C++. I wish to
>emphasize the difference, as sometimes in these threads they incorrectly get
>referred to interchangeably.)
>
>> That you don't recognise/acknowledge this shows that either you're trying
>to hoodwink us, or that you've succeeded too
>> well in hoodwinking yourself.
>
>I understand that you made a convincing argument. I respectfully suggest,
>however, that doesn't necessarilly mean I was convinced and am therefore
>trying to argue things I secretly believe to be false.
>
>I know exactly how to implement const as a type modifier. If I believed it
>was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
>C++ compilers under active development, and they know how to do it, too.
>They've both poured incredible resources in developing C# and Java. I have
>no idea exactly how the decision came about not to use const as a type
>modifier (as distinct from const as a storage class), but you can bet your
>last dollar that if they felt it had high value, it'd be implemented. This
>is one reason why I don't think I am way out of step in my opinion on const
>as a type modifier.
>
>> > I'd argue that C++ is less complete, since it relies so heavilly on STL
>to
>> > do things that are built in to most languages. Doing a general purpose
>> > foreach with C++ is fiendishly difficult. It's for free in D.
>> As a general point, I must observe that you are far too prone these days
>to counter criticisms of D's feature X by
>> saying feature Y is great. This is just stupid.
>
>The thread is about whether C++ and D are "complete" languages or not, and I
>wrote that comment should in that context.
>
>> The absence of some/all of const in D is a flaw. Period! The only debate
>is where the some/all point is drawn. To
>> counter
>> by saying that Java and .NET haven't followed C++ is (i) not true, and
>(ii) disingenuous. IIRC, Java does use final on
>> members, so one of the *fabulous powers of const in C++* has been aped.
>That D has not followed this particular facet
>> is a manifest flaw, and cannot be explained away by 'the complexity of
>using/implementing const'.
>
>Java's 'final' is a storage class, not a type modifier. Its use on a field
>does not require the constructor to have an initializer for it. In fact, it
>is illegal to set 'final' fields inside a constructor. The initializer for
>the 'final' field must appear immediately after the declaration of the
>field, outside of any constructor. Therefore, constructor parameters cannot
>influence the setting of 'final' fields. Also, if one has multiple
>constructors in Java, and one 'forgets' to initialize one of the fields, no
>diagnostic is issued. The field gets default initialized. I'd argue it is a
>fairly different beast in Java than in C++, since it is not aping the C++
>feature of getting diagnostics from the constructor about uninitialized
>const fields.
>
>What Java's 'final' does share with C++ const fields is that the compiler
>will diagnose attempts to modify the field after it is set. Java did it
>right, though, as Java doesn't allow casting away of constness, or non-const
>references to the same field modifying it out from under you. 'final' fields
>in Java are solid enough that the compiler can optimize based on it, and
>they have meaning in multithreaded apps, which is not the case in C++.
>
>I have no issue with const and final as a storage class, I believe they are
>valuable and useful, and const is implemented as a storage class in D (its
>use could probably be profitably extended to more contexts). I don't agree
>with its value as a type modifier, for oft stated reasons that I will
>summarize as being that in legal, standard conforming C++ code the value of
>the presumably 'const' data can change at any moment. Const things ought to
>be, dagnamit, constant.


Very glad to hear you opinion on this. I, for one, agree 100%. 

If you could provide a D mechanism for making scalar and vector data "appear" to
be fully constant (as in the storage class) to third-parties (think return
values), then we'd have the read-only enforcement so many of us are crying out
for. That could easily become a major advantage for D over other languages.

In addition, the utility of a true storage-constant attribute (one that is also
supported via call-by-reference ~ inout obviously does not work) then that would
open up additional avenues for D.
March 07, 2005
Re: Writing C in D
On Mon, 7 Mar 2005 13:44:43 -0800, Walter wrote:

> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message
> news:d0idln$97o$1@digitaldaemon.com...
>>>> simplified const handling (storage instead of type),
>>> As has been debated here many times <g>, const as a type modifier in C++
> is
>>> so semantically weak it is fairly useless. (Many disagree.)
>> This is hugely disingenuous. _You_ don't think const has any use.
> 
> Right - many disagree - and I was thinking specifically of you!
> 
>> But then _you_ don't use const. Maybe they're related?
> 
> I used to use const as a type modifier. I gave it up after becoming
> disenchanted with it. I use const as a storage class all the time. (The two
> uses are very different,  although they look the same in C++. I wish to
> emphasize the difference, as sometimes in these threads they incorrectly get
> referred to interchangeably.)
> 
>> That you don't recognise/acknowledge this shows that either you're trying
> to hoodwink us, or that you've succeeded too
>> well in hoodwinking yourself.
> 
> I understand that you made a convincing argument. I respectfully suggest,
> however, that doesn't necessarilly mean I was convinced and am therefore
> trying to argue things I secretly believe to be false.
> 
> I know exactly how to implement const as a type modifier. If I believed it
> was the right thing to do, I'd do it. Microsoft and Sun both have inhouse
> C++ compilers under active development, and they know how to do it, too.
> They've both poured incredible resources in developing C# and Java. I have
> no idea exactly how the decision came about not to use const as a type
> modifier (as distinct from const as a storage class), but you can bet your
> last dollar that if they felt it had high value, it'd be implemented. This
> is one reason why I don't think I am way out of step in my opinion on const
> as a type modifier.
> 
>>> I'd argue that C++ is less complete, since it relies so heavilly on STL
> to
>>> do things that are built in to most languages. Doing a general purpose
>>> foreach with C++ is fiendishly difficult. It's for free in D.
>> As a general point, I must observe that you are far too prone these days
> to counter criticisms of D's feature X by
>> saying feature Y is great. This is just stupid.
> 
> The thread is about whether C++ and D are "complete" languages or not, and I
> wrote that comment should in that context.
> 
>> The absence of some/all of const in D is a flaw. Period! The only debate
> is where the some/all point is drawn. To
>> counter
>> by saying that Java and .NET haven't followed C++ is (i) not true, and
> (ii) disingenuous. IIRC, Java does use final on
>> members, so one of the *fabulous powers of const in C++* has been aped.
> That D has not followed this particular facet
>> is a manifest flaw, and cannot be explained away by 'the complexity of
> using/implementing const'.
> 
> Java's 'final' is a storage class, not a type modifier. Its use on a field
> does not require the constructor to have an initializer for it. In fact, it
> is illegal to set 'final' fields inside a constructor. The initializer for
> the 'final' field must appear immediately after the declaration of the
> field, outside of any constructor. Therefore, constructor parameters cannot
> influence the setting of 'final' fields. Also, if one has multiple
> constructors in Java, and one 'forgets' to initialize one of the fields, no
> diagnostic is issued. The field gets default initialized. I'd argue it is a
> fairly different beast in Java than in C++, since it is not aping the C++
> feature of getting diagnostics from the constructor about uninitialized
> const fields.
> 
> What Java's 'final' does share with C++ const fields is that the compiler
> will diagnose attempts to modify the field after it is set. Java did it
> right, though, as Java doesn't allow casting away of constness, or non-const
> references to the same field modifying it out from under you. 'final' fields
> in Java are solid enough that the compiler can optimize based on it, and
> they have meaning in multithreaded apps, which is not the case in C++.
> 
> I have no issue with const and final as a storage class, I believe they are
> valuable and useful, and const is implemented as a storage class in D (its
> use could probably be profitably extended to more contexts). I don't agree
> with its value as a type modifier, for oft stated reasons that I will
> summarize as being that in legal, standard conforming C++ code the value of
> the presumably 'const' data can change at any moment. Const things ought to
> be, dagnamit, constant.

I'm getting too confused with all this 'storage class' and 'type modifier'
talk. Sorry but I'm not a C++ nor a Java coder, so these terms are a bit
cloudy. This is what I can understand so far from these discussions ...

const "storage class":
The data is defined at compile time and RAM is reserved for the
information. No part of the application is allowed to modify the data
during run time.

const "type modifer":
The data is stored by one part of the application but is not allowed to be
modified by another part of the application.

I can see a really good use for what I've called 'type modifier'. Passing
something by reference to a routine, but not allowing that routine to
modify the data passed to it. Currently, the only obvious way to do that in
D is to pass a copy of the data and throw it away once the routine has
returned.

 void Bar(char[] x)
 {
    x[4] = 'b';
 }

 void Foo(char[] X)
 {
    X[0] = 'a';
    Bar(x);
 }

 . . .
 char[] Y = "derek";
 Foo(Y.dup);  // Ignore any changes that 'Foo' might make to Y.


But a nicer, more obvious, more explicit in declaring coding intentions,
would be do something like ...

 void Foo(PRESERVE char[] X)
 {
    X[0] = 'a';  // Compiler would flag this as an error.
    Bar(x);  // Compiler might have to pass a copy of x.
 }

 . . .
 char[] Y = "derek";
 Foo(Y); 

I don't know how to implement this efficiently, but that is not the issue.
The issue is that as a coder/designer, I must have the data in the passed
argument to by unchanged after calling the routine.

-- 
Derek
Melbourne, Australia
8/03/2005 9:59:25 AM
March 07, 2005
Re: Writing C in D
> const "storage class":
>  The data is defined at compile time and RAM is reserved for the
> information. No part of the application is allowed to modify the data
> during run time.
> 

From an embedded systems point of view, const data can also live in ROM 
(well, it should be able to) - many small systems do use this trick to 
save RAM usage.  ROM also physically prevents you from modifying the 
variable, as such you shouldn't try to do dirty tricks to modify a const 
variable.  I bring this up because I do embedded stuff for a living, and 
I don't see anything in D which precludes it from being used in small 
systems.

Brad
March 07, 2005
Re: Writing C in D
"Kris" <Kris_member@pathlink.com> wrote in message
news:d0ilcf$hbt$1@digitaldaemon.com...
> In article <d0iiqi$emd$1@digitaldaemon.com>, Walter says...
> >What Java's 'final' does share with C++ const fields is that the compiler
> >will diagnose attempts to modify the field after it is set. Java did it
> >right, though, as Java doesn't allow casting away of constness, or
non-const
> >references to the same field modifying it out from under you. 'final'
fields
> >in Java are solid enough that the compiler can optimize based on it, and
> >they have meaning in multithreaded apps, which is not the case in C++.
> >
> >I have no issue with const and final as a storage class, I believe they
are
> >valuable and useful, and const is implemented as a storage class in D
(its
> >use could probably be profitably extended to more contexts). I don't
agree
> >with its value as a type modifier, for oft stated reasons that I will
> >summarize as being that in legal, standard conforming C++ code the value
of
> >the presumably 'const' data can change at any moment. Const things ought
to
> >be, dagnamit, constant.
>
>
> Very glad to hear you opinion on this. I, for one, agree 100%.

Good. To put it another way, anything labeled as 'const' could be burned
into ROM without changing the meaning of the program. (This is also implies
that const data must have initializers that can be evaluated at compile
time.)

> If you could provide a D mechanism for making scalar and vector data
"appear" to
> be fully constant (as in the storage class) to third-parties (think return
> values), then we'd have the read-only enforcement so many of us are crying
out
> for. That could easily become a major advantage for D over other
languages.
>
> In addition, the utility of a true storage-constant attribute (one that is
also
> supported via call-by-reference ~ inout obviously does not work) then that
would
> open up additional avenues for D.

Fundamentally connected with this is the problem of aliased function
parameters. Get it wrong, as C and C++ do, and you cannot build an optimizer
that is competitive with FORTRAN optimizers.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home