Damir Tenishev's questions

Por que não posso (re)atribuir o valor para uma visualização com o mesmo tipo de visualização?

Demonstração: https://godbolt.org/z/aqdh7ohva

#include <iostream>
#include <ranges>
#include <vector>

int main()
{
    std::vector<int> v = { 0, 1, 2, 3, 4, 5, 6 };

    const bool strategy_check_for_zero = true;

    auto selected = v | std::views::filter([=](const auto& v) { return !strategy_check_for_zero || v != 0; });

    // Impossible to do; why?
    selected = v | std::views::filter([=](const auto& v) { return true; });

    std::ranges::copy(selected, std::ostream_iterator<int>{std::cout, ", "});
    std::cout << '\n';
}

Bem, em código real, é mais ou menos assim:

auto selected = v | std::views::filter([=](const auto& v) { return !strategy_check_for_zero || v != 0; });

if (selected.empty()) {
    selected = v | std::views::filter([=](const auto& v) { return true; });
}

Quero manter o código em questão o mais simples possível.

Como posso mapear dados de estrutura aninhados com std::views::transform?

No código abaixo, a transformação as_v1funciona perfeitamente e permite copiar os dados.

Como posso fazer o mesmo para os dados na estrutura aninhada NS?

#include <algorithm>
#include <iostream>
#include <ranges>
#include <vector>

struct S
{
    float v1;
    float v2;

    struct SN {
        float v3;
    };

    SN sn;
};

int main() {
    std::vector<S> aos{ { 1.0f, 2.0f, { 3.0f } } };
    std::vector<float> soa(aos.size());

    // Would work just fine for the:
    // auto as_v1 = aos | std::views::transform(&S::v1);

    // How could I manage a nested structure's member:
    // This, of course, doesn't compile because of types inconsistency
    auto as_v3 = aos | std::views::transform(offsetof(S, sn.v3));

    std::ranges::copy(as_v3, soa.begin());
    std::cout << "soa value:" << soa[0] << std::endl;
}

Entendo que S::SN::v3 não funcionará, pois precisamos do deslocamento do membro e ele será relativo ao snobjeto, e parece que isso offsetofdeve resolver o problema, mas não consigo descobrir como fazer a conversão de tipos.

É possível?

Demonstração

Quero que meu modelo aceite lambdas com diferentes números de parâmetros e seja capaz de lidar com eles.

No código abaixo, o template processpega o objeto callable (função), mas não sabe se o lambda passado pega argumentos ou não. Posso de alguma forma verificar isso no template e fazer a respectiva chamada?

void process(auto fn) {
    [[maybe_unused]] float res = fn(2.0f);

    // Is there a chance to make something like:
    // float res = takes-no-args<fn>() ? fn() : fn(2.0f);

    // do something with res...
}

int main() {
    // This is the default usage
    process([](float arg) { return arg; });

    // I want to be able to make such a call
    process([]() { return 1.0f; });

    // Possible, but verbose workaround
    process([](float) { return 1.0f; });
}

Demonstração

Uma solução alternativa simples seria sempre passar o lambda com a mesma assinatura e ignorar o argumento fornecido, mas isso é muito prolixo no caso de muitos argumentos.

O objetivo é manter o código do cliente o mais simples e limpo possível.

No código abaixo, eu poderia usar a sintaxe conveniente de std::ranges::transformpara copiar valores de array de estruturas (AoS) para estrutura de arrays (SoA) (neste exemplo, apenas um vetor). Existe uma maneira de fazer o mesmo de forma oposta, copiando dados de um campo específico de estrutura quando eu preciso copiar valores de SoA para AoS?

Especificamente, existe uma maneira de substituir o for-loop no código abaixo por alguma chamada de algoritmo (intervalos de visualizações seriam preferíveis)?

#include <algorithm>
#include <iostream>
#include <ranges>
#include <vector>

struct S
{
    float v1;
    float v2;
};

int main() {
    std::vector<S> aos = { { 1.0f, 2.0f } };
    std::vector<float> soa(aos.size());

    std::ranges::transform(aos, soa.begin(), &S::v1);

    std::cout << "soa value:" << soa[0] << std::endl;

    soa[0] = 3.0;

    // I want to replace this with something transform-like above
    for (std::size_t i = 0; i < soa.size(); ++i)
    {
        aos[i].v1 = soa[i];
    }

    std::cout << "aos value:" << aos[0].v1 << std::endl;
}

Demonstração

Por que o mesmo código abaixo compila bem com CLang e não compila com MSVC?

#include <iostream>

const char * NumberToText(int val)
{
    return (const char *[]) {
        "Zero",
        "One",
        "Two", 
    }[val];
}

int main()
{
    std::cout << NumberToText(2);
}

Aqui está a demonstração .

E o MSVC dá o erro:

(5): erro C4576: um tipo entre parênteses seguido por uma lista de inicializadores é uma sintaxe de conversão de tipo explícita não padrão

Ao mesmo tempo, o CLang compila e executa isso muito bem.

No erro C4576 no VS2015 Enterprise, vejo algumas ideias de que isso ocorre porque esse é um recurso da linguagem C e está malformado em C++, mas por que o CLang compila isso então?

Posso manter o array anônimo e ainda obter o mesmo resultado no MSVC C++?

O código abaixo:

#include <sstream>

int main() 
{
    std::istringstream iss{"\x{01}"};
}

Compila bem com CLang e GCC e não compila com MSVC (veja a demonstração ).

O que essa sintaxe significa para os dois primeiros compiladores (não consigo encontrar no padrão) e por que ela não funciona na versão recente do MSVC?

Processando grandes quantidades de dados (gigabytes) uso índices para matrizes de dados. Como o acesso aos dados pode levar à ineficiência do cache, quero armazenar em cache alguns dados do array junto com o índice, o que proporciona uma aceleração drástica para operações por meio de índices.

A quantidade de dados armazenados em cache é uma escolha em tempo de compilação que deve incluir quantidade zero de dados em cache. Tenho uma grande quantidade de índices, então neste caso não quero pagar por elementos “vazios” extras como std::arrayacontece, por exemplo.

Então, fiz um template com especialização:

using index_t = unsigned int;
using lexem_t = unsigned int;

template <std::size_t t_arg_cache_line_size>
struct lexem_index_with_cache_t {
    index_t index;
    std::array<lexem_t, t_arg_cache_line_size> cache_line;

    constexpr std::size_t cache_line_size() const {
        return t_arg_cache_line_size;
    }
};

template<>
struct lexem_index_with_cache_t<0> {
    index_t index;
    static std::array<lexem_t, 0> cache_line;

    constexpr std::size_t cache_line_size() const {
        return 0;
    }
};

std::array<lexem_t, 0> lexem_index_with_cache_t<0>::cache_line;

O problema é esse “hack” que usei na especialização com tamanho zero que utiliza membro estático para dar acesso formal ao cache_linewhile está vazio e o acesso não é realmente necessário. Isso me permite evitar especializações em funções que utilizam este modelo, como aqui:

using lexem_index_with_cache = lexem_index_with_cache_t<0>;

template <typename T>
class seq_forward_comparator_cached
{
    const std::vector<T>& vec;
public:
    seq_forward_comparator_cached(const std::vector<T>& vec) : vec(vec) { }

    bool operator() (const lexem_index_with_cache& idx1, const lexem_index_with_cache& idx2)
    {
        if (idx1.index == idx2.index) {
            return false;
        }

        const auto it1_cache_line = idx1.cache_line;  // This code wouldn’t compile in absence of static “hack”
        const auto it2_cache_line = idx2.cache_line;  // This code wouldn’t compile in absence of static “hack”

        auto res = std::lexicographical_compare_three_way(
            it1_cache_line.begin(), it1_cache_line.end(),
            it2_cache_line.begin(), it2_cache_line.end());

        if (res == std::strong_ordering::equal) {
            auto range1 = std::ranges::subrange(vec.begin() + idx1.index + idx1.cache_line_size(), vec.end());
            auto range2 = std::ranges::subrange(vec.begin() + idx2.index + idx2.cache_line_size(), vec.end());

            return std::ranges::lexicographical_compare(range1, range2);
        }

        return res == std::strong_ordering::less;
    }
};

Claro, posso implementar outra especialização de modelo deste modelo para cache de tamanho zero, mas isso levará à duplicação de código e tenho muitas dessas funções, então não quero especializar todas elas.

staticPor outro lado, qual é a maneira adequada no C++ moderno de evitar esse hack e possível duplicação de código?

Não tenho certeza, talvez algum tipo de código condicional incluído dependendo do tipo possa ajudar.

Eu gostaria de evitar o acesso a cache_lineuma função, mas se esse for o único caso, dê uma pista sobre a abordagem.

O código compilável está aqui .

Com o código abaixo

#include <algorithm>
#include <vector>

bool MyComparator(const int lhs, const int rhs) {
    // More logic included here
    return lhs < rhs;
}

template <typename T, typename Comp = std::less<T>>
class seq_forward_comparator
{
    const std::vector<T>& vec;
    const Comp& comp;
public:
    static const std::size_t npos = ((std::size_t)-1);

    seq_forward_comparator(const std::vector<T>& vec, const Comp& comp = {}) : vec(vec), comp(comp) { }

    bool operator() (int idx1, int idx2)
    {
        // More logic here
        return std::ranges::lexicographical_compare(vec.begin()+idx1,vec.end(), vec.begin() + idx2, vec.end(), comp);
    }
};

int main() {
    std::vector<int> vec = { 1, 2, 3, 4 };

    seq_forward_comparator<int, decltype(MyComparator)> less2(vec, MyComparator);

    seq_forward_comparator<int> less1(vec);

}

No MSVC++ estou recebendo avisos:

<source>(13): warning C4180: qualifier applied to function type has no meaning; ignored
<source>(13): note: the template instantiation context (the oldest one first) is
<source>(29): note: see reference to class template instantiation 'seq_forward_comparator<int,bool (int,int)>' being compiled
<source>(17): warning C4180: qualifier applied to function type has no meaning; ignored

enquanto CLang não emite aviso.

Caso eu substitua

    seq_forward_comparator<int, decltype(MyComparator)> less2(vec, MyComparator);

com

    seq_forward_comparator<int, decltype(MyComparator)*> less2(vec, MyComparator);

MSVC++ 2022 para de avisar.

Isso é falso-positivo?

Caso contrário, qual problema potencial são os sinais, exceto "excessivos" conste de que maneira mudar o tipo de função (que é um ponteiro para uma função, de qualquer maneira) para um ponteiro para uma função resolve isso?

Em caso afirmativo, qual seria a melhor maneira de evitá-lo, exceto suprimir o aviso e passar um ponteiro explícito para a função?

Atualizar

É claro que a solução com a substituição decltype(MyComparator)de decltype(MyComparator)*está errada ou, neste caso, pelo menos o ponteiro para a função deve ser passado como um predicado, como afirma este tipo.

Qual é a razão específica pela qual ambos std::sorte std::ranges::sortlevam ao contexto subjacente de std::stringcópia durante a classificação, enquanto std::swapapenas trocam os ponteiros no std::string?

Veja a demonstração com os endereços:

#include <algorithm>
#include <iostream>
#include <string>
#include <vector>

int main()
{
    std::vector<std::string> arr = { "You", "HereIJustWantToHaveMemoryReallocation", "See" };

    std::cout << "\nBefore sorting:";

    for (auto& s : arr) {
        std::cout << "\nString:" << s << " at " << std::addressof(s) << " points to " << (void*)(s.c_str());
    }

    std::sort(arr.begin(), arr.end());

    std::cout << "\nAfter sorting:";
    for (auto& s : arr) {
        std::cout << "\nString:" << s << " at " << std::addressof(s) << " points to " << (void*)(s.c_str());
    }
}

A questão não é como evitar isso, o que pode ser feito facilmente, por exemplo, com std::string_view. A questão é: por que agir std::sorte std::ranges::sortse comportar dessa maneira?

Eu esperaria que o algoritmo de classificação usasse std::swapalgum tipo de semântica de movimento que permitiria std::stringapenas trocar ponteiros para as strings subjacentes, sem tocar nas próprias strings. Por que não é esse o caso?

Se eu quiser tornar a classe TopNStorage parametrizável com predicado de comparação, tenho que fazer algo como:

#include <algorithm>
#include <iostream>
#include <queue>
#include <vector>

template <typename T, typename Pred = std::greater<T>>
class TopNStorage {
    std::priority_queue<T, std::vector<T>, Pred> counts;
    size_t n;
public: 
    TopNStorage(size_t n) : n(n) {  }

    void add(T value) {
        if (counts.size() >= n) {
            if (Pred()(value, counts.top())) {
                counts.pop();
                counts.push(value);
            }
        }
        else {
            counts.push(value);
        }
    }

    auto get_values() const { 
        std::vector<T> sorted_collocations_counts(counts.size());

        std::copy(&(counts.top()), &(counts.top()) + counts.size(), sorted_collocations_counts.begin());
        std::sort(sorted_collocations_counts.begin(), sorted_collocations_counts.end(),Compare());

        return sorted_collocations_counts;
    }
};

int main() {
    TopNStorage<int,std::less<int>> storage(3);

    for (int i = 1; i <= 5; ++i) {
        storage.add(i);
    }

    for (auto value : storage.get_values()) {
        std::cout << value << "\n";
    }
} 

Embora isso seja totalmente aceitável, o inttipo std::less<int>parece ser redundante nesses casos e eu gostaria de dizer ao compilador para retirá-lo typename Tda classe, mas não sei se posso parametrizar o modelo com outro modelo. Existe uma maneira de fazer o código do cliente parecer:

TopNStorage<int,std::less> storage(3);

Motivação

Não gosto de duplicação e quero evitar situações em que um tipo possa ser alterado sem alterar o outro (quando se trata de tipos e códigos mais complicados).

Fundo

Com base na pergunta Mantendo os N valores principais .

Eu costumava escrever código de uma forma que pudesse ser lido em inglês simples.

Alguém pode dar uma pista de como é melhor ler o código abaixo nesses termos?

Meu problema é que o código abaixo diz “apagar todos os elementos únicos”, mas faz exatamente o oposto.

Esta não é uma sugestão para retrabalhar STL e intervalos de alguma forma, apenas estou curioso sobre algum truque para considerar/tratar std::unique(e alguns outros métodos) neste contexto para tornar este texto menos contra-intuitivo.

Na ausência de “não” no código abaixo (o que poderia ajudar a ler como “não exclusivo” ou “exceto exclusivo”) qual seria a melhor maneira de ler este código?

std::vector<T> v = …;
std::sort(v.begin(), v.end());
v.erase(std::unique(v.begin(), v.end()), v.end());

A versão Ranges não é melhor nestes termos:

std::vector<T> v = …;
std::ranges::sort(v);
v.erase(std::ranges::unique(v), v.end());

Em um aplicativo multithreading, dois ou mais threads paralelos usam um ponteiro para chamar uma função virtual. Ao mesmo tempo, em outro thread, esse ponteiro muda para outro objeto. Isso é seguro ou devo tomar medidas para torná-lo seguro?

Considere o código:

class Scene {
public:
  virtual void render() const = 0;
  virtual void update() const = 0;
};

class D1: public Scene {
    // members
public:
  virtual void render() const { /* work with D1 members */ }
  virtual void update() const { /* work with D1 members */ }
};

class D2: public Scene {
    // members
public:
  virtual void render() const { /* work with D2 members */ }
  virtual void update() const { /* work with D2 members */ }
};
// …somewhere in thread 1
Scene *scene=new D1;
…
Scene *scene=new D2;
// … somewhere in thread 2
scene->render();
// … somewhere in thread 3
scene->update();

Por que considero arriscado

Se a chamada de função virtual não for uma operação atômica, posso imaginar a situação em que o compilador leva o ponteiro para o objeto (para ser passado implicitamente é this ) em uma etapa e se refere à chamada de função virtual em outra etapa, lendo novamente esse ponteiro da memória . Entre essas etapas o ponteiro pode ser alterado em outro thread e isso pode acabar com o método D2::render chamado para o objeto D1.

Eu nem tenho certeza de que tornar esse ponteiro volátil ajudaria o compilador a corrigir isso, já que é uma chance de o compilador usar essa dica para outros propósitos.

Minha solução simples

Uma solução simples para isso seria usar uma cópia intermediária:

// … somewhere in thread 2
Scene* safe_copy_scene = scene;
safe_copy_scene->render();

A questão é: é necessário ou a chamada de função virtual pode ser considerada atômica nesta perspectiva e isso é garantido por padrão e não depende de compilador/otimização?

Por que esse código não compila com uma mensagem de erro?

#include <initializer_list>
    
int main() {
    auto [a, b] = { 1, 2 };
}

erro: não é possível decompor o membro inacessível 'std::initializer_list<int>::_M_array' de 'std::initializer_list<int>'

Demonstração

Mas esse código compila e funciona bem?

#include <utility>
    
int main() {
    auto [a, b] = std::make_pair(1, 2);
}

O que há de tão específico em uma lista de inicializadores que torna seus membros inacessíveis?

Existe algum tipo de suposição de que uma lista de inicializadores cria um objeto (de uma classe) com campos privados (ou mesmo "estrutura interna inacessível") ou há algo mais em jogo?

Por questões de legibilidade, evito o uso de std::pair para código complexo para manter os nomes das variáveis ​​significativos.

Levando em consideração que std::equal_range retorna o std::pairnúmero de iteradores, é eficaz e seguro usar ligação estruturada para descompactar os iteradores desta forma:

Em vez de

auto it_lower = std::lower_bound(my_array.begin(), my_array.end(), val, comparator);
auto it_upper = std::upper_bound(my_array.begin(), my_array.end(), val, comparator);

usar

auto [it_lower, it_upper] = std::equal_range(my_array.begin(), my_array.end(), val, comparator);

abordagem?

Esquecendo-se de possíveis implementações diferentes de equal_rangee lower_bound/ upper_boundpar (desempenho diferente, etc.) e focando apenas no uso de pacotes estruturados, isso é igual tanto em termos de representação no código compilado quanto em desempenho? Não estou perguntando o que o compilador fará. Minha pergunta é apenas: se eu usar a ferramenta corretamente e posso esperar resultados semelhantes? Ou há alguma diferença ou, pior ainda, armadilhas?

Sinto falta de alguma coisa ou está perfeitamente bem?

Tenho duas unidades de compilação separadas sem arquivos de cabeçalho:

Unidade a.cpp:

#include <algorithm>
#include <vector>
class my_predicate
{
    const std::vector<int>& vec;
public:
    my_predicate(const std::vector<int>& container) : vec(container) { }

    bool operator() (size_t idx1, size_t idx2)
    {
        return vec[idx1] < vec[idx2];
    }
};

int main()
{
    std::vector<int> v1,v2;
    v1.resize(10);
    v2.resize(10);

    std::sort(v1.begin(), v1.end(), my_predicate(v2));
}

Unidade b.cpp:

#include <algorithm>
#include <vector>

class my_predicate
{
    const std::vector<char>& vec;
public:
    my_predicate(const std::vector<char>& container) : vec(container) { }

    bool operator() (size_t idx1, size_t idx2)
    {
        std::cout << "Why the operator from b.cpp is called?" << std::endl;
        return vec[idx1] < vec[idx2];
    }
};

void bar()
{
    std::vector<char> v1, v2;

    std::sort(v1.begin(), v1.end(), my_predicate(v2));
}

A principal diferença na my_predicateimplementação é o tipo de contêiner usado: vector<int>e vector<char>.

Formalmente, a unidade a.cpp não deve saber nada sobre a classe my_predicateda unidade b.cpp.

Coisas estranhas começam quando sortin main from a.cpp é executado:

1. Ele chama o construtor correto my_predicateem a.cpp
2. E então , para classificação, de repente começa a ligar operator()de my_predicateb.cpp que ele não deve saber.

Isso também é reproduzido no modo de depuração, portanto, a otimização de todo o programa está desativada aqui.

Estou faltando alguma coisa e agora as definições de classe são visíveis globalmente ou isso é um bug do compilador?

A mágica acontece apenas se eu tiver uma chamada fictícia my_predicateem b.cpp (consulte a barra de funções fictícias não utilizadas em b.cpp).

Como bônus, se eu tentar renomear my_predicateem a.cpp com a ferramenta VS Rename (Ctrl+R,Ctrl+R), ele oferece renomeá-lo em ambos os arquivos.