On 07/11/2013 10:20 AM, Maxim Fomin wrote:
> On Thursday, 11 July 2013 at 17:07:18 UTC, Ali Çehreli wrote:
>> that magic should be the same as
>> getting the .ptr property.
Yes.
> In context of slices cast(int*)arr is essentially s.ptr.
And yes. :)
Ali
On Thursday, 11 July 2013 at 17:07:18 UTC, Ali Çehreli wrote:
On 07/11/2013 12:23 AM, Jacob Carlborg wrote:
> On 2013-07-10 20:22, Ali Çehreli wrote:
>
>> And to be pedantic, length comes first:
>>
>> struct Array (T)
>> {
>> size_t length;
>> T* ptr;
>> }
>
> I thought "ptr" came firs
On 07/11/2013 12:23 AM, Jacob Carlborg wrote:
> On 2013-07-10 20:22, Ali Çehreli wrote:
>
>> And to be pedantic, length comes first:
>>
>> struct Array (T)
>> {
>> size_t length;
>> T* ptr;
>> }
>
> I thought "ptr" came first, that's the reason you could cast to the
> pointer type. Not
On 2013-07-11 13:19, Jacob Carlborg wrote:
Yes, but that is easier to type. All the above or:
struct Array (T)
{
size_t length;
T* ptr;
}
"that" should have been "what".
--
/Jacob Carlborg
On 2013-07-11 09:43, Maxim Fomin wrote:
It's in the user side. In druntime it is void[] + typeinfo. I am not
aware of any part in dmd/druntime where arrays are repsented as
templates (or strongly typed) as depicted in this dicsussion. And
current treatment can be barely called templatization as
On Thursday, 11 July 2013 at 07:13:50 UTC, Jacob Carlborg wrote:
On 2013-07-11 04:59, Maxim Fomin wrote:
To be pedantic dynamic arrays are implemented in D simply as
struct Array
{
size_t length;
void* ptr;
}
and there is no type parametrization since such arrays
handling is
opaque
On 2013-07-10 20:22, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
I thought "ptr" came first, that's the reason you could cast to the
pointer type. Not that one should do that. Perhaps there's some
compiler/runtime magic in
On 2013-07-11 04:59, Maxim Fomin wrote:
To be pedantic dynamic arrays are implemented in D simply as
struct Array
{
size_t length;
void* ptr;
}
and there is no type parametrization since such arrays handling is
opaque for users (in druntime they are treated as void[]).
Parametrizatio
On Wednesday, 10 July 2013 at 18:22:24 UTC, Ali Çehreli wrote:
And to be pedantic, length comes first:
struct Array (T)
{
size_t length;
T* ptr;
}
Which is actually property-like because assigning to length
does pretty complex stuff. So the member cannot be named as
'length':
struct
On Wednesday, 10 July 2013 at 17:18:09 UTC, JohnnyK wrote:
export string mytest(string tstStr)
{
string st = tstStr;
/* abbreviated to protect the innocent but other operations
such as concatenating and deleting may be done to st
before the return
*/
return st;
}
Arrays are comp
On Wednesday, 10 July 2013 at 17:18:09 UTC, JohnnyK wrote:
I hope you like the subject matter and I hope it is not too
simplistic or have been answered before.
Anyway I have a question about how the garbage collector
works in a very specific situation. When passing string type
to a function
On Wednesday, 10 July 2013 at 18:45:56 UTC, H. S. Teoh wrote:
On Wed, Jul 10, 2013 at 08:38:40PM +0200, JohnnyK wrote:
[...]
Reminds me of how Delphi (aka Pascal) strings are work. Thanks
everyone this answers some of my questions. Now what about
when the
return type of a function is a string
On Wednesday, July 10, 2013 20:38:40 JohnnyK wrote:
> Reminds me of how Delphi (aka Pascal) strings are work. Thanks
> everyone this answers some of my questions. Now what about when
> the return type of a function is a string? Is D returning the
> pointer to the string structure or is it returning
On Wed, Jul 10, 2013 at 08:38:40PM +0200, JohnnyK wrote:
[...]
> Reminds me of how Delphi (aka Pascal) strings are work. Thanks
> everyone this answers some of my questions. Now what about when the
> return type of a function is a string? Is D returning the pointer
> to the string structure or i
On Wed, Jul 10, 2013 at 07:45:25PM +0200, Namespace wrote:
> >A string in D, and all arrays, is a struct looking like this:
> >
> >struct Array (T)
> >{
> >T* ptr;
> >size_t length;
> >}
>
> I always thought it looks like this:
>
> struct Array(T) {
> T* ptr;
> size_t length, capa
On Wednesday, 10 July 2013 at 18:22:24 UTC, Ali Çehreli wrote:
On 07/10/2013 11:10 AM, Sean Kelly wrote:
> On Jul 10, 2013, at 10:45 AM, Namespace
wrote:
>
>>> A string in D, and all arrays, is a struct looking like
this:
>>>
>>> struct Array (T)
>>> {
>>> T* ptr;
>>> size_t length;
>>>
On 07/10/2013 11:10 AM, Sean Kelly wrote:
> On Jul 10, 2013, at 10:45 AM, Namespace wrote:
>
>>> A string in D, and all arrays, is a struct looking like this:
>>>
>>> struct Array (T)
>>> {
>>> T* ptr;
>>> size_t length;
>>> }
>>
>> I always thought it looks like this:
>>
>> struct Array
On Jul 10, 2013, at 10:45 AM, Namespace wrote:
>> A string in D, and all arrays, is a struct looking like this:
>>
>> struct Array (T)
>> {
>>T* ptr;
>>size_t length;
>> }
>
> I always thought it looks like this:
>
> struct Array(T) {
>T* ptr;
>size_t length, capacity;
> }
Sad
A string in D, and all arrays, is a struct looking like this:
struct Array (T)
{
T* ptr;
size_t length;
}
I always thought it looks like this:
struct Array(T) {
T* ptr;
size_t length, capacity;
}
On 2013-07-10 19:18, JohnnyK wrote:
I hope you like the subject matter and I hope it is not too simplistic
or have been answered before.
Anyway I have a question about how the garbage collector works in a
very specific situation. When passing string type to a function in a
shared library or D
I hope you like the subject matter and I hope it is not too
simplistic or have been answered before.
Anyway I have a question about how the garbage collector works
in a very specific situation. When passing string type to a
function in a shared library or DLL and assigning it to a
variable o
21 matches
Mail list logo
