Readit News logoReadit News
niekb commented on A safe, non-owning C++ pointer class   techblog.rosemanlabs.com/... · Posted by u/niekb
TinkersW · 3 months ago
They never mention std::weak_ptr which makes me think they aren't aware of it.. yes this looks pretty useless and unsafe(isn't everything multi-threaded these days..)
niekb · 3 months ago
> isn't everything multi-threaded these days..

There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".

niekb commented on A safe, non-owning C++ pointer class   techblog.rosemanlabs.com/... · Posted by u/niekb
abstractspoon · 3 months ago
> Extending the design to a thread-safe one is left as an exercise to the reader.

Doesn't get much glibber than that!

niekb · 3 months ago
That was mostly meant as irony/a joke, but I admit that's not really clear from the text... For the sake of clarity, if you need thread-safety, probably best to just use std::shared_ptr / std::weak_ptr.
niekb commented on A safe, non-owning C++ pointer class   techblog.rosemanlabs.com/... · Posted by u/niekb
mwkaufma · 3 months ago
> Note that our use case is in a single-threaded context. Hence, the word safe should not be interpreted as ‘thread-safe.’ Single-threadedness greatly simplifies the design; we need not reason about race conditions such as one where an object is simultaneously moved and accessed on different threads. Extending the design to a thread-safe one is left as an exercise to the reader.

Why intentionally design a worse alternative to std::weak_ptr which has been around since C++11??

niekb · 3 months ago
(Author here.) That is a good question. For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention). However, when I wrote the blog-post, I replaced that not-so-well-known class by std::shared_ptr for the sake of accessibility of the blogpost for a general c++ audience, but by doing so, it indeed becomes a natural question to ask why one wouldn't use std::weak_ptr (which I hadn't realised when writing the post).

One reason why this design can still be beneficial when using the standard std::shared_ptr in its implementation, is when you do not want to manage the pointee object by a std::shared_ptr (which is a requirement if you want to use std::weak_ptr). E.g., if you want to ensure that multiple objects of that type are laid out next to each other in memory, instead of scattered around the heap.

Another goal of the post is to show this idea, namely to use a shared_ptr<T*> (instead of shared_ptr<T>), which is kind of non-standard, but can be (as I hope I convinced you) sometimes useful.

niekb commented on Show HN: Building an End-to-End Encrypted Shazam with Homomorphic Encryption   zama.ai/post/encrypted-sh... · Posted by u/zacchj
niekb · 2 years ago
I'd be curious to the training time (per training example) of the logistic regression model in FHE.
niekb commented on Safety: A comparaison between Rust, C++ and Go   nested.substack.com/p/saf... · Posted by u/ephesee
niekb · 3 years ago
The author could compile c++ with the sanitizers, i.e. -fsanitize=address,undefined and make a make_appender function that leverages perfect forwarding...:

  template<typename S>
  auto make_appender(S&& suffix)
  {
    return [perf_fwd_suffix = std::tuple{std::forward<S>(suffix)}](std::vector<int>&& items)
    {
        return append(std::move(items), std::get<0>(perf_fwd_suffix));
    };
  }
see: https://godbolt.org/z/M9P4MK4a8

niekb commented on Ask HN: Who is hiring? (February 2022)    · Posted by u/whoishiring
niekb · 4 years ago
Roseman Labs | C++ engineer and front-end/UX specialist | Utrecht, The Netherlands (EU work permit required)

We build a software product that enables parties that manage privacy-sensitive data to collaborate and jointly extract insights without having to mutually share the underlying data. Our product is based on secure multiparty computation (MPC), a mature academic subfield of cryptography; MPC is among the most promising privacy enhancing technologies (PETs).

Roseman Labs was founded in March 2020; meanwhile we have a growing customer base and our team consists of 11 people (+ 1 pet).

We are looking for talent to help us further develop the core of this product (C++20 & Computer Science / Math knowledge), as well as intuitive web-based GUIs (JavaScript, Svelte, etc.) tailored to different user roles (privacy officer, data scientist, business owner, etc.).

Core:

- C++20 development on Linux (gcc, clang, concepts, coroutines, etc.)

- asynchronous networking & disk I/O, cooperative multitasking, multi-core

- high performance networking (zero-copy, RSS, ...)

- cryptographic protocols, finite-ring / finite-field arithmetic

- performance benchmarking & optimization

GUI layer:

- Javascript/Typescript

- Svelte

- CSS

- UX

- interaction design

https://www.rosemanlabs.com jobs@rosemanlabs.com

u/niekb

KarmaCake day39August 14, 2015View Original