All perguntas(coding)

Este código compila:

#include <iostream>

class MyClass;

template<typename T>
concept HasFun = requires(T t)
{
    { t.fun() };
};

int main()
{
    std::cout << HasFun<MyClass> << std::endl;
    return 0;
}

sem erro e imprime 0.

Quando

class MyClass;

é substituído por

class MyClass
{
public:
    void fun();
};

ele imprime 1;

Minha expectativa é que a compilação falhe (no primeiro caso) com um erro dizendo algo como "agregado 'MyClass' tem tipo incompleto".

Qual é o caso de uso em permitir que conceitos avaliem declarações de classe?

De acordo com o padrão UUID RFC 4122 , os UUIDs devem ser tratados como unsigned int 128 e a comparação deve ser feita dessa maneira:

Rules for Lexical Equivalence:
      Consider each field of the UUID to be an unsigned integer as shown
      in the table in section Section 4.1.2.  Then, to compare a pair of
      UUIDs, arithmetically compare the corresponding fields from each
      UUID in order of significance and according to their data type.
      Two UUIDs are equal if and only if all the corresponding fields
      are equal.

 UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.

O que significa que println(UUID.fromString("b533260f-6479-4014-a007-818481bd98c6") < UUID.fromString("131f0ada-6b6a-4e75-a6a0-4149958664e3"))deve imprimir falso.

No entanto, é verdade!!

Olhando para a implementação de compareTo (estou usando temurin aqui)

@Override
    public int compareTo(UUID val) {
        // The ordering is intentionally set up so that the UUIDs
        // can simply be numerically compared as two numbers
        int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
        return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);
    }

Para este caso particular, os bits mais significativos são

-5389922481480318956
1377831944219938421

respectivamente. O que significa que a comparação está errada porque o longo transborda.

Meu colega porta um programa C++ com intervalos no macOS e observa um erro de compilação inesperado.

Após a simplificação máxima, o programa de exemplo fica assim:

#include <optional>
#include <algorithm>

int main() {
    std::optional<int> ops[4];
    //...
    return (int)std::ranges::count_if( ops, &std::optional<int>::has_value );
};

O GCC e o MSVC funcionam bem com o programa, mas o Clang exibe um longo erro:

 error: no matching function for call to object of type 'const __count_if::__fn'
    7 |     return (int)std::ranges::count_if( ops, &std::optional<int>::has_value );
      |                 ^~~~~~~~~~~~~~~~~~~~~
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:62:3: note: candidate template ignored: constraints not satisfied [with _Range = std::optional<int> (&)[4], _Proj = identity, _Predicate = bool (std::__optional_storage_base<int>::*)() const noexcept]
   62 |   operator()(_Range&& __r, _Predicate __pred, _Proj __proj = {}) const {
      |   ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:60:13: note: because 'indirect_unary_predicate<_Bool (std::__optional_storage_base<int>::*)() const noexcept, projected<iterator_t<optional<int> (&)[4]>, identity> >' evaluated to false
   60 |             indirect_unary_predicate<projected<iterator_t<_Range>, _Proj>> _Predicate>
      |             ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__iterator/concepts.h:191:60: note: because 'predicate<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, iter_value_t<__type> &>' evaluated to false
  191 |     indirectly_readable<_It> && copy_constructible<_Fp> && predicate<_Fp&, iter_value_t<_It>&> &&
      |                                                            ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/predicate.h:28:21: note: because 'regular_invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false
   28 | concept predicate = regular_invocable<_Fn, _Args...> && __boolean_testable<invoke_result_t<_Fn, _Args...>>;
      |                     ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:34:29: note: because 'invocable<_Bool (std::__optional_storage_base<int>::*&)() const noexcept, std::optional<int> &>' evaluated to false
   34 | concept regular_invocable = invocable<_Fn, _Args...>;
      |                             ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__concepts/invocable.h:28:3: note: because 'std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...)' would be invalid: no matching function for call to 'invoke'
   28 |   std::invoke(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...); // not required to be equality preserving
      |   ^
/opt/compiler-explorer/clang-19.1.0/bin/../include/c++/v1/__algorithm/ranges_count_if.h:54:3: note: candidate function template not viable: requires at least 3 arguments, but 2 were provided
   54 |   operator()(_Iter __first, _Sent __last, _Predicate __pred, _Proj __proj = {}) const {
      |   ^          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Demonstração online: https://gcc.godbolt.org/z/no55zPzGz

Não entendi o que há de errado com o programa?

O seguinte conceito do C++20 - The Complete Guide (adaptado de http://wg21.link/p0870 ), proíbe conversões de estreitamento. Por exemplo, floatpara int, como em 1.9f→ 1.

template <typename From, typename To>
concept ConvertibleWithoutNarrowing = requires (From&& from) {
  { std::type_identity_t<To[]>{std::forward<From>(from)}} -> std::same_as<To[1]>;
};

O livro usa isso para uma coleção C que não deve ter conversões de restrição ao adicionar dados:

template<typename C, typename T>
requires ConvertsWithoutNarrowing<T, typename C::value_type>
void add(C& collection, const T& val) {…}

// Usage:
std::vector<int> vec_i;
add(vec_i, 1); // OK
add(vec_i, 1.3); // Does not compile.

Entendi a ideia geral por trás do conceito, mas o que o [1]na última parte, std::same_as<To[1]>;, faz?

O seguinte é um exemplo de brinquedo

A classe studenttem um std::array<char, 15>chamado namee um inteiro age. Um aluno tem uma função membro chamada encodeque chama uma função de modelo global encodeusando name.size()como parâmetro de modelo.

O código é mostrado abaixo:

//main.cpp
#include <iostream>
#include <array>

template <unsigned long num1>
unsigned long encode(unsigned long num2){
    return num1 + num2;
}


struct student {
    std::array<char, 15> name;
    int age;
    student(const std::array<char, 15>& name, int age):
        name(name),
        age(age)
    {}
    unsigned long encode(){
        return ::encode<name.size()>(age);
    }
};

int main(){
    std::array<char, 15> name = {"Tim"};
    student Tim(name, 17);
    std::cout << Tim.encode();
}

No entanto, isso produz o seguinte erro do compilador

>g++ main.cpp -std=c++11

main.cpp: In member function 'long unsigned int student::encode()':
main.cpp:22:43: error: use of 'this' in a constant expression
   22 |                 return ::encode<name.size()>(age);
      |                                           ^
main.cpp:22:45: error: no matching function for call to 'encode<((student*)this)->student::name.std::array<char, 15>::size()>(int&)'
   22 |                 return ::encode<name.size()>(age);
      |                        ~~~~~~~~~~~~~~~~~~~~~^~~~~
main.cpp:9:15: note: candidate: 'template<long unsigned int num1> long unsigned int encode(long unsigned int)'
    9 | unsigned long encode(unsigned long num2){
      |               ^~~~~~
main.cpp:9:15: note:   template argument deduction/substitution failed:
main.cpp:22:45: error: use of 'this' in a constant expression
   22 |                 return ::encode<name.size()>(age);
      |                        ~~~~~~~~~~~~~~~~~~~~~^~~~~
main.cpp:22:42: note: in template argument for type 'long unsigned int'
   22 |                 return ::encode<name.size()>(age);

É necessário que eu faça isso ::encode<15>(age)para resolver esse problema, porque eu acho que um dos principais benefícios de um std::arrayé poder carregar um tamanho em vez de ter que armazenar o tamanho em alguma variável extra (ou codificar o tamanho).

g++ version: 14.1.0

Modelei uma função que retorna uma instância de um std::expected<void, Error>- eu disse a mim mesmo "Posso usar um novo padrão, então projetarei minha biblioteca de acordo" - e estava muito positivo para ter um tratamento de erro agradável e concreto. Agora acontece que todas as operações monádicas no std::expectedfuncionam apenas em itens não nulos. Embora haja uma especialização para void, as operações monádicas não estão disponíveis. Entendo que or_elseprecisa retornar o valor - mas há uma especialização para void, então por que isso não deveria funcionar ?

std::expected<void, Error> fun (int);

fun (19).and_then ([]() { doSomething(); }).or_else ([] (Error e) { std::println ("Uh oh error.."); });

Isso produz:

/usr/include/c++/14.2.1/expected:1586:37: error: static assertion failed
 1586 |           static_assert(__expected::__is_expected<_Up>);
      |                         ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
/usr/include/c++/14.2.1/expected:1586:37: note: ‘std::__expected::__is_expected<void>’ evaluates to false
/usr/include/c++/14.2.1/expected:1587:25: error: ‘std::remove_cvref<void>::type’ {aka ‘void’} is not a class, struct, or union type
 1587 |           static_assert(is_same_v<typename _Up::error_type, _Er>);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/14.2.1/expected:1592:20: error: expression list treated as compound expression in functional cast [-fpermissive]
 1592 |             return _Up(unexpect, std::move(_M_unex));
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/david/tests/cpp/src/expect.cpp: In function ‘int main()’:
/home/david/tests/cpp/src/expect.cpp:49:26: error: invalid use of ‘void’

Qual é o problema aqui? Esse recurso está apenas pela metade (então o padrão está incompleto) ou estou entendendo mal seu ponto?

Precisamos separar alocação e inicialização de algum armazenamento de heap. Infelizmente, o código do cliente usa delete p;para excluir o ponteiro. Se tivéssemos controle da exclusão, poderíamos alocar com ::operator new (sizeof(T), std::align_val_t(alignof(T)))e então usar posicionamento newe o global correspondente ::operator delete. Mas (se entendi corretamente) deletepode chamar T::operator delete, potencialmente exigindo uma alocação que veio de T::operator new, com uma ordem de preferência complicada entre os diferentes argumentos possíveis para T::operator newe T::operator deletese houver múltiplas sobrecargas.

Existe algo assim std::allocate_as_if_by_new<T>()que fará exatamente a mesma alocação que new T(...)eu faria, mas sem inicializar, ou pelo menos garantirá que (após a inicialização) delete p;irá desalocá-la corretamente?

Vamos supor que eu tenha o seguinte código ( https://godbolt.org/z/MW4ETf7a8 ):

Xh

#include <iostream>

struct X{
    void* operator new(std::size_t size)
    {
        std::cout << "new X\n";
        return malloc(size);
    }

    void operator delete(void* ptr)
    {
        std::cout << "delete X\n";
        return free(ptr);
    }

    virtual ~X() = default;
};

struct ArenaAllocatedX : public X {
    void* operator new(std::size_t size)
    {
        std::cout << "new ArenaAllocatedX\n";
        return malloc(size);
    }

    void operator delete(void* ptr)
    {
        std::cout << "delete ArenaAllocatedX\n";
        return free(ptr);
    }
};

principal.cpp

int main() {
    X* x1 = new X();
    delete x1;

    X* x2 = new ArenaAllocatedX ();
    delete x2;    
}

Usando o GCC 10.3.1, x1chama os operadores newe de , enquanto chama de .deleteclass Xx2class ArenaAllocatedX

Eu entendo como ele pegará o newoperador, já que ele tem o nome real da classe à sua direita, mas não entendo como o deleteoperador é escolhido para a subclasse enquanto é apontado por X*.

Os operadores new/ são deleteconsiderados funções dentro da tabela virtual (descartei o VTable usando gcc -f-dump-lang-classe ainda não vejo nenhum operador de exclusão)?

Os despejos do VTable:

Vtable for X
X::_ZTV1X: 4 entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI1X)
16    (int (*)(...))X::~X
24    (int (*)(...))X::~X

Class X
   size=8 align=8
   base size=8 base align=8
X (0x0x7f38cd807780) 0 nearly-empty
    vptr=((& X::_ZTV1X) + 16)

Vtable for ArenaAllocatedX
ArenaAllocatedX::_ZTV15ArenaAllocatedX: 4 entries
0     (int (*)(...))0
8     (int (*)(...))(& _ZTI15ArenaAllocatedX)
16    (int (*)(...))ArenaAllocatedX::~ArenaAllocatedX
24    (int (*)(...))ArenaAllocatedX::~ArenaAllocatedX

Class ArenaAllocatedX
   size=8 align=8
   base size=8 base align=8
ArenaAllocatedX (0x0x7f38cd848680) 0 nearly-empty
    vptr=((& ArenaAllocatedX::_ZTV15ArenaAllocatedX) + 16)
X (0x0x7f38cd807cc0) 0 nearly-empty
      primary-for ArenaAllocatedX (0x0x7f38cd848680)

Como o C++ escolhe qual deleteoperador usar no código fornecido?

Não acredito que SortedSet.IsSubsetOfesteja funcionando como esperado. Dado este código, não deveria ss.IsSubsetOf(l)retornar True?

Suspeito que o problema esteja na minha CompareTofunção, mas não consigo ver o problema.

Também adicionei um loop separado pensando que o conjunto deveria ser encontrado classificado dentro de otherIEnumerable . . . mas isso também não funciona.

Alguém pode explicar por que esse comportamento está acontecendo?

List<Point> l = new();
SortedSet<Point> ss = new();
HashSet<Point> h = new();

for (int i = 0; i < 100; i++)
{
    var p = new Point(i, i);
    l.Add(p);
    l.Add(p);
    h.Add(p);
    h.Add(p);
    ss.Add(p);
    ss.Add(p);
}

// additional loop to get a sorted set.
for (int i = 0; i < 100; i++)
{
    l.Add(new Point(i, i));
}

Console.WriteLine(l.Count); // 300
Console.WriteLine(h.Count); // 100
Console.WriteLine(ss.Count); // 100
Console.WriteLine(h.IsSubsetOf(l));  // True (as expected)
Console.WriteLine(h.IsProperSubsetOf(l)); // False

// This is the line in question
Console.WriteLine(ss.IsSubsetOf(l)); // False ?????????

Console.WriteLine(ss.IsProperSubsetOf(l)); // False

readonly struct Point : IComparable<Point>, IEquatable<Point>
{
    public Point(double x, double y)
    {
        X = x;
        Y = y;
    }

    public double X { get; }
    public double Y { get; }

    public int CompareTo(Point other)
    {
        if (X == other.X)
        {
            return Y.CompareTo(other.Y);
        }
        else
        {
            return X.CompareTo(other.X);
        }
    }

    public bool Equals(Point other)
    {
        return X == other.X && Y == other.Y;
    }

    public override int GetHashCode()
    {
        return HashCode.Combine(X, Y);
    }
}

Em um microcontrolador, para evitar o carregamento de configurações de uma versão anterior do firmware, também armazeno o tempo de compilação, que é verificado no carregamento.

O projeto do microcontrolador é construído com 'mikroC PRO for ARM' da MikroElektronika .

Para ser mais fácil de depurar, programei o código com minGW no meu PC e, após verificar à esquerda e à direita, coloquei-o no microC.

O código que usou essa verificação não funcionou corretamente. Depois de uma noite de depuração frustrante, descobri sizeof("...")que produzia valores diferentes nas duas plataformas e, como consequência, causava um estouro de buffer.

Mas agora não sei de quem é a culpa.

Para recriar o problema, use o seguinte código:

#define SAVEFILECHECK_COMPILE_DATE __DATE__ " " __TIME__

char strA[sizeof(SAVEFILECHECK_COMPILE_DATE)];
char strB[] = SAVEFILECHECK_COMPILE_DATE;

printf("sizeof(#def): %d\n", (int)sizeof(SAVEFILECHECK_COMPILE_DATE));
printf("sizeof(strA): %d\n", (int)sizeof(strA));
printf("sizeof(strB): %d\n", (int)sizeof(strB));

No MinGW ele retorna (conforme esperado):

sizeof(#def): 21
sizeof(strA): 21
sizeof(strB): 21

Porém, no 'mikroC PRO for ARM' ele retorna:

sizeof(#def): 20
sizeof(strA): 20
sizeof(strB): 21

Essa diferença causou um estouro de buffer na linha (sobrescrevendo o byte zero de um ponteiro – ai).

21 é a resposta que espero: 20 caracteres e o terminador '\0'.

Esta é uma das coisas que 'depende' em C ou há uma violação do sizeofcomportamento do operador?