PS: я пользовал lexertk, но в силу объективных причин смотрю в сторону spirit, так как при работе с последним не нужно плясать с бубном вокруг выражений типа function(value1, function2(value8, function3()))
На тех курсах что проходил я, не было чисто бухгалтерского направления.
Как рекомендация было: можете почитать соответствующую литературу, все кейсы на рабочем коде было видно и объяснялось на видео (естественно услышав новое словечко типа проводка, фифо и тд и тп — лезешь гуглить...)
Я прошёл(почти до конца!) курсы по 1С, уже будучи программистом С++, пару лет назад.
Может 1С действительно не для всех, в частности и для меня тоже:
вроде бы и улавливаешь суть, но какое-то странное чувство дискомфорта было на всём протяжении обучения, бросил на 5-ом месяце…
Ну а по поводу спасти мир и всё такое: кто ж против то? :)
Мне так всё это видится:
NULL всё таки больше подходит для указателей, так же как 0 для целочисленных типов. DWORD — это двойное слово, слово — 16бит(2байта) — имеем 32битное целое число, для которого лучше пользовать 0, нежели NULL.
Опять же, если упорно доказывать самому себе и окружающим, что NULL можно использовать везде в том числе и для целочисленных типов, то вас (не имею ввиду ИМЕННО ВАС) никто не будет закидывать гнилыми помидорами, но взгляните на этот код, и скажите, радует ли он ваш глаз/привычно ли оно выглядит:
int count = NULL;
Случай же с INVALID_HANDLE_VALUE на входе в CreateFileMappingA, скорее означает инициализацию, то есть первоначальное состояние; при возврате NULL — возврат есть ничто ( зачастую в Си такая практика: если указатель нулевой при возврате, — проверяй errno)
Александр, огромный вам респект! С интересом ждём новостей по данной теме!..
1) не хочу навязывать, сам частенько грешу написанием прототипов в текстовом редакторе (хоть и навороченном), но IDE будет удобнее для подобной разработки (какой-нибудь codeblocks например).
2) посмотрел скрины в ВК, там файл исходников ядра перевалил за 15K строк, — не оч удобно на мой взгляд. Раскидайте функционал по файликам (с соответствующими функционалу именами), продумайте архитектуру для своего проекта: типа в папке drivers — драйвера, в core — ядро ОС, utils — всякие вспомогательные ф-ии…
Делать и использовать нужно то, что подходит под требования проекта.
Вот именно !
А по всем остальным пунктам, касательно моего быдлокодерства (не заморочился с потоко-безопасностью, сделал хранение массива чисел в строке потому что в SOCI нет этой поддержки, борюсь с диалектами SQL) отвечу:
всё что я посчитал нужным осветить в данной статье — я осветил,
если вам не нравится как я подготовил этот tutorial — ну на вкус и цвет как говорится ))
По моему небольшому опыту, сама идея встраивания SQL-подобного кода в С++ программу в конечном итоге заканчивается спуском к деталям реализации конкретной БД и вызову конкретных функций коннектора этой БД.
Ок. Мы вас слушаем, что нужно делать, что использовать, и почему нужно использовать именно то что вы предлагаете, а не какую-нибудь зрелую библиотеку, которая даёт гибкость в работе...
Напишите статью "я против всяких ORM библиотек, я за чистый SQL", киньте ссылку, и мы будем в курсе раз и навсегда ))
PS: советую перепрочитать статью, я её переработал, возможно в том виде в каком вы её читали, не дала вам ясных представлений...
А ещё есть разработчики, которые навыдумывают тысячу ПРОТИВ,
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))
Поместите ссылку на проект в конце статьи.
PS: я пользовал lexertk, но в силу объективных причин смотрю в сторону spirit, так как при работе с последним не нужно плясать с бубном вокруг выражений типа function(value1, function2(value8, function3()))
Битовая идентификация токенов — интересный подход.
Сам сейчас читаю доки по boost::spirit, для DSL, так как нет свободного времени для «написать с нуля и разобраться во всём самому» :)
Как рекомендация было: можете почитать соответствующую литературу, все кейсы на рабочем коде было видно и объяснялось на видео (естественно услышав новое словечко типа проводка, фифо и тд и тп — лезешь гуглить...)
Может 1С действительно не для всех, в частности и для меня тоже:
вроде бы и улавливаешь суть, но какое-то странное чувство дискомфорта было на всём протяжении обучения, бросил на 5-ом месяце…
Ну а по поводу спасти мир и всё такое: кто ж против то? :)
Мне так всё это видится:
NULL всё таки больше подходит для указателей, так же как 0 для целочисленных типов. DWORD — это двойное слово, слово — 16бит(2байта) — имеем 32битное целое число, для которого лучше пользовать 0, нежели NULL.
Опять же, если упорно доказывать самому себе и окружающим, что NULL можно использовать везде в том числе и для целочисленных типов, то вас (не имею ввиду ИМЕННО ВАС) никто не будет закидывать гнилыми помидорами, но взгляните на этот код, и скажите, радует ли он ваш глаз/привычно ли оно выглядит:
Случай же с INVALID_HANDLE_VALUE на входе в CreateFileMappingA, скорее означает инициализацию, то есть первоначальное состояние; при возврате NULL — возврат есть ничто ( зачастую в Си такая практика: если указатель нулевой при возврате, — проверяй errno)
PS: nullptr был ведён в с++11 ))
1) не хочу навязывать, сам частенько грешу написанием прототипов в текстовом редакторе (хоть и навороченном), но IDE будет удобнее для подобной разработки (какой-нибудь codeblocks например).
2) посмотрел скрины в ВК, там файл исходников ядра перевалил за 15K строк, — не оч удобно на мой взгляд. Раскидайте функционал по файликам (с соответствующими функционалу именами), продумайте архитектуру для своего проекта: типа в папке drivers — драйвера, в core — ядро ОС, utils — всякие вспомогательные ф-ии…
Вопрос: каким компилятором пользуетесь?
Не нашёл имени Amy Troschinetz в списке разработчиков.
Много всяких решений существует, каждый выбирает своё ...
Вот именно !
А по всем остальным пунктам, касательно моего
быдлокодерства
(не заморочился с потоко-безопасностью, сделал хранение массива чисел в строке потому что в SOCI нет этой поддержки, борюсь с диалектами SQL) отвечу:всё что я посчитал нужным осветить в данной статье — я осветил,
если вам не нравится как я подготовил этот tutorial — ну на вкус и цвет как говорится ))
Ок. Мы вас слушаем, что нужно делать, что использовать, и почему нужно использовать именно то что вы предлагаете, а не какую-нибудь зрелую библиотеку, которая даёт гибкость в работе...
Напишите статью "я против всяких ORM библиотек, я за чистый SQL", киньте ссылку, и мы будем в курсе раз и навсегда ))
PS: советую перепрочитать статью, я её переработал, возможно в том виде в каком вы её читали, не дала вам ясных представлений...
Мир — большой, и полон удивительных вещей! И он не ограничивается тремя берёзками в густом смешанном лесу…
Я — есть я, не потому что я на какой-то там стадии, всё проистекает из личности…
ЛОЛ...
Никогда не замечал, всегда читал Соци ))
Может поэтому она не популярна в РФ ?..
По поводу версии сделал замечание в тексте статьи — качать свежие сырцы.
Незакрытые задачи по большей части всплывают из-за желания юзеров юзать из коробки
очень специфичные вещи.
А для LOB'ов юзайте стандартный API soci::blob:
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))
Да вы правы, если пользовать ветку 4.*, но ссылку я дал на 3.2.3, а там такого нет ))
Я сделаю правку в тексте, спасибо!
в проде нужен доступ по HTTP, инженер стал пилить свою либу, за одно запилил поддержку SSL/TLS…