On 16-05-2012 16:25, Gor Gyolchanyan wrote:
On Wed, May 16, 2012 at 6:10 PM, Alex Rønne Petersen <[email protected] <mailto:[email protected]>> wrote:On 16-05-2012 16:04, Gor Gyolchanyan wrote: On Wed, May 16, 2012 at 5:25 PM, Steven Schveighoffer <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: On Tue, 15 May 2012 18:31:26 -0400, deadalnix <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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 [email protected] <mailto:[email protected]> 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.
C support and interoperability has always been a goal of D; and I don't see that changing.
That's not saying that reimplementing these libraries in D is a bad idea - in fact, it would make everyone's lives easier. So by all means, do that. But I'm using some libraries such as libgc (the Boehm-Demers-Weiser GC) and libffi (foreign function interface for C) that would take eons to port, audit, test, ... and I have a project that depends on them that I need to work on.
-- Alex Rønne Petersen [email protected] http://lycus.org
