Кодерский уголок

Следующая проблема: OW не поддерживает istreambuf_iterator

SidTuneBase.h

Код:

...
class SidTuneBase
{
protected:
    typedef std::vector<uint_least8_t> buffer_t;
    ...

SidTuneBase.cpp

Код:

void SidTuneBase::loadFile(const char* fileName, buffer_t& bufferRef)
{
    std::ifstream inFile(fileName, std::ifstream::binary);
    ...
    inFile.seekg(0, inFile.end);
    const int fileLen = inFile.tellg();
    ...
    buffer_t fileBuf;
    fileBuf.reserve(fileLen);
    try
    {
        fileBuf.assign(std::istreambuf_iterator<char>(inFile), std::istreambuf_iterator<char>());
    }
    catch (std::exception &ex)
    {
        throw loadError(ex.what());
    }

    ...
}

Как тут обойтись без istreambuf_iterator?

 

Потому что обращение идёт именно к сишной функции. Попробуй убрать #include <time.h> и сделать std::time(0) - должно нормально фунцыклировать.

 

Проверил - это работает. Вопрос - почему работало без std у автора, читай - под gcc?

 

Geryon, кстати, вместо "%2x" я бы советовал "%02x"

 

А да, точно, иначе будет ширина <=2, а не 2.

 

:-( А про это говорилось несколько недель назад:

:-((((((

 

Geryon, Функцию загрузки файла переписать на C, думаю, не вопрос, но нужен контекст. Откуда это? лень листать много страниц.

 

Ширина ОК, а заполнение ведущими нулями - йок. А в шестнадцатиричке пренебрегать ими не принято. Тем более для вывода md5-суммы, если я правильно понимаю.

 

Рыжий Тигра, в выходной строке будут пропущены все нули, попавшие на нечетную позицию (если считать от 1).

 

Точно... Совсем я всё забыл.

Это я компилирую libsidplayfp 1.6.2 под OpenWatcom C++ 1.9

Под OW компилирую не из мазохизма, а ради возможности собрать под платформу DOS.

Код загрузки файла находится здесь: /sidplayfp/sidtune/sidtunebase.cpp

 

Рыжий Тигра, и даже сейчас есть нестыковки у разных компиляторов. GCC и MSVC более-менее похожи, почти не требуются правки, если использовать стандартные и кроссплаформенные либы. Главное отличие, MSVC даёт больше свободы с шаблонами, он хорошо понимает что имел ввиду "этот криворукий", но с другой стороны это плохо потому что ухудшается читаемость и ваще расслабляет программиста. Хорошо ещё, что после адаптации к GCC, мелкомягкий принимает это. А то была бы жопа с #ifdef __GCC__ и тому подобным.

 

Эмм.. Я, возможно, не в теме, а что стало с DJGPP?

 

C DJGPP я никогда не сталкивался. Пытаюсь сейчас установить под DosBox. С ним наверняка будут следующие проблемы:

- потребуется перетрясти весь проект на предмет несовместимости имен файлов с 8.3
- соберет ли он вообще это безобразие с учетом использования там старого gcc?
- проект не заточен под DOS и совершенно точно работать там не будет; с OW я могу сначала собрать под винду, потом выбросить весь win-специфичный код, которого там немного, и заменить на dos-специфичный, затем пересобрать под DOS

Поэтому я и пытаюсь собрать под привычный OpenWatcom.

 

Geryon, Для начала пишем
typedef uint_fast8_t u8;
typedef std::vector<u8> buffer_t;
вместо
typedef std::vector<uint_least8_t> buffer_t;
Это необязательно, строго говоря, но значительно удобнее и немного быстрее.
Пользуемся далее типом u8 вместо вышеупомянутого идиотизма, не забывая только , что теперь байты - беззнаковые. Но если какой-то идиотский код заменой типа будет поломан, придется убрать.
далее

Код:

void SidTuneBase::loadFile(const char* fileName, buffer_t& bufferRef)
{
    FILE *f = fopen(fileName, "rb");
    if (NULL == f)
        throw loadError(ERR_CANT_OPEN_FILE);

    fseek(f, 0, SEEK_END);
    const size_t fileLen = ftell(f);
    if (0 == fileLen) 
        throw loadError(ERR_EMPTY);

    fseek(f, 0, SEEK_SET);

    bufferRef.resize(fileLen);
   /*sizeof(bufferRef[0])  == 1 иначе всё поломается в любом случае, но для строгости пишем так :) */
    if (fileLen != fread(&bufferRef[0], sizeof(bufferRef[0]), fileLen, f))
        throw loadError(ERR_CANT_LOAD_FILE);

    fclose(f);
}

Честно говоря, я бы выкинул весь этот плюсовый мусор на помойку и переписал бы по-человечески. Только времени нет

Еще совет. Строго говоря, C-хидеры в C++ нужно подключать через C++ обертки. Обычно компиляторам всё равно, но, возможно, для вашего это важно.
<stdlib.h> -> <cstdlib>
<time.h> -> <ctime>
<stdio.h> -> <cstdio>

---------- Сообщение добавлено 12.12.2014 в 00:10 ---------- Предыдущее сообщение размещено 11.12.2014 в 23:58 ----------

Geryon, Я не знаю, насколько далеко ушел OpenWatcom от "старого" Watcom, но DJGPP вроде как развивался уже после смерти Watcom. Могу ошибаться.

 

Ну да - после такой замены из-под каждого куста начали раздаваться вопли о type mismatch и подобных ошибках, так что этот кусок пришлось оставить как есть.

Для OpenWatcom как раз наоборот! Автор постоянно использует всякие там time() и size_t, подключая <ctime> и <cstring> соответственно, а в OW это не работает, нужно либо писать std::time() и std::size_t, либо подключать <time.h> и <string.h>.

DJGPP закончил развитие в 2002 году, правда кто-то вроде адаптировал под него GCC 2008 года. Текущая версия OpenWatcom вышла в 2010. Хотя это лишь косвенные данные, а какой компилятор более прогрессивен в смысле новых стандартов - я не знаю.

 

Печально. Мнение об авторах проекта не очень хорошее складывается. Со знаковыми байтами без серьезной надобности работают только идиоты, это источник тормозов и багов. Я бы попытался облагородить код, починив все ссылки на этот буфер, но мало ли, может баг случайно создадите...

Код:

#include "sidplayfp/event.h"
#include "sidemu.h"

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

using namespace std; - не прокатило?

а using std::size_t; ?

 

Тоже подбешиваюсь и правлю на ходу, но получаются не менее уродливые (но хотя бы работающие) конструкции:

Код:

#include "mos656x.h"

#include <cstring>

#include "../../sidendian.h"

За вещи типа "../../" я бы и сам бил канделябрами, но толком не знаю, как от этого избавиться.

---------- Сообщение добавлено в 00:41 ---------- Предыдущее сообщение размещено в 00:37 ----------

Я собрал наконец, хотя сам не понимаю, что Оно говорит "File /usr/lib/vice/C64/kernal" not found и отваливается, но это уже что-то.

 

Geryon, Это один из ROM-ов, типа BIOS-а. Ищет его по фиксированному пути, что ли?

 

Да, пути заданы макросами в test.cpp, но библиотека вроде должна работать и без ROM'ов, по крайней мере с большинством SID-файлов. Надо подумать, вероятно, я что-то делаю не так.

Кстати, судя по всему, предполагалось, что все это соберется в библиотеку, а у меня получилась куча obj-файлов. Как сделать, чтобы была .lib библиотека?

Апдейт: ромы скачал, теперь всё зависает на проигрывании, что и неудивительно, учитывая, что собрано под DOS, а движок рассчитан либо на win32, либо на unix. Под win32 пока собрать не могу, потому что линкер ругается:

 

Geryon, Не подскажу. Но нет ли у вас желания зафигачить проект на github? Тогда совместная работа станет значительно более удобной.