Войти
ПрограммированиеФорумОбщее

Знатоки C++ и WinAPI, покритикуйте код! (Считывание ini-файла на голом WinAPI.) [(временно?) закрыто] (6 стр)

Страницы: 1 2 3 4 5 6
#75
23:31, 25 сен. 2020

Silen#ID
> leonardo98, а endeavour_pr с тобой не согласен, и кто прав?)
Если "его" быстрая либа умеет парсить инишки  значит ты можешь парсить ей инишки либо свой клон инишек для конфиг файлов.
Я имел ввиду что сам конфиг в ини файлах удобней читать и править руками в блокноте чем хмл представление.

В древних играх юзали и то и другое, для разных целей. Инишки как конфиги для разных параметров, ну например настройки графики или даже настройки игровых объектов, все по сути одно и тоже есть объект и есть его параметры. Хмл юзали для ГУИ. Для скриптинга вообще часто брали lua.

Но раньше ты вроде хотел реализовать с минимумом либ и зависимостей даже от виндовых с++ либ.А теперь ты переобулся.


#76
(Правка: 8:58) 8:56, 26 сен. 2020

}:+()___ [Smile]
> XML на порядки сложнее JSON
В xml все данные - текст, он не делает преобразования типов при парсинге, в json есть зависимость от типа данных, доступ из кода в xml более низкоуровневый, поэтому быстрее( и опаснее в руках мартышек)

#77
20:54, 26 сен. 2020

В xml основная проблема не в его сложности (и невероятной избыточности, когда 90% содержимого может быть служебной информацией  - теги, атрибуты, пространства имён, итд в разных комбинациях), а в том, как некоторые идейные личности пытаются его применять. Некоторые, например, в качестве языка программирования пытаются и парсинг превращает в ад, с тысячами циклов по всему дереву (и это реальная запара даже c применением XPath, а без него, наверное вообще лучше не браться).  Насчёт "сложности" json, - есть более лайтовый YAML  (фактически, это ini, с небольшими различиями, на стероидах).

#78
23:06, 26 сен. 2020

0iStalker
> Насчёт "сложности" json, - есть более лайтовый YAML (фактически, это ini, с
> небольшими различиями, на стероидах).
Наверно, ты о какой-то старой версии, потому что текущая - 1.2 (которой уже 10 лет?) - это чистое надмножество жисона. Причём не как кое-кто болтает про С и С++, а по-настоящему - можно прямо подсунуть произвольный жисон-документ, и он распарсится как корректный ямл с тем же самым содержимым.

#79
21:31, 10 ноя. 2020
Я вернулся. Наверное...

Оу, последний мой ответ аж "20:35, 24 сен. 2020" -- надеюсь, полтора месяца -- это ещё не некропост?

}:+()___ [Smile]
> Стандарт простой — максимально придерживаться стандартов. {...}
Спасибо. Я б тебе поставил 10 лайков, жаль не куда. (Хотя, если скажешь чего тебе лайкнуть и если на том сайте у меня есть профиль --  не поленюсь, зайду и лайкну.) Ты крутой!)

}:+()___ [Smile]
> Предпочитать стандартный C++ OS-специфичному коду (использовать fread/fscanf
> вместо ReadFile).
Вероятно, туплю, но это с учётом потоков? Т.е. через fread считается лучше, чем даже через потоки?

}:+()___ [Smile]
> POSIX вместо WinAPI
Эм, что-то про это слышал... загуглил... да, точно, стандарты для Юникс-систем. На винде вроде частичная поддержка... Ну, т.к. пока я кодю только под винду, и ещё мой компилятор не понимает даже команду "fork" из POSIX... пожалуй мне пока лучше остаться на винапи, чем пытаться для частных случаев пытаться дёргать функции из POSIX.

}:+()___ [Smile]
> Google Code Style
Блин, а ведь тоже краем уха слышал. Пошёл читать Руководство Google по стилю в C++. Часть 1

}:+()___ [Smile]
> > Итого есть 1 голос в пользу xml против json -- причина: json медленнее
> > парсить.
> XML на порядки сложнее JSON, "быстрее парсить" его может быть потому, что
> большинство библиотек кладут болт на стандарт XML и реализуют его маленькое
> подмножество. К счастью, большая часть стандарта XML — это махровое легаси,
> которое никому не нужно.
Спасибо, что подтвердил предположение.

endeavour_pr
> Silen#ID
> > leonardo98, а endeavour_pr с тобой не согласен, и кто прав?)
> Если "его" быстрая либа умеет парсить инишки  значит ты можешь парсить ей
> инишки либо свой клон инишек для конфиг файлов.
> Я имел ввиду что сам конфиг в ини файлах удобней читать и править руками в
> блокноте чем хмл представление.
Ясно. (Согласен, хотя это и так самоочевидная вещь, и толку от её обмусоливания ноль.)

endeavour_pr
> Но раньше ты вроде хотел реализовать с минимумом либ и зависимостей даже от
> виндовых с++ либ.А теперь ты переобулся.
Не совсем понял, что за "виндовых с++ либ"? Это ты так обозвал STL?
Насчёт зависимостей...

+ ... это ты про эти мои посты?...

Хм, а это хороший вопрос.
(Спустя кучу времени самокопаний, копаний в теме, и тупо попыток вспомнить, что мне было надо более 2 месяцев назад...)
Ответ: не-а. А точнее:
- насчёт "виндовых с++ либ". Нашёл только 2 упоминания: заюзать std:string ради лишь пары операций конкатенации строк => имхо, не вижу смысла; и совет "Если хочешь конфиги свои читать юзай JSON и используй boost, а этим садо мазо не занимайся.", которым возможно и воспользуюсь (но об этом ниже);
- насчёт считывания конфигов через библиотеки. Тот свой примитивный конфиг с параметрами инициализации, я пожалуй буду считывать без библиотек, ибо смысл юзать целую либу ради пары строчек из файла. Но, на перспективу, в рамках повышения квалификации так сказать, так же интересует общепринятая практика: в зависимости от условий, в каких форматах лучше хранить конфиги, и как их читать, в том числе, можно и либами.
Как-то так.

(Остальное потом.)

#80
23:42, 10 ноя. 2020

Silen#ID
> Вероятно, туплю, но это с учётом потоков? Т.е. через fread считается лучше, чем даже через потоки?
Под "потоками" ты имеешь в виду fstream и прочее? Можешь использовать и их, это тоже стандартный способ C++.
Но лично я считаю потоки C++ ошибкой дизайна и стараюсь их избегать, благо доступны аналоги из C.

> Ну, т.к. пока я кодю только под винду
Лучше не вырабатывать вредные привычки, потом долго переучиваться будешь.

> мой компилятор не понимает даже команду "fork" из POSIX
Если тебе нужны потоки (thread), в C++ тоже есть стандартный способ, всякие специфичные вещи не нужны.

Кстати, CreateProcess — это тоже ошибка дизайна, делать из него нормальную обертку можно задолбаться.
У POSIX ситуация в этом смысле гораздо продуманней, но, к сожалению, форточки не поддерживают.

> пожалуй мне пока лучше остаться на винапи, чем пытаться для частных случаев пытаться дёргать функции из POSIX
Кстати, если уж где-то используется WinAPI, то хорошей практикой будет делать обертки и изолировать это в OS-специфичных файлах так, чтобы нигде ненароком не торчал #include <windows.h>.

А кодеров из M$ которые делали эти хедеры надо гнать вон из профессии с позором.

> Но это же подключать библиотеку... Не совсем голый получается.
Стандартная библиотека C++ подключена по умолчанию и входит в понятие "голый C++".

#81
0:33, 11 ноя. 2020

Не  считая, что ini это извращение по мне так, но если бы я что-то городил сам с чтением INI файлов, я бы как то так делал бы (Точнее я бы использовал модуль для работы с INI). Не знаю, насколько коряво, по быстрому накидал чего-то, но вроде читает парсит и вроде более или менее активно, из того, что потестил только что. Ну можно вместо copy использовать move побыстрее будет.
После первого чтения есть все данные для изменения файла. Куда нить это записать и обновлять по мере изменения, а апдейтить файл по типу WriteFile в нужных местах.

Код такой получился...

+ Показать


Получается что-то типа такого:

+ Показать

#82
0:42, 11 ноя. 2020

}:+()___ [Smile]
> Но лично я считаю потоки C++ ошибкой дизайна и стараюсь их избегать

Как концепция, или из за имплементации?

Страницы: 1 2 3 4 5 6
ПрограммированиеФорумОбщее