About 2 million in C++.

source: http://www.ohloh.net/p/qt/analyses/latest/languages_summary


On Wed, Jul 11, 2012 at 10:28 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >
> How many lines total?
>
> Andrei
>

On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
>
> We can't really model every possible design.
>

If it cannot be modelled, it is not a possible design.

On 7/11/12 11:33 AM, Caligo wrote:
> About 2 million in C++.
>
> source:
> http://www.ohloh.net/p/qt/analyses/latest/languages_summary

I agree that 1500 occurrences of "mutable" in 2 million lines of C++ is quite large.

Andrei

On 7/11/12 12:12 PM, Timon Gehr wrote:
> On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
>>
>> We can't really model every possible design.
>>
>
> If it cannot be modelled, it is not a possible design.

There is if it can be modeled in a less constrained language.

Andrei

On Wednesday, 11 July 2012 at 15:57:51 UTC, Andrei Alexandrescu wrote:
> On 7/11/12 11:50 AM, Max Samukha wrote:
>> On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei Alexandrescu wrote:
>>> On 7/11/12 11:11 AM, Max Samukha wrote:
>>>> On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu wrote:
>>>>
>>>>>
>>>>> I gave evidence on a large, high quality C++ codebase that the use of
>>>>> mutable (which is the solution of choice for memoization, caching, and
>>>>> lazy computation) is extremely scarce.
>>>>>
>>>>> What evidence do you have for your prediction?
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>> Qt codebase (large, high quality) has around 1500 'mutable' keyword
>>>> occurrences.
>>>
>>> How many lines total?
>>>
>>> Andrei
>>
>> 1512. Obtained by grepping the src directory of Qt 4.8.0, so the number
>> includes duplicates, comments, etc. I think that even if the actual
>> number is lower by an order, some 100 types using mutable still do not
>> qualify for 'extremely scarce'. If I have time (which is unlikely), I
>> will probably analyse the codebase for the actual number.
>
> I was asking about total number of C++ code lines. In our codebase we have one use of "mutable" per 7659 lines of C++ code (as grep and wc count).
>
> Andrei

Sorry, I misunderstood the question. As I said earlier, the relative number of lines with 'mutable' is mostly irrelevant. What is more relevant is the ratio of types defining at least one mutable member to the total number of types.

On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
> On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
> >This solution is not for allowing people to use lazy computation in their const overrides, it's for allowing people to still use opEquals, toString etc. even if their implementations cannot and should not be const.
> >
> 
> In this case, they have function that does something else than compare test for equality, etc . . . The overload make no sense here in the first place, and the fact that const break such thing isn't a problem. This is the other way around, the fact that const break such a practice is good.

It *is* a problem when you're talking about abstractions. If I have million node binary trees and I'm testing for equality, I'd like to be able to cache the results. But being forced to use const means I can't cache anything. And this isn't just about caching; if my tree is partially stored in the database, and I have a DB connection object in my tree class, then I can't use opEquals because I can't modify the DB state (which is impractical if I have to actually use it to make DB queries -- the DB engine may have to cache DB pages, etc.). Any abstraction of opEquals beyond the bitwise level cannot be implemented.

In other words, druntime's opEquals is useless in this case. Since const is viral, as soon as one class deep in your class hierarchy needs non-const, your entire class hierarchy is out of luck. Users will have to sidestep the issue by implementing their own version of equality comparison. Which means they have to implement their own version of AA's, because built-in AA's use opEquals, and they have to implement their own version of array comparisons for the same reason, etc.. They will essentially have to rebuild the entire infrastructure provided in druntime.

So every user and every library will have their own infrastructure for non-const comparisons, and it will be a major nightmare trying to interoperate between them. All because the single standard, druntime, insists that comparisons must be bitwise const.

Sure, it's a good thing, from a theoretical ivory-tower point of view. It's also impractical for non-trivial applications.


T

-- 
Many open minds should be closed for repairs. -- K5 user

On 7/11/12 12:30 PM, H. S. Teoh wrote:
> It *is* a problem when you're talking about abstractions. If I have
> million node binary trees and I'm testing for equality, I'd like to be
> able to cache the results. But being forced to use const means I can't
> cache anything. And this isn't just about caching; if my tree is
> partially stored in the database, and I have a DB connection object in
> my tree class, then I can't use opEquals because I can't modify the DB
> state (which is impractical if I have to actually use it to make DB
> queries -- the DB engine may have to cache DB pages, etc.). Any
> abstraction of opEquals beyond the bitwise level cannot be implemented.

How about the static (h|c)ache??

Andrei

On 7/11/12 12:30 PM, H. S. Teoh wrote:
> It *is* a problem when you're talking about abstractions. If I have
> million node binary trees and I'm testing for equality, I'd like to be
> able to cache the results. But being forced to use const means I can't
> cache anything. And this isn't just about caching; if my tree is
> partially stored in the database, and I have a DB connection object in
> my tree class, then I can't use opEquals because I can't modify the DB
> state (which is impractical if I have to actually use it to make DB
> queries -- the DB engine may have to cache DB pages, etc.). Any
> abstraction of opEquals beyond the bitwise level cannot be implemented.

How about the static hash/cache?

Andrei

On 11/07/2012 18:30, H. S. Teoh wrote:
> On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
>> On 11/07/2012 17:03, Jakob Ovrum wrote:
> [...]
>>> This solution is not for allowing people to use lazy computation in
>>> their const overrides, it's for allowing people to still use
>>> opEquals, toString etc. even if their implementations cannot and
>>> should not be const.
>>>
>>
>> In this case, they have function that does something else than
>> compare test for equality, etc . . . The overload make no sense here
>> in the first place, and the fact that const break such thing isn't a
>> problem. This is the other way around, the fact that const break
>> such a practice is good.
>
> It *is* a problem when you're talking about abstractions. If I have
> million node binary trees and I'm testing for equality, I'd like to be
> able to cache the results. But being forced to use const means I can't
> cache anything. And this isn't just about caching; if my tree is
> partially stored in the database, and I have a DB connection object in
> my tree class, then I can't use opEquals because I can't modify the DB
> state (which is impractical if I have to actually use it to make DB
> queries -- the DB engine may have to cache DB pages, etc.). Any
> abstraction of opEquals beyond the bitwise level cannot be implemented.
>

Either the structure is mutable, and you have to recompute anyway, or the structure is trully const and thing can be computed up-front.

On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
> On 7/11/12 12:30 PM, H. S. Teoh wrote:
>> It *is* a problem when you're talking about abstractions. If I have
>> million node binary trees and I'm testing for equality, I'd like to be
>> able to cache the results. But being forced to use const means I can't
>> cache anything. And this isn't just about caching; if my tree is
>> partially stored in the database, and I have a DB connection object in
>> my tree class, then I can't use opEquals because I can't modify the DB
>> state (which is impractical if I have to actually use it to make DB
>> queries -- the DB engine may have to cache DB pages, etc.). Any
>> abstraction of opEquals beyond the bitwise level cannot be implemented.
>
> How about the static hash/cache?
>
> Andrei

Will break horribly as soon as it is discovered that the methods should be pure as well.