C++ Logo

STD-DISCUSSION

Advanced search

Subject: Re: extremely long compile time with large number of string literals
From: Marcin Jaczewski (marcinjaczewski86_at_[hidden])
Date: 2020-07-10 03:55:57


pt., 10 lip 2020 o 10:30 Artur Czajkowski <atch.cpp_at_[hidden]> napisał(a):

> @Marcin Jaczewski <marcinjaczewski86_at_[hidden]> I addressed you so that
> is enough. Don't have to reply to your particular email. And if big O
> notation as you say will give nothing then you are not a person that I wish
> to discuss things with you. Also your explanation either or both doesn't
> make sense nor you don't understand how Big O works.
>
>
Did you read my email? You do not answer to `std::map` example or how to
define `n` in this notation. How do you want have any useful Big O
definition without addressing this two problems?
Do you know that bubble sort is better than quick sort in some corner
cases? And this quick sort is another great example of limits of Big O
notation. If you demand that compilers need to have `O(n log n)` complexity
then you cannot use quick sort because it have only that complexity in best
case, worst case is `O (n * n)`. If you allow exception to O complexity
then you will end up with situation that Mandeep Sandhu have, and this will
be still standard conforming implementation.

And for quotes, you need to do it, because this is for all others how read
your emails on the public list. how they would know what I said and what
you were referring to?

> On Fri, Jul 10, 2020 at 10:26 AM Marcin Jaczewski <
> marcinjaczewski86_at_[hidden]> wrote:
>
>>
>>
>> pt., 10 lip 2020 o 08:26 Artur Czajkowski <atch.cpp_at_[hidden]>
>> napisał(a):
>>
>>> @Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
>>> I'm not talking about putting limits on compilation time. I'm talking
>>> about introducing constraints in a form of Big O notation with regards to
>>> time complexity that needs to be met by compiler implementer in order to
>>> conform to the standard.
>>>
>>>
>>>
>> Big O notation will give you nothing, this could be the same case as
>> `std::map` and `std::vector`, with one have better big O guarantees and
>> with one you should use?
>> And again you ignored the fact that I show you an example when putting
>> any restriction on complexity you prevent compiler optimizations (if it
>> have a bigger than given O haractersitic).
>> Another important question is how you define this `n` in `O(n)`? Number
>> characters in source file? Tokens? Classes?
>> This is why I suggest putting hard limits on users, because with them
>> everything could be described as very "fat" `O(1)`.
>>
>> Btw could you reply to my email, not to some random one? Or at least put
>> a proper quote of its text.
>>
>>
>>
>>> On Thu, Jul 9, 2020 at 11:34 PM Mandeep Sandhu via Std-Discussion <
>>> std-discussion_at_[hidden]> wrote:
>>>
>>>> >
>>>> > Overload resolution. Try passing suffixed-string literals,
>>>> >
>>>> > const std::unordered_set<std::string> my_set ({"item1"s, "item2"s,
>>>> ....});
>>>>
>>>> I tried creating UDL strings like you suggested (but with a space
>>>> between the literal & s), but it doesn't compile for me.
>>>>
>>>> A simple program like:
>>>> ...
>>>> const unordered_set<string> myset ({ "a" s, "b" s, "c" s, });
>>>> int main()
>>>> {
>>>> cout << "size of myset = " << myset.size() << endl;
>>>> }
>>>>
>>>> Doesn't compile, I get the error:
>>>> ...
>>>> error: expected ‘}’ before ‘s’
>>>> 7 | const unordered_set<string> myset ({ "a" s, "b" s, "c" s, });
>>>>
>>>> Maybe I'm doing it wrong (I haven't used UDLs before).
>>>>
>>>> Thanks.
>>>> -mandeep
>>>> --
>>>> Std-Discussion mailing list
>>>> Std-Discussion_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Best regards
>>> *Artur Czajkowski*
>>>
>>> https://marketplace.visualstudio.com/items?itemName=GitAtomic.GitAtomic
>>>
>>>
>
> --
>
>
> Best regards
> *Artur Czajkowski*
>
> https://marketplace.visualstudio.com/items?itemName=GitAtomic.GitAtomic
>
>



STD-DISCUSSION list run by std-discussion-owner@lists.isocpp.org

Older Archives on Google Groups