Would Lcl be better if it was in D?

So I was using the Lazarus IDE the other day, and i thought to 
myself, what if i create an application with only a button in it. 
well it was easy enough to do. but behold I saw the executable 
and it was 14 MB, and I said 'well damn.' It seems to me that 
pascal does not do lazy inclusion when it comes to components of 
Lcl apart from pre-compiler directives.

I noticed some includes in d are inside of functions.

void foo() {
  import thingIneed:subfoo;
  subfoo();
}

would this allow people to use a large library like LCL but with 
much smaller executables?

via Digitalmars-d | 1 Mar 16:47 2015

Re: Making RCSlice and DIP74 work with const and immutable

On Sunday, 1 March 2015 at 15:08:47 UTC, H. S. Teoh wrote:
> On Sun, Mar 01, 2015 at 01:43:44PM +0000, via Digitalmars-d 
> wrote:
>> On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote:
> [...]
>> >So then Const!MyClass is a modified version of MyClass where 
>> >the data
>> >fields are const (similarly, we can define Immutable for the
>> >analogous purpose) but the fields marked as metadata will 
>> >remain
>> >mutable.
>> >
>> >Of course, this is just a crude first stab at the problem; 
>> >I'm sure
>> >there's plenty of room for refinement to make it more usable, 
>> >and to
>> >address some obvious roadblocks, like how to make MyClass 
>> >implicitly
>> >convertible to Const!MyClass, etc.. But it seems likely that 
>> >D's
>> >template machinery can actually express this in a way that 
>> >does not
>> >violate the guarantee of physical const.
>> 
>> You still cannot access it through a const reference, though.
>
> The whole point is to use Const!T instead of const(T).

But that's intrusive! You can only apply it code you control, or 
at least you have to convince everyone to use it.
(Continue reading)

via Digitalmars-d | 1 Mar 16:44 2015

RCArray is unsafe

Walter posted an example implementation of a reference counted 
array [1], that utilizes the features introduced in DIP25 [2]. 
Then, in the threads about reference counted objects, several 
people posted examples [3, 4] that broke the suggested 
optimization of eliding `opAddRef()`/`opRelease()` calls in 
certain situations.

A weakness of the same kind affects DIP25, too. The core of the 
problem is borrowing (ref return as in DIP25), combined with 
manual (albeit hidden) memory management. An example to 
illustrate:

     struct T {
         void doSomething();
     }
     struct S {
         RCArray!T array;
     }
     void main() {
         auto s = S(RCArray!T([T()])); // s.array's refcount is 
now 1
         foo(s, s.array[0]);           // pass by ref
     }
     void foo(ref S s, ref T T) {
         s.array = RCArray!T([]);      // drop the old s.array
         t.doSomething();              // oops, t is gone
     }

Any suggestions how to deal with this? As far as I can see, there 
are the following options:
(Continue reading)

Re: Making RCSlice and DIP74 work with const and immutable

On Sunday, 1 March 2015 at 02:53:34 UTC, Manu wrote:
> On 1 March 2015 at 12:48, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> On 2/28/15 6:33 PM, Manu via Digitalmars-d wrote:
>>>
>>> one of the biggest recurring
>>> complaints relating to the D type system
>>
>>
>> That didn't get talked about in I don't remember. -- Andrei
>
> So, what's the solution?
> I've never complained about it, but I still have this problem
> regularly. The solution in my experience is; 'everything is 
> always
> mutable'.

I've lost count now of how many times I've had to downgrade to 
auto despite always wanting immutable or const. This doesn't work:

  auto reg = regex(`(foo)`);
  const match = "foo".matchAll(reg);
  writeln(match.captures); //oops, captures isn't const

It should, but it doesn't. Maxime talked about it here as well:

http://pointersgonewild.com/2014/07/11/the-constness-problem/

Atila

(Continue reading)

via Digitalmars-d | 1 Mar 14:43 2015

Re: Making RCSlice and DIP74 work with const and immutable

On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote:
> On Sun, Mar 01, 2015 at 12:53:24PM +1000, Manu via 
> Digitalmars-d wrote:
>> On 1 March 2015 at 12:48, Andrei Alexandrescu via Digitalmars-d
>> <digitalmars-d <at> puremagic.com> wrote:
>> > On 2/28/15 6:33 PM, Manu via Digitalmars-d wrote:
>> >>
>> >> one of the biggest recurring
>> >> complaints relating to the D type system
>> >
>> >
>> > That didn't get talked about in I don't remember. -- Andrei
>> 
>> So, what's the solution?
>> I've never complained about it, but I still have this problem
>> regularly. The solution in my experience is; 'everything is 
>> always
>> mutable'.
>
> I ran into the same problem, and as a result I hardly ever make 
> use of
> D's const system.
>
> One possible solution that occurred to me, though, is to 
> introduce a
> kind of "logical const" template that constructs a 
> partially-const type,
> with the "logical data" parts const/immutable/etc., but the 
> "metadata"
> parts mutable. User-defined attributes could be used for this 
(Continue reading)

Re: DIP74: Reference Counted Class Objects

On 2/28/15 7:30 PM, Manu via Digitalmars-d wrote:
> On 1 March 2015 at 13:13, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> Inserting calls to opAddRef and opRelease, and the rules that allow their
>> elision, follow quite closely (albeit not 100% identically) the rules for
>> inserting calls to copy constructors and destructors.
>
> The most important case to be elided is the function call case.
> Passing struct to function results in postblit and destructor for
> every call.
> If postblit and destructor were sufficient, we would have been
> satisfied with RC in D for years.

RefCounted has been in there for quite a while and worked with structs. 
Its main problem was it wasn't safe. With DIP25 safety of structs 
(including those that use reference counting for their payload) becomes 
a reality.

>>> Okay, so if I'm not better off then I've always been, what is the good
>>> of DIP74 to me?
>>
>>
>> The title reads "Reference Counted Class Objects".
>
> That title is not immutable.
> If DIP74 is a starting point, and you can see extension to the struct
> case in the future, then I'll let this go now.

It would be mightily confusing to add opAddRef and opRelease calls for 
structs that follow the constructors/destructors ever so closely. It 
(Continue reading)

Re: DIP74: Reference Counted Class Objects

On 2/28/15 7:01 PM, Manu via Digitalmars-d wrote:
> On 1 March 2015 at 12:51, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> On 2/28/15 6:49 PM, Manu via Digitalmars-d wrote:
>>>
>>> On 1 March 2015 at 12:21, Andrei Alexandrescu via Digitalmars-d
>>> <digitalmars-d <at> puremagic.com> wrote:
>>>>
>>>> On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> I'd like to see a struct with RC operators have implicit calls
>>>>> generated (and elided) for exactly the same set of cases as classes,
>>>>> in terms of construction/destruction/assignment/passing to/from
>>>>> functions.
>>>>
>>>>
>>>>
>>>> The short answer is that probably won't happen. -- Andrei
>>>
>>>
>>> *sigh* ... ever, or in DIP74?
>>
>>
>> In the foreseeable future.
>>
>>> I presented my 80% case to you before. I just want this to work
>>> efficiently:
>>>
>>> extern(C) void inc(void*);
(Continue reading)

Re: DIP74: Reference Counted Class Objects

On 2/28/15 6:49 PM, Manu via Digitalmars-d wrote:
> On 1 March 2015 at 12:21, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
>>>
>>> I'd like to see a struct with RC operators have implicit calls
>>> generated (and elided) for exactly the same set of cases as classes,
>>> in terms of construction/destruction/assignment/passing to/from
>>> functions.
>>
>>
>> The short answer is that probably won't happen. -- Andrei
>
> *sigh* ... ever, or in DIP74?

In the foreseeable future.

> I presented my 80% case to you before. I just want this to work efficiently:
>
> extern(C) void inc(void*);
> extern(C) void dec(void*);
>
> struct X
> {
>    void *thing;
>
>    opInc() { inc(thing); }
>    opDec() { dec(thing); }
> }

(Continue reading)

Re: Making RCSlice and DIP74 work with const and immutable

On 2/28/15 6:33 PM, Manu via Digitalmars-d wrote:
> one of the biggest recurring
> complaints relating to the D type system

That didn't get talked about in I don't remember. -- Andrei

Re: Making RCSlice and DIP74 work with const and immutable

On 2/28/15 5:57 PM, Manu via Digitalmars-d wrote:
> Perhaps an operator that may be implemented to return a mutable
> metadata pointer for objects? From an algebraic point of view, it
> should be defined that mutating metadata will have no effect on the
> actual object.

But how would custom data be defined?

> Interestingly, I wonder if such an approach may also be used to
> satisfy a common problem that people have with const objects, where
> it's not possible to implement caching systems for repeated work
> optimisation?
> The result cache is another thing that may be stored in the object's
> metadata...?

That's already abuse. No.

Andrei

Re: DIP74: Reference Counted Class Objects

On 2/28/15 5:43 PM, Manu via Digitalmars-d wrote:
> I'd like to see a struct with RC operators have implicit calls
> generated (and elided) for exactly the same set of cases as classes,
> in terms of construction/destruction/assignment/passing to/from
> functions.

The short answer is that probably won't happen. -- Andrei


Gmane