On Mon, Jun 5, 2017 at 6:55 AM, Volker Reichelt
wrote:
> On 15 May, Martin Sebor wrote:
>>> So how about the following then? I stayed with the catch part and added
>>> a parameter to the warning to let the user decide on the warnings she/he
>>> wants to get: -Wcatch-value=n.
>>> -Wcatch-value=1 on
On 15 May, Martin Sebor wrote:
>> So how about the following then? I stayed with the catch part and added
>> a parameter to the warning to let the user decide on the warnings she/he
>> wants to get: -Wcatch-value=n.
>> -Wcatch-value=1 only warns for polymorphic classes that are caught by
>> value (
On Tue, May 30, 2017 at 2:14 AM, Volker Reichelt
wrote:
> On 24 May, Jason Merrill wrote:
>> On Mon, May 15, 2017 at 3:58 PM, Martin Sebor wrote:
So how about the following then? I stayed with the catch part and added
a parameter to the warning to let the user decide on the warnings she
On 24 May, Jason Merrill wrote:
> On Mon, May 15, 2017 at 3:58 PM, Martin Sebor wrote:
>>> So how about the following then? I stayed with the catch part and added
>>> a parameter to the warning to let the user decide on the warnings she/he
>>> wants to get: -Wcatch-value=n.
>>> -Wcatch-value=1 onl
On Mon, May 15, 2017 at 3:58 PM, Martin Sebor wrote:
>> So how about the following then? I stayed with the catch part and added
>> a parameter to the warning to let the user decide on the warnings she/he
>> wants to get: -Wcatch-value=n.
>> -Wcatch-value=1 only warns for polymorphic classes that a
So how about the following then? I stayed with the catch part and added
a parameter to the warning to let the user decide on the warnings she/he
wants to get: -Wcatch-value=n.
-Wcatch-value=1 only warns for polymorphic classes that are caught by
value (to avoid slicing), -Wcatch-value=2 warns for
On 7 May, Martin Sebor wrote:
> On 05/07/2017 02:03 PM, Volker Reichelt wrote:
>> On 2 May, Martin Sebor wrote:
>>> On 05/01/2017 02:38 AM, Volker Reichelt wrote:
Hi,
catching exceptions by value is a bad thing, as it may cause slicing, i.e.
a) a superfluous copy
b) which
On Sun, May 7, 2017 at 8:05 PM, Martin Sebor wrote:
> On 05/07/2017 02:03 PM, Volker Reichelt wrote:
>>
>> On 2 May, Martin Sebor wrote:
>>>
>>> On 05/01/2017 02:38 AM, Volker Reichelt wrote:
Hi,
catching exceptions by value is a bad thing, as it may cause slicing,
i.e.
>
On 05/07/2017 02:03 PM, Volker Reichelt wrote:
On 2 May, Martin Sebor wrote:
On 05/01/2017 02:38 AM, Volker Reichelt wrote:
Hi,
catching exceptions by value is a bad thing, as it may cause slicing, i.e.
a) a superfluous copy
b) which is only partial.
See also
https://github.com/isocpp/CppCor
On 2 May, Martin Sebor wrote:
> On 05/01/2017 02:38 AM, Volker Reichelt wrote:
>> Hi,
>>
>> catching exceptions by value is a bad thing, as it may cause slicing, i.e.
>> a) a superfluous copy
>> b) which is only partial.
>> See also
>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCo
On 05/01/2017 02:38 AM, Volker Reichelt wrote:
Hi,
catching exceptions by value is a bad thing, as it may cause slicing, i.e.
a) a superfluous copy
b) which is only partial.
See also
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#e15-catch-exceptions-from-a-hierarc
Hi,
catching exceptions by value is a bad thing, as it may cause slicing, i.e.
a) a superfluous copy
b) which is only partial.
See also
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#e15-catch-exceptions-from-a-hierarchy-by-reference
To warn the user about catch han
12 matches
Mail list logo