Some way to support an a handler for `BOOST_ASSERT(_MSG)` that takes a `std::source_location`
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- cpp
- Ambito
- testing-qa
Direzione di ricerca
Inizia esaminando l’API dell’handler BOOST_ASSERT esistente e il modo in cui viene espanso BOOST_ASSERT(_MSG). Confronta l’opzione proposta per l’handler con std::source_location con le macro personalizzabili BOOST_ASSERT_FAILURE_HANDLER() e BOOST_ASSERT_MSG_FAILURE_HANDLER(). Il lavoro è completato quando sono disponibili un design dell’API approvato da un maintainer e il relativo ambito di implementazione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem: Using std::source_location is more efficient than passing separate file/line/column/func info because the location is a single pointer to static storage, rather than 2 pointer + 2 const ints. That can result in codegen bloat, especially on platforms like Aarch64 where it takes multiple instructions to load a global pointer. Given the usecase of assertions, this is often used for very cold (hopefully never executed!) code that sits in the same function as hot code, so you often want to make it as small as possible to maximize icache and iTLB. Note that it is important to use source_location from std:: rather than boost:: because the std:: flavor uses implementation techniques that are not available to userspace C++ to make it a single pointer to static storage.
Possible solution 1: Add a new macro like BOOST_ENABLE_ASSERT_HANDLER_WITH_STD_SOURCE_LOCATION to opt into a different handler API that takes std::source_location.
Possible solution 2: Give the user full control over the handler expression by just making the failure case be a macro call like BOOST_ASSERT_FAILURE_HANDLER() and BOOST_ASSERT_MSG_FAILURE_HANDLER(msg). The only tricky issue is that you would likely need some way to inject declarations and #includes into global scope, but it may be reasonable to say that anyone who can use this facility correctly can probably also use -include "my_boost_assert_prefix_header.h". This option also has the advantage for anyone who wants to use __builtin_trap() to get the ultimate code size reduction, while still checking asserts.
- Lingua principale
- C++
- Stelle
- 35
- Fork
- 77
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di boostorg/assert
-
Slow cmake glob checks Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
Tutte le issue di boostorg/assert
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
ros2/message_filters#338 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
subsurface/subsurface#4984 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
google-ai-edge/LiteRT-LM#3739 ·