The more interesting question

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed May 16 07:25:04 PDT 2012


On Wed, May 16, 2012 at 6:10 PM, Alex Rønne Petersen <alex at lycus.org> wrote:

> On 16-05-2012 16:04, Gor Gyolchanyan wrote:
>
>> On Wed, May 16, 2012 at 5:25 PM, Steven Schveighoffer
>> <schveiguy at yahoo.com <mailto:schveiguy at yahoo.com>> wrote:
>>
>>    On Tue, 15 May 2012 18:31:26 -0400, deadalnix <deadalnix at gmail.com
>>    <mailto:deadalnix at gmail.com>> wrote:
>>
>>        Le 15/05/2012 17:51, Christophe a écrit :
>>
>>            deadalnix , dans le message (digitalmars.D:167404), a écrit :
>>
>>                This looks to me like a bad practice. C string and D
>>                string are
>>                different beasts, and we have toStringz .
>>
>>
>>            C string and D string are different, but it's not a bad idea
>>            to have
>>            string *literals* that works for both C and D strings,
>>            otherwise using
>>            printf will lead to a bug each time the programmer forget
>>            the trailing
>>            \0.
>>
>>
>>        Due to slicing, it is already unsafe to pass a D string to C
>>        code. The main problem is array casting silently to pointers,
>>        making the error easy to do.
>>
>>
>>    How so?  strings are immutable, and literals are *truly* immutable.
>>
>>
>>        Fixing the problem for literal isn't going to solve it at all.
>>
>>        The real solution is toStringz
>>
>>
>>    toStringz can allocate a new block in order to ensure 0 gets added.
>>      This is ludicrous!
>>
>>    You are trying to tell me that any time I want to call a C function
>>    with a string literal, I have to first heap-allocate it, even though
>>    I *know* it's safe.
>>
>>    I don't see a "problem" anywhere.  The current system is perfect for
>>    what it needs to do.
>>
>>    -Steve
>>
>>
>> Aside from the string problem the very existence of this debate exposes
>> a fundamental flaw in the entire software engineering industry: heavy
>> usage of ancient crap.
>> If some library is so damned hard to refresh, then something's terribly
>> wrong with it. It's about damned time ancient libraries are thrown away.
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> I... don't think that's a very pragmatic view.
>
> Yes, software sucks. Deal with it, etc.
>
>
> --
> Alex Rønne Petersen
> alex at lycus.org
> http://lycus.org
>

Deal with it? That's the attitude that made it this way in the first place.
If you like having software this way till the end of times - be my guest. I
for one will not tolerate this unacceptably obsolete software. If you want
it to stop being this bad - you're welcome to join me in the effort to put
an end to this. It seems impossible only because nobody actually tried
doing anything and all everybody does is complain about ancient stuff still
requiring compatibility. With some effort that can be changed. Ancient
libraries still require compatibility not because it's a rule, but because
there are people who use them. They use them because there are no
alternatives. If some people deliberately refuse to embrace the progress -
it's their damned problem.

-- 
Bye,
Gor Gyolchanyan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120516/b3568328/attachment.html>


More information about the Digitalmars-d mailing list