Посмотрел мэйн, дальше смотреть не хочется. Выбери уже один стиль именования переменных.

принято

AudioFile audioFile(QString(file.fileName()));
QString(file.fileName())

Нафейхуа? fileName() и так QString.

перебдел :)))))

По стилистике

1. COMMIT_MSG на русском языке в перемешку с английским. Выбери что-нибудь одно, лучше eng;
2. Приведи всё к одному стилю, у тебя сейчас то:

   int foo()
   {
       ...
   }

   то:

   int foo() {
       ...
   }

   причём в одних и тех же файлах;
3. Разберись с выравниванием, либо ты его используешь, либо не используешь.

Из одного main могу сказать следующее

ApplicationSettings *Settings = new ApplicationSettings();
[.code]
Нет смысла создавать объект в куче. Читай доки, там ясно написано, что создание QSetting и работа с ним - очень быстрые операции, по-этому, там, где он тебе нужен, просто создаешь на стеке

QSettings s;
...

QObject::connect(StreamProcessor->audioDecoder, SIGNAL(bufferReady()), StreamProcessor, SLOT(transferSamples()));
    QObject::connect(DjProcessor->audioDecoder, SIGNAL(bufferReady()), DjProcessor, SLOT(transferSamples()));

Если ты собираешься связывать сигналы и слоты одного и того же объекта класса, то это, как правило, делается внутри этого класса...так сказать сокрытие информации от пользователя.

client.connectToServer("radon");
...
return app.exec();

Здесь нужно понимать, что подключение идет еще до запуска основного лупа qt, обычно это плохая практика и делаю что то типа этого

app.postEvent(client, new StartEvent())
...
return app.exec();

QSettings(QDir::homePath()+"/.radon/radon.conf"

я бы заменил на нечто такое

QSettings(tr("%1%2").arg(QDir::homePath()).arg("/.radon/radon.conf"))

Ну и тебе уже сказал panter_dsd, определись со стилем, и не только именования переменных и и вообще с оформлением кода. т.к. инкапсулированные переменные и методы лучше оформлять как private ну или protected

QString artist;
    QString title;
    QString album;
    QString comment;
    QString genre;
    uint track;
    uint year;

    void setTitle(QString title);
    void setArtist(QString artist);
    void setAlbum(QString album);
    void setComment(QString comment);
    void setGenre(QString genre);
    void setTrack(uint track);
    void setYear(uint year);

Еще заметил у тебя класс ApplicationSettings, спрашивается «ЗАЧЕМ»... тем более, зачем класс?

 this->artist = QString::fromStdWString(artist.toCWString());
    this->album = QString::fromStdWString(album.toCWString());
    this->title = QString::fromStdWString(title.toCWString());
    this->comment = QString::fromStdWString(comment.toCWString());
    this->genre = QString::fromStdWString(genre.toCWString());
    this->track = track;
    this->year = year;

this здес не нужен, т.к. ты и так внутри объекта...

Вынеси сборку qjack в отдельный .pri, а сами исходники в 3rdparty, например. Это же не твой код. Ну и man git submodule.

Про Settings мне настройки потом ещё надо будет хранить на сервере и забирать их оттуда поэтому в отдельный класс вынес.

Остальное вроде бы уже поправил.

QSettings(QDir::homePath()+«/.radon/radon.conf»

я бы заменил на нечто такое

QSettings(tr(«%1%2»).arg(QDir::homePath()).arg(«/.radon/radon.conf»))

За бан по ДНК обоих. Какой хоумпаф? QSettins сам (ну, почти) знает куда сохранять (XDG_CONFIG_HOME, например в линуксах), не надо умничать.

Тя не пинать надо а убивать

«/.radon/radon.conf»

http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html

$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

Это у ТСа такой путь, кто знает, что у него там в голове, и для чего он сделал именно так. Но если ТС указал явно формат, то он наверное все же заглянул в доки.А мой комментарий был исключительно для того, чтобы показать ТСу, что вместо конкатенации в Qt есть чудо функция arg...

не надо умничать

Вот и не умничай, лучше бы сам посмотрел код и сделал замечания...а то судить все горазды...

Почему Radon, а не RadiON ?

Мне нужно будет потом конфиг и коллекцию разносить rsync по нескольким компам и поэтому я всё в одну папочку положил...пока так...

Типа газ.

Я и делаю замечание, если для тебя это суд, то у меня для тебя плохие новости.

this здесь не нужен, т.к. ты и так внутри объекта.

Есть похожее соглашение о кодировании — обращаться к членам класса изнутри через this. Позволяет их визуально отличать.

нет, это было сделано по глупости.

Да в общем-то пофигу. Я просто хотел сказать, что несмотря на очевидную в данном случае ненужность this, его всё-таки используют так. Есть ещё и другие варианты: один знак подчёркивания в конце (methodfield_), префиксы (m_methodfield). Может есть ещё, не встречал.

Пиши свои программы как хочешь. В какой-то момент их размер перевалит границу, за которой плохо структурированный код ты поддерживать уже не сможешь, и тогда появится необходимость выработать свой стиль, что ты и сделаешь. А пока надобности нет, эти «попинайте код» смысла не имеют.

посмотрел пару модулей мейн и колекция - ничего

осиль доксиген

В main.cpp выделяется память под 4 объекта в куче, а где она освобождается?

При закрытии нет разве ?

При закрытии нет разве ?

Действительно, зачем нужен delete.

ок. спасибо за совет. Но лучше уж я думаю на начальном этапе думать над этим...

Эммммммм можно по подробнее ?

Добавь комментарии: - в начале файла (о лицензии, авторе, проекте и т.п.) - описание каждого класса, его методов, членов (как минимум публичных) - для указателей (членов и параметров) - кто ими владеет

AudioFile::AudioFile(QString audiofile, QObject *parent) рекомендуется использовать референции вместо указателей

рекомендуется делать дестуркторы виртуальными

mediaFile = new QFile(audiofile)

tagFile = new

new бросает ислючение при недостатке памяти. Кто его ловит? По-видимому нужен delete в деструкторе.

Вызов AudioFile::sync или getTags уронит программу, если файл не найден.

comment = QString::fromStdWString(t_comment.toCWString());

Комментарий может быть довольно длинным, а здесь происходит полное копирование строки минимум 2 раза

mediaFile->open(QIODevice::ReadWrite);

Не обрабатывается случае если файл доступен только для чтения

album.length() == 0

Для коллекций обычно, есть более удобный и эффективный метод empty

QSettings(tr(«%1%2»).arg(QDir::homePath()).arg(«/.radon/radon.conf»))

tr(«%1%2»)

Локализация здесь каким местом? Если уже и соединять пути, то:

QDir::home().filePath(".radon/radon.conf");

ну если ты выделяешь в main, то и освобождай там же. То что ты сделал называется http://en.wikipedia.org/wiki/Memory_leak

Это плохая идея.

Выше уже сказано, что QString надо на стеке выделять, а не в куче, тогда и не нужно будет освобождать, оно само.

• Не стоит использовать префикс get если метод void, это не отражает суть метода, лучше loadTags или parseTags.
• Из названия Collection не понятно что это и зачем, это название подходит для интерфейса, но не для реализации! Лучше назвать FileCollection, иначе оно ассоциируется с абстракцией над списками, очередями и массивами.
• Перестань оставлять переменные в public:!

Эммммммм можно по подробнее ?

Да, https://ru.wikipedia.org/wiki/Сарказм

Поправил кроме последнего - не понял :) Пример плз

Вроде всё поправил...

Не нарушай инкапсуляцию оставлением всех членов класса в public секции, переменные должны лежать в private или protected и к ним get\set методы.

А разница?

истинно верующий?

али в еретичну банду тетру?

Локализация здесь каким местом...

Я же написал, что можно tr использовать для КОНКАТЕНАЦИИ, и, что я бы так и сделал. Это очень удобно, когда необходимо собрать строку и нескольких параметров, да еще и разного типа...

QString str = tr("Hello %1, this is the %2st message: pi=%3")
              .arg("man").arg(1).arg(3.14);

не отрицаю, но по мне, так это лишний код. На назойливость не претендую, каждый выбирает для себя удобное решение...Но в Qt, по моему опыту, при создании того или иного класса, меня всегда вымораживала рутинная работа (я обычно не пользуюсь ui файлами, а сам прогаю gui), а добавление this мне бы точно прибавило времени по разработке

На сколько я помню, все объекты QObject явно удалять не нужно (даже созданные в куче), если это явно не прописано в доках

ок, я тебя не так понял, постоянное прибывание на ЛОРе делает свое дело...

Вот и я что то такое читал...

man инкапсуляция

На сколько я помню, все объекты QObject явно удалять не нужно (даже созданные в куче), если это явно не прописано в доках

говнокод. То, что ТЫ создаёшь в куче, ТЫ и должен удалять. И не важно, GObject это, или Foo/Bar.

Да, то, что ты там у себя насоздавал можно конечно и не удалять, система сама удалит(обычно так).

То, что ТЫ создаёшь в куче, ТЫ и должен удалять. И не важно, GObject это, или Foo/Bar.

для QObject не обязательно, если четко выстроена иерархия владения объектами

для QObject не обязательно, если четко выстроена иерархия владения объектами

вот откуда вы такие умные на свет ползёте? Абсолютно насрать, что внутри контейнера, если ты выделил контейнер, ты его и обязан удалить. Сборщика мусора в C++ нет по дефолту, ты его с чем-то путаешь.

QSettings(tr(«%1%2»).arg(QDir::homePath()).arg(«/.radon/radon.conf»))

а что будет, если учетная запись называется: %2?

вот откуда вы такие умные на свет ползёте?

Так им твоя аватарка вместо солнышка светит. Поменяй на кирпич, может отпугнёт

поменял.

Парень, контейнер никто не выделяет в куче, т.к. нет смысла. А вот удаление QObject делать не надо, т.к. Qt сама удаляет объекты когда надо, только что открывал Бланшет, там про это в начале книги написано...В огромных гуях я создаю целую тучу объектов, и, если для каждого из них делать вызов delete, то я думаю, Qt скоро бы возненавидели... Qt так же предоставляет свой метод deleteLater, который правильно удалит объект, убедившись, что в очереди к нему нет эвентов...А если ты удалишь через delete сам, и в очереди окажется event, то прога может рухнуть... Более того, как правильно сказали выше, родитель сначала вызывает диструкторы всех своих детей, где те сами удаляются...

Об экранировании слышал?

Парень, контейнер никто не выделяет в куче, т.к. нет смысла.

ТС таки выделяет.

А вот удаление QObject делать не надо

я и не предлагал его специально удалять.

каждого из них делать вызов delete

деструкторы придумали для этого.

вот откуда вы такие умные на свет ползёте? Абсолютно насрать, что внутри контейнера, если ты выделил контейнер, ты его и обязан удалить.

мы просто умеем читать, в отличие от некоторых. если система отношений между объектами позволяет контроллировать уборку согласно некоторым правилам - пусть делает это. какой профит с ручного delete если объект обязан удалить его владелец?