jpo38's questions

Estou migrando algum código do Qt 6.2.2 para o 6.9.0 no Android.

Tenho um código procurando arquivos .so na pasta do aplicativo (para possíveis plugins a serem carregados). Este código costumava iterar a pasta do aplicativo usando std::filesystemcódigo padrão. Não funciona mais. Consigo iterar a pasta HOME, mas não a pasta do aplicativo. Surpreendentemente QDir, consigo, mas meu código que faz isso é puramente C++/STL, não consigo usar Qt neste nível.

Algo mudou na estrutura do apk? Por que o STL não consegue ver a pasta do aplicativo? Existe alguma solução alternativa?

Aqui está um programa de exemplo muito simples:

#include <QApplication>
#include <QMainWindow>
#include <QLabel>
#include <QDebug>
#include <QDir>
#include <filesystem>
void listDirContent(QString path)
{
    {
        QDir dir(path);
        qDebug() << "Using Qt, " << path << ":";
        for (auto file : dir.entryList())
            qDebug() << file;
    }
    {
        std::filesystem::path std_path = path.toStdString();
        qDebug() << "using std, " << std_path.c_str() << ":";
        std::filesystem::directory_iterator itDir;
        std::filesystem::directory_iterator itEnd;
        std::filesystem::path Path;
        try
        {
            itDir = std::filesystem::directory_iterator(std_path);
            qDebug() << "Found files:";
            for (; itDir != itEnd; itDir++)
            {
                qDebug() << QString(itDir->path().c_str());
            }
            qDebug() << "end files";
        }
        catch (const std::exception& e)
        {
            qDebug() << "FAILED" << e.what();
        }
    }
}

int main( int argc, char* argv[] )
{
    QApplication app(argc, argv);
    QMainWindow wnd;
    wnd.setCentralWidget(new QLabel("Hello",&wnd));
    wnd.show();
    listDirContent(qApp->applicationDirPath());
    listDirContent(QDir::homePath());
    return app.exec();
}

Este programa produz:

D/default (18701): Using Qt,  "/data/app/org.qtproject.example.TestListDir-UzLzgFYV8gnNNAzUQkD1Lw==/base.apk!/lib/armeabi-v7a" :
D/default (18701): "armeabi-v7a"
D/default (18701): "libc++_shared.so"
D/default (18701): "libplugins_iconengines_qsvgicon_armeabi-v7a.so"
D/default (18701): "libplugins_imageformats_qgif_armeabi-v7a.so"
D/default (18701): "libplugins_imageformats_qico_armeabi-v7a.so"
D/default (18701): "libplugins_imageformats_qjpeg_armeabi-v7a.so"
D/default (18701): "libplugins_imageformats_qsvg_armeabi-v7a.so"
D/default (18701): "libplugins_platforms_qtforandroid_armeabi-v7a.so"
D/default (18701): "libplugins_styles_qandroidstyle_armeabi-v7a.so"
D/default (18701): "libQt6Core_armeabi-v7a.so"
D/default (18701): "libQt6Gui_armeabi-v7a.so"
D/default (18701): "libQt6Svg_armeabi-v7a.so"
D/default (18701): "libQt6Widgets_armeabi-v7a.so"
D/default (18701): "libTestListDir_armeabi-v7a.so"
D/default (18701): using std,  /data/app/org.qtproject.example.TestListDir-UzLzgFYV8gnNNAzUQkD1Lw==/base.apk!/lib/armeabi-v7a :
D/default (18701): FAILED filesystem error: in directory_iterator::directory_iterator(...): No such file or directory ["/data/app/org.qtproject.example.TestListDir-FvVxa-eHXbBc9Zpa2Q0uGQ==/base.apk!/lib/armeabi-v7a"]
D/default (18701): Using Qt,  "/data/user/0/org.qtproject.example.TestListDir/files" :
D/default (18701): "."
D/default (18701): ".."
D/default (18701): "profileInstalled"
D/default (18701): "profileinstaller_profileWrittenFor_lastUpdateTime.dat"
D/default (18701): using std,  /data/user/0/org.qtproject.example.TestListDir/files :
D/default (18701): Found files:
D/default (18701): /data/user/0/org.qtproject.example.TestListDir/files/profileinstaller_profileWrittenFor_lastUpdateTime.dat
D/default (18701): /data/user/0/org.qtproject.example.TestListDir/files/profileInstalled
D/default (18701): end files

Veja que std::filesystem não consegue iterar /data/app/org.qtproject.example.TestListDir-UzLzgFYV8gnNNAzUQkD1Lw==/base.apk!/lib/armeabi-v7aa pasta, ele relata que a pasta não existe, enquanto o Qt consegue iterar por ela.

Com o Qt 6.2.2, ele costumava listar os arquivos da pasta do aplicativo (o que era um pouco diferente, não havia "base.apk!" no caminho).

Relatei um bug no Qt: https://bugreports.qt.io/browse/QTBUG-136214

Alguém tem alguma ideia de como contornar esse problema? Como fazer com que o std::filestem consiga acessar a pasta do aplicativo?

Editar, std::filesystemé capaz de iterar /data/app/org.qtproject.example.TestListDir-UzLzgFYV8gnNNAzUQkD1Lw==, visto base.apkcomo um arquivo. Parece QDirsuportar um caso especial em que o nome do arquivo apk é seguido por !e é possível examiná-lo como se fosse, na verdade, uma pasta...

Tenho uma biblioteca my_libcom uma função C que pega um char***parâmetro, um ponteiro para um array que char*é alocado pela função. Aqui está um exemplo mínimo reproduzível de tal função:

void getArrayOfStrings(char*** paramPtr)
{
    (*paramPtr) = (char**) malloc(3*sizeof(char*));
    
    (*paramPtr)[0] = (char*) malloc(strlen("Foo")+1);
    strcpy((*paramPtr)[0], "Foo");
    
    (*paramPtr)[1] = (char*) malloc(strlen("Bar")+1);
    strcpy((*paramPtr)[1], "Bar");
    
    (*paramPtr)[2] = 0;
}

Ele define o último elemento do array como 0, para que o chamador possa identificá-lo (em vez de fornecer o tamanho como um segundo parâmetro). Note que uma função separada é fornecida para liberar a memória.

Eu corro ctypesgenpara gerar uma ligação Python para esta função. Ela gera este código:

getArrayOfStrings = _lib.get("getArrayOfStrings", "cdecl")
getArrayOfStrings.argtypes = [POINTER(POINTER(POINTER(c_char)))]
getArrayOfStrings.restype = None

Essa ligação gerada pode ser chamada a partir do script Python abaixo:

import my_lib

import ctypes
names = ctypes.POINTER(ctypes.POINTER(ctypes.c_char))()

my_lib.getArrayOfStrings(names)

if names:
    for name in names:
        name_str = my_lib.String(name)
        if name_str:
            print("Got name: " + str(name_str))
        else:
            break

Funciona perfeitamente e imprime "Foo\nBar\n"

Estou apenas me perguntando por que usar ctypes.POINTER(ctypes.POINTER(ctypes.c_char)), que eu entendo como sendo um "ponto para ponteiro para char", então um char**, funciona. Por que eu não deveria usar um ctypes.POINTER(ctypes.POINTER(ctypes.POINTER(ctypes.c_char)))?

Testei com ctypes.POINTER(ctypes.POINTER(ctypes.POINTER(ctypes.c_char))), o mesmo código produz o erro:

my_lib.getArrayOfStrings(names)
OSError: exception: access violation writing 0x0000000000000000

Estou usando ctypepara chamar código C do Python.

A função C que preciso chamar recebe um char***, e por isso é vinculada como se estivesse usando um ctypes.POINTER(ctypes.POINTER(ctypes.c_char)).

Não entendo como criar e inicializar esses objetos com segurança, porque se eu criar um e tentar iterá-lo imediatamente, o programa Python trava:

import ctypes
names = ctypes.POINTER(ctypes.POINTER(ctypes.c_char))()
if names != None:
    for name in names:
        pass

O erro é:

Traceback (most recent call last):
  File "example_sdetests_lib_bind_python_string_array.py", line 6, in <module>
    for name in names:
ValueError: NULL pointer access

Como posso verificar com segurança se um valor ctypes.POINTER(ctypes.POINTER(ctypes.c_char))é NULL ou não?

Estou executando o CppCheck em algum legado e tentando consertar todos os problemas relatados. Tenho alguns avisos de portabilidade relacionados à transmissão que não consigo descobrir como consertar.

Eu isolei o código em um MVCE, basicamente, recebemos um char*(lido de um driver USB). Este array representa doublevalores. Para interpretá-los, usamos um cast from char*to double*, funciona bem para todas as nossas plataformas suportadas, mas o CppCheck não gosta disso.

Existe uma maneira melhor de fazer isso em C++? Ou devo simplesmente silenciar o aviso para essas linhas?

void printAsDouble( char* myData, size_t size )
{
    if ( size%sizeof(double) == 0 )
    {
        double* array = (double*)myData;
        for (size_t pos = 0; pos != size/sizeof(double); ++pos)
            std::cout << "Value #" << (pos+1) << " is " << array[pos] << std::endl;
    }
}

Relatórios CppCheckportability: Casting between char * and double * which have an incompatible binary data representation.

Estou executando a ferramenta cppcheck em algum código e ela me relata um problema de desempenho em algum código ao verificar se um mapa não tem um valor antes de inserir um novo.

Isolei o código em um snippet MCVE (que não faz sentido... mas ilustra o problema):

std::map<int, float*> myMap;
myMap[1] = new float(3.0f);

for ( size_t pos = 0; pos != 10; ++pos )
{
    if ( myMap.find( pos ) == myMap.end() )
    {
        myMap[pos] = new float(4.0f);
    }
}

Relatórios CppCheck(performance,ID=stlFindInsert) Searching before insertion is not necessary.

Na verdade, é necessário evitar vazamentos substituindo o valor antigo por um novo... e, a propósito, você pode não querer substituir o valor antigo, se houver algum...

Como devo escrever o código melhor para evitar esse problema de desempenho?

Eu tenho este trecho de código que aplica um filtro Bessel:

Versão única:

import scipy.signal

fc_bessel = 0.14  # [Hz]
ordre_bessel = 3

b,a = scipy.signal.bessel(ordre_bessel, fc_bessel, 'low', analog=False, output='ba', fs=300)

filter_once = scipy.signal.lfilter(b, a, input_data)

Como no final receberei meus dados em tempo real, preciso adaptar esse código para pegar cada um input_datana hora, então preciso manter o estado do filtro em uma zivariável. Então eu escrevi:

Versão iterativa:

import scipy.signal

fc_bessel = 0.14  # [Hz]
ordre_bessel = 3

b,a = scipy.signal.bessel(ordre_bessel, fc_bessel, 'low', analog=False, output='ba', fs=300)
z = scipy.signal.lfilter_zi(b, a)

filter_iter = []
for input_value in input_data:
    filtered_value, z = scipy.signal.lfilter(b, a, [input_value], zi=z)
    filter_iter.append(filtered_value[0])

No entanto, as saídas são completamente diferentes (se o primeiro valor for 0, filter_once[0]é 00,999 filter_iter[0]...)