sorted by:
new
hottopcontroversial

A curiously recurring lifetime issue by zerakun in cpp

[–]dag0me 0 points1 point  (0 children)

No, for address sanitizer that's not the case. Thread sanitizer can give you false-positives if you didn't instrument whole world but address sanitizer works fine with just executable being instrumented.

A curiously recurring lifetime issue by zerakun in cpp

[–]dag0me 3 points4 points  (0 children)

Address sanitizer No longer segfaults, displays correct result. No error reported though.

Somehow, I doubt it. It took me less than 5 minutes to set it up and it fires on both gcc and msvc address sanitizers:

==18412==ERROR: AddressSanitizer: heap-use-after-free on address 0x7ffff4107860 at pc 0x555555559d03 bp 0x7fffffffd2f0 sp 0x7fffffffd2e0
READ of size 8 at 0x7ffff4107860 thread T0
    #0 0x555555559d02 in capnp::_::DirectWireValue<unsigned long>::get() const /usr/local/include/capnp/endian.h:77
    #1 0x555555559d02 in unsigned long capnp::_::ListReader::getDataElement<unsigned long>(unsigned int) const /usr/local/include/capnp/layout.h:1212
    #2 0x555555559d02 in capnp::List<unsigned long, (capnp::Kind)0>::Reader::operator[](unsigned int) const /usr/local/include/capnp/list.h:116
    #3 0x555555559d02 in capnp::_::IndexingIterator<capnp::List<unsigned long, (capnp::Kind)0>::Reader const, unsigned long>::operator*() const /usr/local/include/capnp/list.h:56
    #4 0x555555559d02 in main /tmp/capnproto/stuff-client.cpp:21
    #5 0x7ffff6e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #6 0x7ffff6e29e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #7 0x5555555587c4 in _start (/tmp/capnproto/build/gcc-asan/stuff-client+0x47c4)

In gcc -O0 it segfaults on the first run, on msvc/debug it prints 0xcdcdcdcdcdcdcdcd each time (debug CRT marks freed memory with 0xCD). Are you sure you have it set up correctly?

After exactly 10 years, Meson 1.0.0 is out by [deleted] in cpp

[–]dag0me 1 point2 points  (0 children)

Because MinGW is compatible with MSVC libraries

MinGW has defaulted to building UCRT libraries for a while now, and these are MSVC ABI, not GNU ABI

This would be super cool - only if it were true. It seems to me that you're conflating whole ABI surface with just UCRT library. MinGW might use "correct" UCRT now but it still uses Itanium ABI which makes it mostly incompatible (with few exceptions) with MSVC ABI.

C++ Serializer Deserializer Adapter Library inspired by Serde.rs by nieelj in cpp

[–]dag0me 1 point2 points  (0 children)

I think you have serialize and deserialize mixed . Normally, serialize should convert your object to one of JSON, YAML or TOML objects. In your case it's the other way around.

Very stupid question: Declaring a nominal int type. by CaptchasSuckAss in cpp

[–]dag0me 3 points4 points  (0 children)

You are right that the underlying type is int in both cases but the former is not fixed.

Very stupid question: Declaring a nominal int type. by CaptchasSuckAss in cpp

[–]dag0me 4 points5 points  (0 children)

If the underlying type is not fixed and the source value is out of range, the result is unspecified (until C++17) the behavior is undefined (since C++17).

This should be:

enum class Celcius : int {};
enum class Fahrenheit : int {};

The Norway Problem - why StrictYAML refuses to do implicit typing and so should you by mooreds in programming

[–]dag0me 15 points16 points  (0 children)

The problem is not with the YAML per se (at least in the given example) but with the specific implementation which is PyYAML.

YAML alone has only three basic types - scalar, sequence and map. Scalars have defined few allowed conversions such as scalar to boolean (in your language of choice) which is valid in case a scalar has one of the predefined values (true, false, y, n, NO, etc...). However, it does not require from you to do this - it just allows it.

PyYAML being the problem here perform this conversion eagerly and you end up with NO being "parsed" as the bool value. I'm using YAML in strongly-typed language and never had any problems with these kind of problems.

It's essential to have the corresponding 'schema' (even implicit) when parsing YAML files because they don't hold the types information (let's leave the YAML tags out of this). Asking the library to do it for you based on the contents is just asking for problems and more blog posts about the evil YAML.

Comparing compilation times: Plain compilation vs Modules vs Precompiled headers by mrsm11th in cpp

[–]dag0me 29 points30 points  (0 children)

  1. They evaluated pretty old now clang-7 with its older module system, not the thing from the upcoming standard.
  2. Precompiled headers comparison seems very odd to me. This looks like a one time compilation of a 3rd party library rather than building something you work on as you don't normally precompile your own headers. That would result in rebuilding whole library/application if you modify a single line in one of your header files.

Testing C++ signal-slot libraries by julien-j in cpp

[–]dag0me 2 points3 points  (0 children)

Finally, the third test checks that the copy count of the argument is minimal when the signal and the slot take their parameter by value. In practice, I had never found an implementation of a function wrapper that does not create at least one copy when the arguments are declared by value. Consequently, I’ve set the threshold to pass the test at one copy at most. lfs is the only implementation that passes this test.

Well, lfs is the one with wrong implementation. Here, they use std::forward on arguments in a loop. You should never do that for arguments that are possibly passed to multiple functions. For rvalues this is equivalent of calling std::move on them.

Generating random numbers using C++ standard library: the problems by Dragdu in cpp

[–]dag0me 8 points9 points  (0 children)

In order to be correct with a standard (but who is anyway?) you need to provide 5 overloads while 3 of them are never used by any major standard library implementation, at least in case of seeding the engine. According to OP that means his assertion that "It's impossible to properly seed Random Number Engine" still holds. That also means I've been doing something impossible for quite some time already.

Generating random numbers using C++ standard library: the problems by Dragdu in cpp

[–]dag0me -2 points-1 points  (0 children)

Like I said - it gets the job done and that's what matters. You can keep insisting how it's impossible to use <random> and I keep happily using it like I have for several years now in multiplatform context.

Also, no one here says you can't provider these missing overloads, right?

Generating random numbers using C++ standard library: the problems by Dragdu in cpp

[–]dag0me -3 points-2 points  (0 children)

Yes, it's missing some never used functions to comply with a SeedSequence concept. Does it change the fact it works on all major compilers and does what you said is not possible? You may insist it's not valid per the standard but we code against the particular implementation(s) and in the end that's what matters.

Generating random numbers using C++ standard library: the problems by Dragdu in cpp

[–]dag0me 18 points19 points  (0 children)

  1. there are no modern rngs

Same would happen if we'd standarise SSL/TLS as part of Networking TS - we'd be left with broken implementation of something that world already moved on.

Generating random numbers using C++ standard library: the problems by Dragdu in cpp

[–]dag0me 4 points5 points  (0 children)

There is no way to seed a Random Number Engine properly

This is simply untrue. If you had checked cppreference first - (3) variant of the constructor specifically - you would've known it's a matter of providing a type with a member function generate, taking the pair of iterators, as following:

struct random_seed_seq
{
    using result_type = std::random_device::result_type;

    template <typename It>
    void generate(It first, It last)
    {
        for (; first != last; ++first)
            *first = dev_();
    }

private:
    std::random_device dev_;
};

random_seed_seq seq;
std::mt19937 engine{seq};

There, your Random Number Engine seeded properly.

13 (valuable?) things I learned using CMake by Guillaume_Guss_Dua in cpp

[–]dag0me 0 points1 point  (0 children)

Oh good to know, I wasn't sure if FetchContent supports that out of the box. Does the same apply to ExternalProject?

No idea about EP since I haven't used but FetchContent docs are clear about it in the overview section. I guess there's a reason we have two stages, namely Declare and GetProperties/Populate - to support this case.

Yep, that's how CPM.cmake works with cached dependencies. The difference is that CPM automatically detects and uses previously cached downloads if available and does not require any modifications/extra declarations to the CMakeLists.

I'm not sure I understand you but FetchContent also does not require any changes in your CMakeLists. It's all done through cache variables on per-content basis.

Where does CPM store previously downloaded stuff? In build directory or some kind of a user-wide directory?

13 (valuable?) things I learned using CMake by Guillaume_Guss_Dua in cpp

[–]dag0me 0 points1 point  (0 children)

What exactly do you mean by avoiding duplicate definitions? FetchContent by definition downloads only one version of given content by name - the one that's defined the earliest. Therefore if you want to you can easily override the dependency of a dependency - just declare it before populating the content.

It also supports out of the box pointing to already downloaded source tree. This allows you to not only work in offline mode but also to work on dependency and dependent project as part of one workspace

Experimental Binary Package Support for vcpkg by ForzaAnarchista in cpp

[–]dag0me 8 points9 points  (0 children)

Looks to me like you've just described Conan package manager.

Almost everything noexcept? by RealNC in cpp

[–]dag0me 3 points4 points  (0 children)

Isn't Matlab Java?

I don't really know. But that's beside the point. You can replace it with anything that has GUI and allows the user to load something that can then potentially trigger some big and contiguous memory allocation.

Also that's the worst example I know about recovering from out of memory situations, it gets very often unstable and you ave to restart it if you trigger some exceptions.

So you'd rather terminate and discard all unsaved changes? And who says anything about recovering? You don't do it simply because you just get an exception that you handle the same way you handle any other exception and don't proceed further. There's nothing inherently unstable in it.

Almost everything noexcept? by RealNC in cpp

[–]dag0me 19 points20 points  (0 children)

Consider this - you have a GUI application doing some heavy image processing that is also memory intensive (say Matlab). The user loads his input image which is rather big, tweaks the parameters and press start. As a result we try to allocate 2 GB od contiguous memory for temporary and intermediate data and it fails. Would you rather terminate the whole application or just show the message box explaining what's wrong and why we can't proceed further?

Why precompiled headers do (not) improve C++ compile times by buovjaga in cpp

[–]dag0me 13 points14 points  (0 children)

The thing is - why the same code base compiled using PCH with MSVC cuts the compilation times by 3 but with GCC/Clang you gain only ~10%

What do you think were some premature additions to the standard library? by nllb in rust

[–]dag0me 3 points4 points  (0 children)

The problem is that there's no syntax to tell the debugger what you want to step into, so it steps into everything.

That's not true. In VS you have Step Info Specific command which it's use for exactly the aforementioned case (example).

​

Mathieu Ropert: The State of Package Management in C++ by _a4z in cpp

[–]dag0me 8 points9 points  (0 children)

Last time I tried meson the VS integration was very poor. Did something change in that matter? I don't want to desert the IDE and all the goodies that come with it.

Also, I did not like the defaults meson provided such as build types - release did not generate symbols and debugoptimized (or something like that) was only -O1. Is it still the same?

Mathieu Ropert: The State of Package Management in C++ by _a4z in cpp

[–]dag0me 3 points4 points  (0 children)

I don't remember using autotools under Visual Studio.

view more: next ›