On Tue, 26 Apr 2011 16:27:00 -0400, Alexander wrote:
Then, there is one issue left - old code... :)
The compiler should tell you all the places where you have to fix the old
code ;)
-Steve
On 26.04.2011 19:15, Steven Schveighoffer wrote:
> In other words, casting an array to a pointer is first of all a hack, and
> second of all 100% unnecessary. It's just wasting compiler code space.
Indeed, your arguments are very convincing - being a person like "I know what
I'm doing" I typ
Steven Schveighoffer:
> D would not allow you to pass a .ptr field of an immutable string, because
> the type would be immutable(char)* and wouldn't implicitly cast to the
> required char* argument. Casting, however, would mask that problem and
> probably overwrite immutable data (and proba
On 4/26/11, Steven Schveighoffer wrote:
> On Tue, 26 Apr 2011 13:11:20 -0400, Andrej Mitrovic
> wrote:
>
>> On 4/26/11, Timon Gehr wrote:
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
>>>
>>> There is a possibility for
On Tue, 26 Apr 2011 10:08:21 -0400, Alexander wrote:
On 26.04.2011 15:21, Daniel Gibson wrote:
No, in D arrays are not just pointers. It's indeed a struct that
contains the length (arr.length) and the pointer (arr.ptr).
If this is a struct, then there is no "special compiler handling"
n
On Tue, 26 Apr 2011 13:11:20 -0400, Andrej Mitrovic
wrote:
On 4/26/11, Timon Gehr wrote:
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
There is a possibility for buffer overflow.
No, I mean the C function will overwrit
On 4/26/11, Timon Gehr wrote:
>> Isn't it dangerous to pass a D string and let the C code overwrite the
>> string, regardless of char* vs .ptr field?
>
> There is a possibility for buffer overflow.
>
No, I mean the C function will overwrite an immutable string.
> Isn't it dangerous to pass a D string and let the C code overwrite the
> string, regardless of char* vs .ptr field?
There is a possibility for buffer overflow.
On 26/04/11 2:11 PM, Alexander wrote:
On 26.04.2011 13:59, Steven Schveighoffer wrote:
Currently, casting an array to a pointer is a special case of casting in the
compiler, which basically returns arr.ptr. However, that functionality is
already available via arr.ptr.
To me (coming from
On 26.04.2011 15:21, Daniel Gibson wrote:
> No, in D arrays are not just pointers. It's indeed a struct that
> contains the length (arr.length) and the pointer (arr.ptr).
If this is a struct, then there is no "special compiler handling" needed to
cast a struct to a pointer using opCast() (exce
Am 26.04.2011 15:11, schrieb Alexander:
> After all, array is a pointer (=reference), and arrays are not structs
> (=values), so I see no reason to disallow this, to be honest.
>
No, in D arrays are not just pointers. It's indeed a struct that
contains the length (arr.length) and the pointer (ar
On 26.04.2011 13:59, Steven Schveighoffer wrote:
> Currently, casting an array to a pointer is a special case of casting in the
> compiler, which basically returns arr.ptr. However, that functionality is
> already available via arr.ptr.
To me (coming from C/C++) it looks more natural to cast
On Tue, 26 Apr 2011 06:31:39 -0400, Alexander wrote:
On 25.04.2011 17:36, Steven Schveighoffer wrote:
Not when a string is defined internally as struct { size_t length;
immutable(char)* ptr; }. Casting to char* is a pointer to the start
of the length, not the pointer.
Try it.
I though
On 25.04.2011 17:36, Steven Schveighoffer wrote:
>>> Not when a string is defined internally as struct { size_t length;
>>> immutable(char)* ptr; }. Casting to char* is a pointer to the start of the
>>> length, not the pointer.
>>
>> Try it.
>>
>
> I thought that "feature" was removed from D2?
bearophile:
> I don't need a perfect language, but I fail to understand why
> similar little pieces of trash are wanted in any language.
It's probably meant to make interaction with C a little easier. In
C, arrays and pointers are interchangeable in a lot of places. It'd
make D code look more like
Steven Schveighoffer:
> simpler language spec/compiler :)
Here there are several people that use D that find surprising things in a tiny
piece of code, and discuss about it with many posts. This is the best
demonstration that this is a special case that adds complexity to the language,
that ne
Daniel Gibson:
> No. Casting other structs (*not* pointer to struct) is in fact illegal.
> (This just occured to me, I didn't think of this when writing the other
> post)
Right, sorry.
> So my only remaining objection is: Allowing it doesn't hurt (IMHO) and
> disallowing may break existing code
On Mon, 25 Apr 2011 13:40:30 -0400, Daniel Gibson
wrote:
Am 25.04.2011 19:30, schrieb bearophile:
Daniel Gibson:
So why not just leave it the way it is?
It muds the semantic of the language, adding another special case. I
think the right (right = shared with other structs) semantics he
Am 25.04.2011 19:30, schrieb bearophile:
> Daniel Gibson:
>
>> So why not just leave it the way it is?
>
> It muds the semantic of the language, adding another special case. I think
> the right (right = shared with other structs) semantics here is to return the
> address of the length field.
>
On Mon, 25 Apr 2011 12:55:38 -0400, Andrej Mitrovic
wrote:
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
Yes. Using sprintf is dangerous regardless of what language you are
using. It is advised to use D equivalents.
-
On Mon, 25 Apr 2011 12:47:20 -0400, Daniel Gibson
wrote:
Am 25.04.2011 17:36, schrieb Steven Schveighoffer:
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 2
Daniel Gibson:
> So why not just leave it the way it is?
It muds the semantic of the language, adding another special case. I think the
right (right = shared with other structs) semantics here is to return the
address of the length field.
My experience based seeing it happen again and again te
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
Am 25.04.2011 17:36, schrieb Steven Schveighoffer:
> On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
> wrote:
>
>> On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
>> wrote:
>>
>>> On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighof
On Mon, 25 Apr 2011 18:42:32 +0300, Steven Schveighoffer
wrote:
Regardless of all this, cast(char *)buffer is *not* recommended D code,
and will likely fail in some future 2.x version of the compiler.
I'm pretty sure I learned of this trick from reading some Phobos code.
Perhaps this beh
On Mon, 25 Apr 2011 11:39:28 -0400, Steven Schveighoffer
wrote:
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveig
On 25/04/2011 16:26, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
jus
On 25/04/2011 16:36, Steven Schveighoffer wrote:
Try it.
I thought that "feature" was removed from D2? Just tested it, and it's
definitely not removed yet. But it will be :)
-Steve
Thanks for putting my mind at ease, I just spent ten minutes writing
various variations and disassembling them
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char*
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char* is exactly the same as using the .ptr
property, as far as genera
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char* is exactly the same as using the .ptr property,
as far as generated code is concerned.
--
Best regards,
On Sun, 24 Apr 2011 17:22:39 -0400, dsimcha wrote:
On 4/24/2011 5:22 PM, Justin Hanekom wrote:
Hi all,
I have what should be an *extremely* simple question that Im banging my
head against: how to use
sprintf to format something to a string.
I have tried:
import std.stdio
Thanks dsimcha, Ben, and Adam,
You guys are great!
If you just want to format a string use std.string.format.
import std.string;
int i=1;
float f=2.5f;
string s = "test";
string output = format("%s %s %s",i,f,s);
If you use the %s placeholder the type will automatically be determined
and printed out correctly.
--
Kind Regards
Benjamin Thaut
Thanks Adam,
My main problem, I guess, is that I can't seem to find the documentation for
these
functions in D. I'll be checking out the link you sent for the format function
shortly.
I don't expect the function to be able to do the thousands formatting for me
(C's
version works if you use "%'
You might try the format() function instead:
http://dpldocs.info/std.string.format
Though, I don't think it does thousands grouping, so it might not
work for you.
If you need C's sprintf, make sure the strings are zero terminated
and that you're passing pointers to them:
char[10] buffer;
sprin
On 4/24/2011 5:22 PM, Justin Hanekom wrote:
Hi all,
I have what should be an *extremely* simple question that Im banging my head
against: how to use
sprintf to format something to a string.
I have tried:
import std.stdio;
...
auto buffer = new char[12];
auto chars_written
Hi all,
I have what should be an *extremely* simple question that Im banging my head
against: how to use
sprintf to format something to a string.
I have tried:
import std.stdio;
...
auto buffer = new char[12];
auto chars_written = sprintf(cast(char *) buffer, "%d", 12345);
40 matches
Mail list logo
