'Re: [CMake] Tests with assert and Release build type'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cmake
Subject:    Re: [CMake] Tests with assert and Release build type
From:       Ruslan Baratov via CMake <cmake () cmake ! org>
Date:       2015-12-24 16:20:59
Message-ID: 567C1B6B.1020703 () yahoo ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On 24-Dec-15 19:46, Magnus Therning wrote:
> I'm *not* mixing stuff built with `-g` and stuff built without it.
Actually I don't see anything bad about mixing `-g` code with code 
without `-g`.

>    I'm
> also *not* mixing linking with debug- and non-debug libraries.
Since we cover a lot of aspects please specify what you mean by debug 
and non-debug libraries.

> I'm only mixing stuff build with `-DNDEBUG` and stuff built without it.
see below

On 24-Dec-15 19:48, Magnus Therning wrote:
> Ruslan Baratov writes:
>
>> On 22-Dec-15 04:07, Magnus Therning wrote:
>>
>> It is possible to hit situation when ODR will be violated, e.g. if
>> somebody define optional member in structure with "#if defined(NDEBUG)"
>> condition. Something like this:
>> http://stackoverflow.com/questions/20833226/library-headers-and-define
> Yes, if we ever start using the NDEBUG macro to control anything in our
> code then I'll have to worry about this, as it stands right now it's
> only the `assert` from `assert.h` that cares about it.
Even if you care only about `assert` somebody can define different type 
of structures based on value of NDEBUG. I'm talking about 3rd party 
library that you can use and you can't control. If this will lead to ODR 
violation then bug is NOT in 3rd party code, but in YOUR code. That's my 
point. You can mix c++11 with c++98, libc++ with libstdc++, mingw with 
cygwin, mingw with Visual Studio, NDEBUG with non NDEBUG, and it MAY 
works, but when something suddenly will stop working with very obscure 
errors that it's YOUR fault and not 3rd party.//

> If I'm reading you correctly you are advocating I simply get rid of the
> use of those asserts altogether instead.
I'm not sure what you mean. I'm just telling that if you want do some 
runtime checks even when NDEBUG is OFF then you should introduce your 
own macro FOO_DEBUG. Difference is about global/local affects.

Ruslo

[Attachment #5 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">
      <div class="moz-cite-prefix">On 24-Dec-15 19:46, Magnus Therning
        wrote:<br>
      </div>
      <blockquote cite="mid:871tac10bz.fsf@therning.org" type="cite">
        <pre wrap="">I'm *not* mixing stuff built with `-g` and stuff built without \
it.</pre>  </blockquote>
      Actually I don't see anything bad about mixing `-g` code with code
      without `-g`.<br>
      <br>
      <blockquote cite="mid:871tac10bz.fsf@therning.org" type="cite">
        <pre wrap="">  I'm
also *not* mixing linking with debug- and non-debug libraries.</pre>
      </blockquote>
      Since we cover a lot of aspects please specify what you mean by
      debug and non-debug libraries.<br>
      <br>
      <blockquote cite="mid:871tac10bz.fsf@therning.org" type="cite">
        <pre wrap="">I'm only mixing stuff build with `-DNDEBUG` and stuff built \
without it.</pre>  </blockquote>
      see below<br>
      <br>
      On 24-Dec-15 19:48, Magnus Therning wrote:<br>
    </div>
    <blockquote cite="mid:87zix0yptw.fsf@therning.org" type="cite">
      <pre wrap="">
Ruslan Baratov writes:

</pre>
      <blockquote type="cite">
        <pre wrap="">On 22-Dec-15 04:07, Magnus Therning wrote:

</pre>
        <pre wrap="">It is possible to hit situation when ODR will be violated, e.g. \
if somebody define optional member in structure with "#if defined(NDEBUG)"
condition. Something like this:
<a class="moz-txt-link-freetext" \
href="http://stackoverflow.com/questions/20833226/library-headers-and-define">http://stackoverflow.com/questions/20833226/library-headers-and-define</a>
 </pre>
      </blockquote>
      <pre wrap="">
Yes, if we ever start using the NDEBUG macro to control anything in our
code then I'll have to worry about this, as it stands right now it's
only the `assert` from `assert.h` that cares about it.</pre>
    </blockquote>
    Even if you care only about `assert` somebody can define different
    type of structures based on value of NDEBUG. I'm talking about 3rd
    party library that you can use and you can't control. If this will
    lead to ODR violation then bug is NOT in 3rd party code, but in YOUR
    code. That's my point. You can mix c++11 with c++98, libc++ with
    libstdc++, mingw with cygwin, mingw with Visual Studio, NDEBUG with
    non NDEBUG, and it MAY works, but when something suddenly will stop
    working with very obscure errors that it's YOUR fault and not 3rd
    party.<i></i><br>
    <br>
    <blockquote cite="mid:87zix0yptw.fsf@therning.org" type="cite">
      <pre wrap="">If I'm reading you correctly you are advocating I simply get rid \
of the use of those asserts altogether instead.
</pre>
    </blockquote>
    I'm not sure what you mean. I'm just telling that if you want do
    some runtime checks even when NDEBUG is OFF then you should
    introduce your own macro FOO_DEBUG. Difference is about global/local
    affects.<br>
    <br>
    Ruslo<br>
  </body>
</html>

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[prev in list] [next in list] [prev in thread] [next in thread] 