All perguntas(coding)

Tenho um código que simplifiquei para isto:

#include <iostream>
#include <string>


enum En
{
    one,
    two,
    three
};

auto get_str(int n, En en)
{
    if (n > 0)
    {
        return std::to_string(n);
    }

    switch (en)
    {
        case one:
            return std::string("one");
        case two:
            return std::string("two");
        case three:
            return std::string("three");
    }
}

int main()
{
    auto str = get_str(3, two);
    std::cout << str << '\n';
}

Veja no explorador do compilador .

Quando compilo com GCC 14.2 ou 13.3.0 (com ou sem -Wall -Wextra), ele reclama da get_strfunção: warning: control reaches end of non-void function [-Wreturn-type].

O Clang 15.0 e superior -Wall -Wextranão emite nenhum aviso. O VS17.10 também reclama: warning C4715: 'get_str': not all control paths return a value.

O que faz com que Clang discorde? Qual é o caminho que ignora returns?

Quero que o usuário consiga passar a struct e instanciá-la sem uma função construtora, mas não consiga modificar os campos da estrutura sem usar os métodos setter fornecidos na implementação. Isso é possível em Rust sem envolver a estrutura em uma estrutura imutável como Arc/Rc?

Não quero usar um método construtor porque, se a estrutura que está sendo construída tiver muitos campos, parece muito mais limpo para mim (e para o rustfmt clippy linter ) poder ver quais valores estão sendo definidos para campos de estrutura específicos na instanciação. Também evita digitar os argumentos fora de ordem, o que pode ser um problema muito maior se você tiver 2 do mesmo tipo de parâmetro um ao lado do outro nos argumentos.

Eu também preferiria não usar pub(crate)porque isso ainda deixa a possibilidade de um mantenedor acessar o campo fora de um método de implementação.

mod foo {
    pub struct Foo { // Struct is public
        bar: usize // Field is private.
    }

    impl Foo {
        // This is the only way I want to allow the user to modify `bar`. I
        // explicitly do not want to allow them to directly access struct
        // fields such as `let baz = foo.bar` or `foo.bar = 1` from down below.
        pub fn set_bar(&mut self, bar: usize) {
            self.bar = bar;
        }
    }
}

fn main() {
    let mut foo = foo::Foo {
        bar: 0 // ! Compilation fails here because this field is private.
    };
    // I want this to continue to fail to compile.
    foo.bar = 1;
    // But I want this to succeed.
    foo.set_bar(1)
}

Desculpas se isso for uma duplicata. Procurei por perguntas de instanciação de construtor relacionadas a campos privados e não consegui encontrar nenhuma que lidasse com isso especificamente. O mais próximo é este post de Alika97 , mas não necessariamente lidava com um grande número de campos (e, portanto, parâmetros de função).

Se construir uma estrutura pública com campos privados fora do módulo não for possível/viável, qual é a melhor solução do que um construtor com muitos parâmetros, ou essa é minha única opção se eu não quiser que os campos sejam públicos (mesmo dentro da caixa)?

Tenho um problema estranho com o posicionamento ImageViewde s em a Sceneno JavaFX.

Quero que três imagens do mesmo tamanho (200 x 200) apareçam uma ao lado da outra na mesma altura. Então, especifico o mesmo valor em setTranslateY()para cada imagem. Mas, por algum motivo, elas aparecem em alturas diferentes: Cada imagem seguinte parece 200 pixels mais baixa que a anterior.

Aqui está o código:

public class Main extends Application {

    @Override
    public void start(Stage myStage) throws IOException {
        myStage.setTitle("title");
        myStage.setScene(getScene());
        stage = myStage;
        myStage.show();
    }

    public static void main(String[] args) {
        launch();
    }

    private Scene getScene() {
        List<Node> nodes = new ArrayList<>();
        Image i1 = loadFromPath("... some path");
        Image i2 = loadFromPath("... some other path");
        Image i3 = loadFromPath("... again some other path");
        ImageView v1 = new ImageView(i1);
        ImageView v2 = new ImageView(i2);
        ImageView v3 = new ImageView(i3);
        v1.setTranslateX(100);
        v1.setTranslateY(100);
        v2.setTranslateX(320);
        v2.setTranslateY(100);
        v3.setTranslateX(540);
        v3.setTranslateY(100);
        nodes.add(v1);
        nodes.add(v2);
        nodes.add(v3);
        VBox box = new VBox(nodes.toArray(new Node[0]));
        box.setMinWidth(800);
        box.setMaxWidth(800);
        box.setMinHeight(400);
        box.setMaxHeight(400);

        return new Scene(box);
    }

    private Image loadFromPath(String path) {
        FileInputStream input = null;
        try {
            input = new FileInputStream(path);
        } catch (FileNotFoundException e) {
            throw new RuntimeException(e);
        }
        return new Image(input);
    }
}

O resultado fica assim:

Quando uso setLayoutX()and setLayoutY()em vez de setTranslateX()and setTranslateY(), o resultado é ainda pior:

Alguém pode explicar esse resultado?

Digamos que eu tenha a seguinte tabela acima. Gostaria de criar um índice para ajudar a acelerar minhas consultas.

Todas as consultas devem ser do tipo:

Select *
from users
where Type = 'SomeType'
  and First = 'SomeName1'
Order by CreatedAt DESC;

Select *
from users
where Type = 'SomeType'
  and Middle = 'SomeName2'
Order by CreatedAt DESC;

Select *
from users
where Type = 'SomeType'
  and Last = 'SomeName3'
Order by CreatedAt DESC;

Como eu indexaria as colunas para tornar as consultas eficientes? Seria CreatedAta primeira da coluna indexada?

Estou pensando

CREATE INDEX idx_users on users(CreatedAt, Type, First, Middle, Last)

CreatedAte typesempre seria usado, enquanto primeiro, meio e último variam.

No GCC 15, std::noop_coroutinea definição de é

{ return std::noop_coroutine_handle(); }

std::noop_coroutine_handleé definido por:

using noop_coroutine_handle = std::coroutine_handle<std::noop_coroutine_promise>;

Para obter uma corrotina sem operação, escrevemos

std::noop_coroutine()

que (eu acho) é equivalente a

std::noop_coroutine_handle{}

e

std::coroutine_handle<std::noop_coroutine_promise>{}

Então acredito que a biblioteca padrão só precisa fornecer std::noop_coroutine_promise(junto com certas especializações que a utilizam como um parâmetro de modelo).

Por que o padrão introduziu três novos símbolos? (Parece um pouco arbitrário — apenas minha opinião pessoal.)

Tenho um dicionário de colunas aninhadas com o índice como chave em cada uma. Quando tento convertê-lo para um dataframe polars, ele busca os nomes das colunas e os valores corretos, mas cada coluna tem apenas um elemento que é o dicionário dos elementos da coluna, sem "expandi-lo" em uma série.

Um exemplo, digamos que eu tenha:

d = {'col1': {'0':'A','1':'B','2':'C'}, 'col2': {'0':1,'1':2,'2':3}}

Então, quando eu faço um pl.DataFrame(d)ou pl.from_dict(d), eu obtenho:

col1           col2
---            ---
struct[3]      struct[3]
{"A","B","C"}  {1,2,3}

Em vez do dataframe regular.

Alguma ideia de como consertar isso?

Desde já, obrigado!

Estou construindo um aplicativo React simples onde tenho um pet com propriedades como fome, tédio e energia. Quero atualizar essas propriedades em intervalos diferentes (fome a cada 5 segundos, tédio a cada 8 segundos e energia a cada 10 segundos).

No entanto, enquanto o status de fome atualiza corretamente, os status de tédio e energia não. Estou usando setIntervalpara atualizar esses valores, mas parece que apenas a fome está sendo atualizada.

Aqui está o código relevante:

import { useEffect, useState } from "react";
import { Pet } from "./types/pet";

function App() {
  const [pet, setPet] = useState<Pet | null>(null);

  useEffect(() => {
    // Load pet from localStorage or create a new pet
    const savedPet = localStorage.getItem("pet");
    if (savedPet) {
      try {
        const parsedPet = JSON.parse(savedPet) as Pet;
        setPet(parsedPet);
      } catch (error) {
        console.error("Error parsing saved pet:", error);
        createNewPet();
      }
    } else {
      createNewPet();
    }
  }, []);

  const updatePet = (updateFn: (currentPet: Pet) => Partial<Pet>) => {
    setPet((prevPet) => {
      if (!prevPet) return null;
      const updatedPet = { ...prevPet, ...updateFn(prevPet) };
      localStorage.setItem("pet", JSON.stringify(updatedPet));
      return updatedPet;
    });
  };

  useEffect(() => {
    if (!pet) return;

    const hungerInterval = setInterval(() => {
      updatePet((pet) => ({ hunger: Math.min(pet.hunger + 1, 100) }));
    }, 5000);

    const boredomInterval = setInterval(() => {
      updatePet((pet) => ({ boredom: Math.min(pet.boredom + 1, 100) }));
    }, 8000);

    const energyInterval = setInterval(() => {
      updatePet((pet) => ({ energy: Math.max(pet.energy - 1, 0) }));
    }, 10000);

    return () => {
      clearInterval(hungerInterval);
      clearInterval(boredomInterval);
      clearInterval(energyInterval);
    };
  }, [pet]);

  return (
    <div>
      <p>Hunger: {pet.hunger}%</p>
      <p>Boredom: {pet.boredom}%</p>
      <p>Energy: {pet.energy}%</p>
    </div>
  );
}

export default App;

O que estou vivenciando:

• A estatística de fome é atualizada corretamente a cada 5 segundos.
• As estatísticas de tédio e energia não são atualizadas como esperado, embora seus intervalos sejam configurados da mesma maneira.

O que eu tentei:

• Verifiquei os intervalos e eles parecem estar corretos.
• Tentei atualizar o estado com atualizações funcionais para garantir que o estado mais recente fosse usado, mas ainda assim, apenas atualizações de fome.

Alguém sabe por que somente a estatística de fome está sendo atualizada e o que posso fazer para corrigir isso?

Tenho uma pasta cheia de arquivos .wav que gostaria de copiar em subpastas chamadas "Tamanho Único" e "Tamanho Não Único". Cerca de metade dos arquivos tem o mesmo tamanho até o byte:

Get-ChildItem "*.wav" | Group-Object -Property Length -NoElement | Sort-Object Count -Descending

Count Name     Group (Example)
----- ----     ----
    6 26244078 {file206.wav, file137.wav, file 101.wav, etc.}
    5 28716602
    5 28807758
    5 30750266
    ...
    1 17773794 {file31.wav}
    1 18144078
    1 18432082
    1 70589446

Gostaria que eles fossem copiados para "Tamanho Único" se Contagem de Grupo = 1 e "Tamanho Não Único" caso contrário, mas sou bastante inexperiente com powershell e CLI em geral e não tenho muita certeza do que fazer com a saída do comando neste momento. Tentei algumas pesquisas online, mas minhas palavras-chave não parecem estar me levando a lugar nenhum para esse problema bastante único. Qualquer ajuda é apreciada, obrigado!

Estou usando o Swaggo para documentar meus endpoints da API Go. Tenho uma função de manipulador onde defini uma struct com tags de exemplo nos campos JSON struct, mas esses exemplos não estão aparecendo na IU do Swagger gerada.

// @Summary Register a new user
// @Description Creates a new user account. In development environment, the user is activated immediately. Otherwise, an activation email is sent.
// @Tags users
// @Accept json
// @Produce json
// @Param request body main.application.registerUserHandler.input true "User registration details"
// @Success 202 {object} object{user=data.User}
// @Router /users [post]
func (app *application) registerUserHandler(w http.ResponseWriter, r *http.Request) {
    var input struct {
        Name     string `json:"name" example:"John Doe"`
        Email    string `json:"email" example:"[email protected]"`
        Password string `json:"password" example:"SecurePass123!"`
    }
    // ... rest of the handler ...
}

A documentação do Swagger gera corretamente, mas os valores de exemplo das tags de exemplo na estrutura não estão aparecendo no esquema do corpo da solicitação.

Existe uma maneira de fazer o Swaggo reconhecer as tags de exemplo em estruturas aninhadas/em linha?

Então me deparei com as postagens maravilhosas do blog de Jeff Preshing sobre o que é Acquire/ Releasee como elas podem ser alcançadas com algumas barreiras de CPU .

Também li que SeqCstse trata de uma ordem total que é garantidamente consistente com a relação não coerente-depois - embora às vezes possa contradizer a relação acontece-antes estabelecida por operações simples Acquiredevido Releasea razões históricas.

Minha pergunta é : como os antigos built-ins do GCC mapeiam no modelo de memória proposto pelo C++11 (e revisões posteriores)? Em particular, como mapear __sync_synchronize()no C++11 ou no C/C++ moderno posterior?

No manual do GCC, essa chamada é simplesmente descrita como uma barreira de memória completa , que eu suponho ser a combinação de todos os quatro principais tipos de barreira, ou seja, barreirasLoadLoad / LoadStore/ StoreLoad/ todas de uma vez. Mas é equivalente a ? Ou talvez , formalmente falando , uma delas seja mais forte que a outra (o que eu suponho ser o caso aqui: em geral, uma cerca deve ser mais forte, pois requer que a cadeia de ferramentas/plataforma improvise uma ordenação global de alguma forma, não?), e acontece que a maioria das CPUs por aí fornece apenas instruções que satisfazem ambas (barreira de memória completa por , ordenação sequencial total por ) de uma vez , por exemplo x86 e PowerPC ?StoreStore sync_synchronize std::atomic_thread_fence(memory_order_seq_cst)SeqCst__sync_synchronizestd::atomic_thread_fence(memory_order_seq_cst)mfencehwsync

Ou __sync_synchronizee std::atomic_thread_fence(memory_order_seq_cst)são formalmente iguais ou são efetivamente iguais (ou seja, formalmente falando, são diferentes, mas nenhuma CPU comercializada se preocupa em diferenciar entre os dois), tecnicamente falando, uma memory_order_relaxedcarga no mesmo atômico ainda não pode ser confiável para sincronizar com /criar acontece antes da relação com ele, certo?

Tecnicamente falando, todas essas afirmações podem falhar, certo?

// Experiment 1, using C11 `atomic_thread_fence`: assertion is allowed to fail, right?

// global
static atomic_bool lock = false;
static atomic_bool critical_section = false;

// thread 1
atomic_store_explicit(&critical_section, true, memory_order_relaxed);
atomic_thread_fence(memory_order_seq_cst);
atomic_store_explicit(&lock, true, memory_order_relaxed);

// thread 2
if (atomic_load_explicit(&lock, memory_order_relaxed)) {
    // We should really `memory_order_acquire` the `lock`
    // or `atomic_thread_fence(memory_order_acquire)` here,
    // or this assertion may fail, no?
    assert(atomic_load_explicit(&critical_section, memory_order_relaxed));
}

// Experiment 2, using `SeqCst` directly on the atomic store

// global
static atomic_bool lock = false;
static atomic_bool critical_section = false;

// thread 1
atomic_store_explicit(&critical_section, true, memory_order_relaxed);
atomic_store_explicit(&lock, true, memory_order_seq_cst);

// thread 2
if (atomic_load_explicit(&lock, memory_order_relaxed)) {
    // Again we should really `memory_order_acquire` the `lock`
    // or `atomic_thread_fence(memory_order_acquire)` here,
    // or this assertion may fail, no?
    assert(atomic_load_explicit(&critical_section, memory_order_relaxed));
}

// Experiment 3, using GCC built-in: assertion is allowed to fail, right?

// global
static atomic_bool lock = false;
static atomic_bool critical_section = false;

// thread 1
atomic_store_explicit(&critical_section, true, memory_order_relaxed);
__sync_synchronize();
atomic_store_explicit(&lock, true, memory_order_relaxed);

// thread 2
if (atomic_load_explicit(&lock, memory_order_relaxed)) {
    // we should somehow put a `LoadLoad` memory barrier here,
    // or the assert might fail, no?
    assert(atomic_load_explicit(&critical_section, memory_order_relaxed));
}

Eu tentei esses snippets no meu RPi 5, mas não vejo falhas nas asserções. Sim, isso não prova nada formalmente, mas também não esclarece a diferenciação entre __sync_synchronizee std::atomic_thread_fence(memory_order_seq_cst).