nedoPC.org

От tinyxml2 тоже надо отказываться, так же как и от CEDAR'ского парсера xml. Что за идиотизм писать парсеры которые тупо роняют программу столкнувшись с кривым синтаксисом на входе? Если бы мне нужен был парсер так себя ведущий, то я бы совершенно точно написал бы парсер вручную, и он бы стопудов работал бы быстрее tinyxml2, как бы там авторы не выпендривались оптимизируя то, что оптимизации не требует по-определению.
Вот ведь, а? И при этом, исходный xml парсер, при всей кривизне его API и уменю падать был всё же лучше. Потому что он, когда оказывался несогласным с синтаксисом, в ужасе падал, наводя такого шороху, что не заметить его падение было невозможно.
А долбаный tinyxml2 вместо того, чтобы с героическим грохотом свалиться, тихонько сдыхал в каком-то безвестном уголке. Я так и не понял каким образом. gdb не замечал ничего, пока процесс не завершался. grep по коду tinyxml2 не показал никаких throw. Когда же я повесил бряк на exit, то бряк сработал, но на стеке было всего лишь три фрейма: exit, и ещё два, которые вообще-то должны быть ниже main. Как собственно такое могло случится не очень понятно. Вот ведь сука а? Столько времени об него убил.

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

Буду значит переписывать всё связанное с xml на libxml++: в ней, как я понимаю, реально рабочего кода нету, лишь бинды к libxml2, а libxml2 написана на C и поэтому не может не работать. И там есть SAX парсер. Правда не очень понятно как хорошо, красиво и удобно использовать SAX парсер не имея в языке лексических замыканий... Хотя, говорят, что в новом C++11 есть что-то типа замыканий. Но C++11 будет совершенно точно несовместим к lavr'овским билдером 5.0. =)

Да ладно прикалывать-то... Я C++ освоил, как раз чтобы писать DLL-ки,
поскольку в Венде некоторые задачи без DLL никак не решить...

И лишь потом убедился, что и небольшого размера программу я на C++ слепить могу.

Ну и поскольку я этому тогда учился, вот и приходилось решения, приводимые
авторами на разных версиях C++ подгонять под свой Билдер 5.0 ...
Он вовсе даже неплох... хотя конечно же - устарел...

Гипотетический вопрос.

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

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

И какой формат?...

Вобще-то для обмена схемами считается удобным иметь в программах симуляции
схем опцию экспорта в SPICE.
Поскольку он считается в некотором роде стандартом.

И есть ли смысл выдумывать новый велосипед?
Для себя программа может сохранять проект в удобном своём формате,
а в SPICE-формате можно втащить разработку по крайней мере в распространенные
пакеты моделирования EWB (Multisim), Proteus и др.

Это не по-пионерски. =)


Взять logisim и приделать к нему симулятор от CEDAR Logic. Оно конечно придётся повозиться, но, вероятно, всё же меньше чем с переписыванием гуя целиком. Но проще в Logisim засунуть модельку Z80, переписав с C++ на Java. Точнее не проще, а перспективнее: можно будет надеятся, что эта моделька Z80 будет включена в Logisim и начнёт жить самостоятельной жизнью, не требуя от нас никаких усилий по затачиванию её на всё новые и новые версии Logisim'а.

Но я как то уже нацелился на переписывание гуя (вообще у меня есть мысли и симулятор переписать, но пока столь неопределённые и отдалённые, что лучше наверное молчать об этом в тряпочку). И я скорее перепишу гуй, чем поставлю в систему жабу. Ну не люблю я её: интерпретируемый язык, сборка мусора, там есть всё, что надо для полноценного динамического языка, но возможности Java на уровне компилируемого C++ и даже ниже.

Полностью согласен! И сам жабу не люблю - но жизнь заставила...
Для сотовых телефонов кроме J2ME - ничего другого нет.

Но у нас-то нет этого ограничения!
Опять же - да, жаба - интерпретатор, и не факт что прямо безусловно кроссплатформенна.
С примерами мы уже и тут на форуме сталкивались.

Вот экспорт в SPICE добавить бы неплохо, чтобы симулятор не остался вещью в себе.

имхо SPICE это для аналоговых схем - нафига нам аналоговые схемы?...

Да неужели? Shame on you! Неверное у тебя "имхо"...





У SPICE есть, конечно, некоторые ограничения, но как ни крути,
его принимают за стандарт...

то что ты привёл легко покрывается и без притягивания за уши аналоговой составляющей - просто вводим третье состояние Z и таблица переходов блока "подтягивающий резистор" будет выглядеть следующим образом:


точно также можно подтянуть на землю...

я бы даже сказал от пяти...

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



ну то есть возвращаеся к тому же с чего и начали - а не замутить ли нам недосимулятр?

А зачем мне эта ненужная ботва? Я тебе привел пример, что формат данных
SPICE - это не только для аналоговых схем, как считал ты.

А для чего ты мне излагаешь всю эту бодягу про "третье состояние Z и таблицу
переходов", я просто не представляю...

Если ты что-то хочешь делать по-своему - делай, но это никак не влияет
на формат данных SPICE...

ну можно и микроскопом гвозди заколачивать, вот только зачем?

повторю вопрос: если мы берёмся делать симулятор цифровых схем, то нафигали нам SPICE?

кнопки и подтягивающие резисторы отпали - что ещё?

Я что-то тебя не понимаю, либо ты не читал топик выше...

Я предложил иметь возможность сохранять проект в формате данных SPICE
в ответ на предложение b2m :


При чем тут какая-то хрень про "микроскоп и гвозди"?

Если ты знаешь какой другой распространенный формат данных для обмена
файлами между симуляторами - назови...

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

про микроскоп и гвозди - SPICE это микроскоп, а симуляция чисто цифровых схем - это гвозди, которым нужен на порядок более простой формат и более упрощённая (и быстрая) симуляция

по аналогии я бы мог тебе предложить сохранять для имитации аналоговых схем точное описание поведения каждого электрона в схеме - теоретически это сделать можно, но нецелесообразно

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

Формат файла Logisim не совместим ни с чем кроме самого Logisim-а.
Его не поддержит ни один распространенный пакет эмуляции.

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

С переносом данных проекта в формате SPICE я безусловно сталкивался -
это работает - иначе я бы не предлагал.
Проблем особых я там не увидел. По крайней мере всё, что работает на основе
SPICE - вполне успешно обменивается файлами в этом формате.