readline() читает текущую строку до символа конца строки. Т.е. если файл заканчивается пустой строкой, то readline() должен вернуть пустую строку. Если файл заканчивается ьремя пустыми строками, то readline () должен три раза вернуть пустую строку. Заглядывать на символ вперед, или искать конец файла после символа пустой строки readline не должен. Подумайте о случае, когда ваш файл - это com-port, например (/dev/serial0) . В этом случае символа конца файла вообще может не быть. И readline(), если попытается считать данные после пустой строки, просто зависнет, т.к. данные еще не пришли. И в этом случае вы всегда будете получать последнюю строку, только когда прийдет следующий символ.
А в чем проблема? Он на Qt, и достаточно часто используется в самом kde. В KIO, например. Есть ui диалог для него, что бы прогресс показывать, ну и т.п.
gettext это ниже уровнем. и работает только на nix'ах. У qt для перевода сделан свой кроссплатформенный подфреймворк. Достаточно удобно в использовании.
Какой-то велосипед, прям. Это ИМХО, без обид. Реализация модульности на dll не очень удобна. Потом как это в кучу собирать на целевую платформу? Мейнтейнер повесится))
Уже много лет работаю с Qt. Ни разу не сталкивался с проблемой компиляции на Windows. Еще не понял про низкий порог вхождения. Qt — это c++ фреймворк. Если хорошо знаешь и понимаешь c++ и ООП, то нет проблем. А если не знаешь… Знаю людей, которые учили c++ с использованием Qt. В итоге человек потом не понимает, где у него фреймворк, а где нет))) Открывает потом для себя c++ и stl заново))
По теме статьи:
readline() читает текущую строку до символа конца строки. Т.е. если файл заканчивается пустой строкой, то readline() должен вернуть пустую строку. Если файл заканчивается ьремя пустыми строками, то readline () должен три раза вернуть пустую строку. Заглядывать на символ вперед, или искать конец файла после символа пустой строки readline не должен. Подумайте о случае, когда ваш файл - это com-port, например (/dev/serial0) . В этом случае символа конца файла вообще может не быть. И readline(), если попытается считать данные после пустой строки, просто зависнет, т.к. данные еще не пришли. И в этом случае вы всегда будете получать последнюю строку, только когда прийдет следующий символ.
А почему при чтении используется readline(), вместо потокового ввода? Это же c++? Логично сразу учить студентов корректно работать с потоковым вводом.
cmake не страшно. Как и современный qt. Все рано придется осваивать, рано или поздно))
Есть. Посмотрите KItemViews
А в чем проблема? Он на Qt, и достаточно часто используется в самом kde. В KIO, например. Есть ui диалог для него, что бы прогресс показывать, ну и т.п.
Билдить весь kde не придется, только kcoreaddons. Он из tier1, зависит только от qt. Ну и от extra-cmake-modules. Под винду собирается.
KJob вам в помощь)) https://api.kde.org/frameworks/kcoreaddons/html/classKJob.html
ИМХО: занимаетесь велосипедостроением.
kdiff3?
gettext это ниже уровнем. и работает только на nix'ах. У qt для перевода сделан свой кроссплатформенный подфреймворк. Достаточно удобно в использовании.
AutoCAD заменить на FreeCAD. Представляю боль в глазах конструкторов))
Очередная HR расширяет список контактов)))
Когда слышу про вовлеченность, аж глаз дергается. А что вы делаете, если сотрудник хорошо справляется с задачами, но не вовлечен?
Да, в vector инициализация происходит в аллокаторе, но что мешает поставить свой аллокатор без инициализации?
http://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665
Нет, не будет. Есть конструктор без инициализации. Ну или можно конструктор по умолчанию использовать.
Какой-то велосипед, прям. Это ИМХО, без обид. Реализация модульности на dll не очень удобна. Потом как это в кучу собирать на целевую платформу? Мейнтейнер повесится))
Васю жалко. Все мы немного Вася…
Интересно. Надо попробовать.