Хорошие правила. Есть еще одно - всегда оставайся мастером-любителем... Мастера профессионалы теряют нюх и страх и приобретают пофигизм. Что приводит к жутким косякам иногда. Где любитель 7 раз перепроверит, перечитает инструкции, перестрахуется - мастер зафигачит разом и уверенно. без сомнений. повезет будет работать долго, нет - случится факап. А так мой код живет 25+ лет уже... и 5 лет я его не трогаю тк отошел от дел.
если честно, то во всяких кроссплатформенных либах чем меньше обращений к системным функциям и проще реализация тем лучше. логи может и некуда писать. возвернуть код ошибки это самое простое. в приличных либах бывает и два варианта - исключения и коды ошибок.
ну тут кому как. все вот молятся на исключения в С++, а для меня это только лишний гемор всегда был. Ну вот пишу я библиотеку в которой использую библиотеку работающую с исключениями... так для меня главная задача все эти исключения перехватить и дальше не выпустить тк пользователь в LabView например совсем не ожидает получить исключение, а скорей errcode от вызова функции. С++ тем и хорош что многогранен в своем применении и при этом совместим между ними.
ну это лечится и техническими средствами и стилем программирования. Как пример вот есть Arduino String - живут с ним. есть гайды как правильно его использовать чтобы меньше алокаций и меньше фрагментация. Есть улучшенные реализации. И это С++ в мелких микроконтроллерах. Для линукса ну тоже гайд нужен, профилирование и code review. В конечном итоге продвинутые альтернативные драйвера могут лежать в отдельной папке и использоваться по желанию пользователя, а дальше время рассудит.
а чем new то плох? его реализацию просто нужно правильную. в Numega new был свой типа new(NonPagedPool) new(PagedPool) и там были закопаны функции выделения памяти для ядра...
в библиотеке гугл это библиотекарь... если он хороший, то даст подсказку для выборки иначе это почти тупик или тяжелый труд по одной книге смотреть другие используемые книги итд. ручной перебор каталога...
так давно пришло время отделить ядро от драйверов и снять оковы в выборе языков программирования для драйверов. ну вернее ядро + ряд системных драйверов, а дальше стандартизованное api подсистем и твори на чем хочется. далеко не все драйвера для linux включены в состав ядра и живут сами по себе.
ядро windows nt вроде как тоже на С, но оно написано так что не блокирует использование компилятора C++. Это позволило в свое время компании Numega создать набор классов DriverStudio для более легкого написания драйверов для windows на С++ и все прекрасно работало. Более того в то время для ядра линукс был патч который позволял использовать С++, но понятное дело его никуда не приняли. так что-то тут в линуксе диктатура какая-то - сказали С и Rust и все... остальные свободны.Так-то никто не претендует на код ядра и основных подсистем, но почему нельзя драйвера писать на других языках непонятно - если они фиговые будут их не примут пользователи и перепишут на С там или Rust.
это к какой части коммент? у меня все на чисто интуитивном уровне - когда я выбираю инструмент для работы я опираюсь на прошлый опыт. и если новый инструмент логично и легко ложится в руки, то это годнота. иначе фуфуфу. сейчас правда тяжелей стало - все новые инструменты делают специально сильно непохожими на старые чтобы сформировать новую свою экосистему, придать ей уникальность и значимость.
ну я как писавший на turbovision паскале и owl на с++ считаю что wxwidgets наиболее близок к борландовскому стилю библиотек. еще я драйвера писал на NuMega DriverStudio кучу лет - там тоже правильный стиль был. А псоледний драйвера уже пришлось писать переписывать на WDF это ближе к MFC по мне... но я старался сгладить свой дискомфорт.
в этом и беда нейросетей. если убрать вот это "рассказываю и показываю как человек с опытом", то нейросеть будет выдавать решения на скудный человеческий опыт студента... при этом классический поиск выдавал гораздо больший объем информации который содержал кроме запрашиваемой еще и кучу около информации как пищу для размышлений... расширял кругозор и обучал фактически. Если коротко, то нейронка это что спросил то и ответили, а поиск это вот тебе куча - тут что-то похожее и еще всякое, смотри сам.
Borland против Microsoft это TurboVision/OWL против MFC. А не паскаль потив С++,C#... тут главное в стиле программирования и написании библиотек, а не языки. Как началось размывание стиля борландистов так они и сдали позиции. А размывать его стали чтобы перетянуть больше программистов с MFC, которых затягивали в .NET. Сейчас я считаю wxWidgets последним оплотом борландистов., ну и freepascal.
ну вообще раньше это был практически стандарт упаковки всех hdd. как пошли емкости приличные. в 90х пакетики, потом с 2000 в коробочках пластиковых, а когда опять на пакетики перешли я не знаю - лет 10 точно диски не покупал...
Хорошие правила. Есть еще одно - всегда оставайся мастером-любителем... Мастера профессионалы теряют нюх и страх и приобретают пофигизм. Что приводит к жутким косякам иногда. Где любитель 7 раз перепроверит, перечитает инструкции, перестрахуется - мастер зафигачит разом и уверенно. без сомнений. повезет будет работать долго, нет - случится факап. А так мой код живет 25+ лет уже... и 5 лет я его не трогаю тк отошел от дел.
если честно, то во всяких кроссплатформенных либах чем меньше обращений к системным функциям и проще реализация тем лучше. логи может и некуда писать. возвернуть код ошибки это самое простое. в приличных либах бывает и два варианта - исключения и коды ошибок.
ну так их надо не забыть в нужном месте.
ну тут кому как. все вот молятся на исключения в С++, а для меня это только лишний гемор всегда был. Ну вот пишу я библиотеку в которой использую библиотеку работающую с исключениями... так для меня главная задача все эти исключения перехватить и дальше не выпустить тк пользователь в LabView например совсем не ожидает получить исключение, а скорей errcode от вызова функции. С++ тем и хорош что многогранен в своем применении и при этом совместим между ними.
хотя я возможно отстал. и можно с++ собрать.
ну это лечится и техническими средствами и стилем программирования. Как пример вот есть Arduino String - живут с ним. есть гайды как правильно его использовать чтобы меньше алокаций и меньше фрагментация. Есть улучшенные реализации. И это С++ в мелких микроконтроллерах. Для линукса ну тоже гайд нужен, профилирование и code review. В конечном итоге продвинутые альтернативные драйвера могут лежать в отдельной папке и использоваться по желанию пользователя, а дальше время рассудит.
а чем new то плох? его реализацию просто нужно правильную. в Numega new был свой типа new(NonPagedPool) new(PagedPool) и там были закопаны функции выделения памяти для ядра...
в библиотеке гугл это библиотекарь... если он хороший, то даст подсказку для выборки иначе это почти тупик или тяжелый труд по одной книге смотреть другие используемые книги итд. ручной перебор каталога...
так это драйвер на С соберется... мои драйвера все out of tree были. а С++ так не пойдет.
это сильно заморочиться с билд системой надо...
portio на с++ через numega гораздо красивей и проще был. wdf что-то среднее по итогу.
так давно пришло время отделить ядро от драйверов и снять оковы в выборе языков программирования для драйверов. ну вернее ядро + ряд системных драйверов, а дальше стандартизованное api подсистем и твори на чем хочется. далеко не все драйвера для linux включены в состав ядра и живут сами по себе.
ядро windows nt вроде как тоже на С, но оно написано так что не блокирует использование компилятора C++. Это позволило в свое время компании Numega создать набор классов DriverStudio для более легкого написания драйверов для windows на С++ и все прекрасно работало. Более того в то время для ядра линукс был патч который позволял использовать С++, но понятное дело его никуда не приняли. так что-то тут в линуксе диктатура какая-то - сказали С и Rust и все... остальные свободны.Так-то никто не претендует на код ядра и основных подсистем, но почему нельзя драйвера писать на других языках непонятно - если они фиговые будут их не примут пользователи и перепишут на С там или Rust.
это да. Turbo pascal 5.5 Professioanl с MenuMaker... и дальше понеслось.
это к какой части коммент? у меня все на чисто интуитивном уровне - когда я выбираю инструмент для работы я опираюсь на прошлый опыт. и если новый инструмент логично и легко ложится в руки, то это годнота. иначе фуфуфу. сейчас правда тяжелей стало - все новые инструменты делают специально сильно непохожими на старые чтобы сформировать новую свою экосистему, придать ей уникальность и значимость.
ну я как писавший на turbovision паскале и owl на с++ считаю что wxwidgets наиболее близок к борландовскому стилю библиотек. еще я драйвера писал на NuMega DriverStudio кучу лет - там тоже правильный стиль был. А псоледний драйвера уже пришлось писать переписывать на WDF это ближе к MFC по мне... но я старался сгладить свой дискомфорт.
в этом и беда нейросетей. если убрать вот это "рассказываю и показываю как человек с опытом", то нейросеть будет выдавать решения на скудный человеческий опыт студента... при этом классический поиск выдавал гораздо больший объем информации который содержал кроме запрашиваемой еще и кучу около информации как пищу для размышлений... расширял кругозор и обучал фактически. Если коротко, то нейронка это что спросил то и ответили, а поиск это вот тебе куча - тут что-то похожее и еще всякое, смотри сам.
Borland против Microsoft это TurboVision/OWL против MFC. А не паскаль потив С++,C#... тут главное в стиле программирования и написании библиотек, а не языки. Как началось размывание стиля борландистов так они и сдали позиции. А размывать его стали чтобы перетянуть больше программистов с MFC, которых затягивали в .NET. Сейчас я считаю wxWidgets последним оплотом борландистов., ну и freepascal.
ну вообще раньше это был практически стандарт упаковки всех hdd. как пошли емкости приличные. в 90х пакетики, потом с 2000 в коробочках пластиковых, а когда опять на пакетики перешли я не знаю - лет 10 точно диски не покупал...
там, это у trassir? hi3536c