"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87fob$2dn0$1@digitaldaemon.com...
> Having said that and using "practices obvious in the code" motto I am thinking about have a question:
>
> Currently following:
>
> const char[] s = "Hello";
>     s[0] = 0;
>
> compiles just fine.

It shouldn't. I just haven't gotten around to dealing with that.

"Walter" <newshound@digitalmars.com> wrote in message news:d87hn9$2fmi$3@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87fob$2dn0$1@digitaldaemon.com...
>> Having said that and using "practices obvious in the code" motto I am thinking about have a question:
>>
>> Currently following:
>>
>> const char[] s = "Hello";
>>     s[0] = 0;
>>
>> compiles just fine.
>
> It shouldn't. I just haven't gotten around to dealing with that.
>
>

Thanks for clarification.

Having implemented this I guess following should be
impossible too:
      "Hello"[0] = 0;
(now it compiles, and more interestingly, works just fine)

If you will implement this then it will effectively mean that type of
string constant will be something like:
      const static char[N]

Which will require that:

      char[] s = "hello";

will allocate new char array, in other words will be equivalent to

      char[] s = "hello".dup;

Am I right?

Andrew.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87k31$2iaq$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d87hn9$2fmi$3@digitaldaemon.com...
> >
> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87fob$2dn0$1@digitaldaemon.com...
> >> Having said that and using "practices obvious in the code" motto I am thinking about have a question:
> >>
> >> Currently following:
> >>
> >> const char[] s = "Hello";
> >>     s[0] = 0;
> >>
> >> compiles just fine.
> >
> > It shouldn't. I just haven't gotten around to dealing with that.
> >
> >
>
> Thanks for clarification.
>
> Having implemented this I guess following should be
> impossible too:
>       "Hello"[0] = 0;
> (now it compiles, and more interestingly, works just fine)
>
> If you will implement this then it will effectively mean that type of
> string constant will be something like:
>       const static char[N]
>
> Which will require that:
>
>       char[] s = "hello";
>
> will allocate new char array, in other words will be equivalent to
>
>       char[] s = "hello".dup;
>
> Am I right?

No, what I plan to do is put string literals into a read-only section of memory. Attempting to change it will result in a runtime fault.

On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:zu8pxspfqpou$.j798zboqpqeo$.dlg@40tude.net...
>> WTF do I have to code so I only have to support one source file for multiple compilers? I don't really want one version of the Build application source for the GDC compiler and another set of source files
> for
>> the DigitalMars compiler. At this stage, I'm going to have to revert to a macro preprocessor again! I'm sure that is not what Walter envisioned his D-isciples doing.
> 
> Compiling with -d will allow the use of deprecated features.

That IS NOT the problem, Walter.

I don't want to use deprecated features.

I want to use the current features, not old ones that are going away someday. Reasonable, no?

The problem is, that not all compilers are at the same release level, or will share the same features. So if one wants one's product to be to be supported with multiple compilers, how does one code their source files?

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:15:50 AM

On Wed, 8 Jun 2005 09:53:35 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:skmeququbanx$.a6mchwy1wg9c.dlg@40tude.net...
>> Unless Walter provides a way, I will be forced into using a preprocessor
> to
>> generate compilable source code for all the platforms I am hoping to support. This means I also have to make available multiple editions of the source files available so people can download the one(s) they need. Just plain stupidity!
> 
> But that's the point of having the -d switch!
> 
> And since compiler updates are free, there's no reason to support older versions once GDC gets updated.

Exactly! But in the meantime, do I just wait upon othes to all catch up. Today we only have two compilers, but soon we could have many compilers?

I really, really, really, really, would like a cost-effective solution to this very real problem. This is not a stupid request.

The -d switch is a *workaround*. And it only effects certain changes in syntax and not all possible changes.

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 7:19:04 AM

These issues will go away once GDC is up to date and/or D reaches 1.0, so why worry and code work-arounds when you can just relax and wait it out?


Derek Parnell wrote:
> On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:
> 
> 
>>"Derek Parnell" <derek@psych.ward> wrote in message
>>news:zu8pxspfqpou$.j798zboqpqeo$.dlg@40tude.net...
>>
>>>WTF do I have to code so I only have to support one source file for
>>>multiple compilers? I don't really want one version of the Build
>>>application source for the GDC compiler and another set of source files
>>
>>for
>>
>>>the DigitalMars compiler. At this stage, I'm going to have to revert to a
>>>macro preprocessor again! I'm sure that is not what Walter envisioned his
>>>D-isciples doing.
>>
>>Compiling with -d will allow the use of deprecated features.
> 
> 
> That IS NOT the problem, Walter. 
> 
> I don't want to use deprecated features. 
> 
> I want to use the current features, not old ones that are going away
> someday. Reasonable, no?
> 
> The problem is, that not all compilers are at the same release level, or
> will share the same features. So if one wants one's product to be to be
> supported with multiple compilers, how does one code their source files?
> 

"Walter" <newshound@digitalmars.com> wrote in message news:d87med$2l0t$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87k31$2iaq$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:d87hn9$2fmi$3@digitaldaemon.com...
>> >
>> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d87fob$2dn0$1@digitaldaemon.com...
>> >> Having said that and using "practices obvious in the code" motto I am thinking about have a question:
>> >>
>> >> Currently following:
>> >>
>> >> const char[] s = "Hello";
>> >>     s[0] = 0;
>> >>
>> >> compiles just fine.
>> >
>> > It shouldn't. I just haven't gotten around to dealing with that.
>> >
>> >
>>
>> Thanks for clarification.
>>
>> Having implemented this I guess following should be
>> impossible too:
>>       "Hello"[0] = 0;
>> (now it compiles, and more interestingly, works just fine)
>>
>> If you will implement this then it will effectively mean that type of
>> string constant will be something like:
>>       const static char[N]
>>
>> Which will require that:
>>
>>       char[] s = "hello";
>>
>> will allocate new char array, in other words will be equivalent to
>>
>>       char[] s = "hello".dup;
>>
>> Am I right?
>
> No, what I plan to do is put string literals into a read-only section of memory. Attempting to change it will result in a runtime fault.
>
>

I see. So

char[] s = "Hello";
     s[0] = 0;

will compile fine, but will raise AV in runtime.....

Will it be possible to determine in runtime is it read-only array or not without Access Violation Error?

Thanks,

Andrew.

Unknown W. Brackets wrote:
> I didn't mean to imply it wasn't - and, in this time, while D is not yet "stable" and has not reached 1.0, it's fine.  I don't mind the version clashes one bit.
> 
> It's after 1.0 that I will, should another occur at that time.  And I would want other, good, worthwhile updates too - not a cold stop at 1.0 and no prospect of a 2.0.
> 
> -[Unknown]
> 
>>
>> I know upgrades that require source code changes suck. But I hope you'll
>> find that this one is worth it.


Come on, we're in pre 1.0 time, such updates are really appreciated and should not be a problem. Walter, just add introspection/reflection to the language and I'll kill -9 everyone who doesn't switch to D ;)



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

On Wed, 08 Jun 2005 21:54:55 +0000, clayasaurus wrote:

> These issues will go away once GDC is up to date and/or D reaches 1.0, so why worry and code work-arounds when you can just relax and wait it out?

I'm thinking about the general case, and not specifically the "!is" issue.

Yes, one day in the indeterminate future, GDC will catch up with DigitalMars, and even more unknown is when v1.0 is going to happen, but what do I do in the meantime? Are you seriously asking me to never use any new feature of D until both those events happen? I didn't think so.

The new features are meant to be used, right? I'm sure Walter is not adding them just because he's got more time than he knows what to do with.

This problem exists because there was not enough fore thought put in about the future of how a new language is going to evolve. A solution to this real-world problem should have been built into the language from the very beginning. It's probably too late to fix now. Preprocessor - he we come (again).

-- 
Derek Parnell
Melbourne, Australia
9/06/2005 8:02:14 AM

Derek Parnell wrote:

>>These issues will go away once GDC is up to date and/or D reaches 1.0, so why worry and code work-arounds when you can just relax and wait it out?
> 
> I'm thinking about the general case, and not specifically the "!is" issue.
> 
> Yes, one day in the indeterminate future, GDC will catch up with
> DigitalMars, and even more unknown is when v1.0 is going to happen, but
> what do I do in the meantime? Are you seriously asking me to never use any
> new feature of D until both those events happen? I didn't think so.

And what about the 2.0 features ? Won't they suffer the same fate,
once they start trickling down in the 1.1 versions of the language ?

I agree/sympathize with Derek, sounds like it's preprocessor time.

--anders