Получать они могут что угодно и сколько угодно. Вопрос о надежность системы. Вот пусть кто-то систему и взломает с копией глаза с 12 или 3 метров. Пока что это мимо темы все.
memcpy не нужны байты? malloc не выделяет байты? Не надо самого себя обманывать. Нужна всем этим функциям конкретная информация из этого указателя. Вы длинной то что передаете? Правильно, сколько байтов. Ваш же пример — функция работает с байтами, она делает каст даже специально внутри себя. То что вы рекомендуете в этом случае void* это не более чем дань тому, что принято в С. По всем остальным объективным причинам там должен быть массив char, uint8_t или еще чего, как это сделано у других, кто смог позволить себе уйти от С прошлого.
то хоть немного знает C и не я не понимаю, почему вы считаете его «каким-то непонятным
То что он известен и понятен не делает его заведомо хорошим и правильным. И аргумент в пользу void* тогда должен звучать как «так причин и известно остальным, так принято в языке», а не выдумать аргументы, который, по сути, ложны.
Вот это единственный реальный аргумент в пользу void* — переносимость на странные платформы. Что до malloc и free — их сигнатура так же не соответствует тому, что она делает. Эти функции выделяю и освобождают память, которая измеряется в байтах. И если для free это вопрос реального удобства, то malloc это реально функция для работы с байтами. Как и все mem* функции. Просто так повелось и пошло поехало, а современный подход использовать именно четкое намерение — функции нужен массив байт, она это и показывает. Но у них и проблем нет — байт всегда байта и в 8 бит
Вы читали ссылку то? Цель исследования достичь идентификации на расстоянии. Это значит компромиссные решения, высокая степень ошибки и т.д. Нет никаких причин, чтобы система идентификации не работала в таком разрешении, что расстояние для работы с ней нужно намного намного меньшее. Я не знаком конечно с темой, но есть подозрения, что оно именно так и есть. Если вы найдете ссылку, что с 12 метров получили снимок, который дает доступ в топовую систему безопасности, вот тогда да, это будет уместный пример.
Это вы идеальном мире смена пароля что-то там решает. Что мы имеем в мире реальном? Простые пароли 123 на всю жизнь на все сервисы. Поэтому здесь это шаг вперед в безопасности и удобстве пользования.
Вообще сам код говорит, что ему важно какой тип. Ему нужны байты. Так и передавайте байты, а не указатель на ничего. Мне как раз запись вида void* всегда не нравилась. Функция ожидает кусок памяти, память у нас считается в байтах. Так с какого она прячет свои намерения за каким-то непонятным void*? И то что надо делать каст скорее как раз плюс, потому что четко показывает намерение. И практически во всех современных API дело обстоит именно так. Взять тех же ближайших родственников ObjC и С++
Он разве лекции по С дает? Даже больше, насколько он вообще активно собственно написанием кода сейчас занимается? И насколько он реально качественный. Гугл мне не помог с ответом.
Биометрия глаз будет по-лучше. И таки дает шаг вперед. Даже пальчики в сравнении с суровой реальность простых паролей и одинаковых везде тоже шаг вперед. + удобство пользователя.
Разработчики утверждают, что такой способ в 10 раз безопаснее дактилоскопического сканера.
Не утверждают. Судя по тексту, надеются и верят, не более.
А технология не вызывает доверия. Какие-то мутные алгоритмы, эвристики, анализы, чтобы попасть в аккаунт. В сравнении с двухфакторной авторизацией, не нужно получается даже пароля. Заполучил телефон=заполучил доступ к аккаунтам. Ведь информация не успеет так быстро измениться до той степени, что перестанет пускать.
Ну это. Нехороший администратор LDAP? По сути, это уже конец всякой защиты. Я с тем же успехом могу взять чужой аккаунт, поменять пароль и ходить куда мне вздумается. Патч защитой то не назовешь. Поэтому комментарии разработчиков gitlab не удивляют.
А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
Это большая свобода и большая ответственность, но уж лучше так, чем сражаться с языком когда доходишь до предела его возможностей и натыкаешься на невидимую стену из багов или ограничений производительности.
Лучше я сам буду рулить памятью чем сборщик мусора будет фризить мою прогу когда ему вздумается, и мне виднее когда память выделять а когда освобождать.
В случае Си мне всегда понятно что оно делает и как, никаких махинаций за ширмой, никакого волшебства, нюансы конечно есть но их довольно мало в сравнении с языками которые на себя берут заметно больше.
Ох уж эти контрол фрики. Подобные рассуждения обычно свойственны, простите уж, мало опытным программистам. Они вечно хотят все контролировать, все делать сами, знать обо всем на свете. Я помню по себе, когда в ObjC с ручного управления памяти перешли на автоматический подсчет ссылок. И аргументы для самого себя у меня были теже самые — нафиг мне это надо, лучше я сам буду все делать, сам буду знать, что там творится и как. Если что сломается, то сам и починю. В какой-то момент просто приходит озарение.
Низкий уровень Си является огромным его минусом и всегда таким будет. Минусом это перестает быть только тогда, когда задача требует этого. Именно требует. Ядро ОС требует. Драйвера требуют. Игры — игры автора никаким местом не требуют. Это просто прихоть автора, ничем объективно не обоснованная. А вот игры ААА уровня, особенно для консолей — требуют. Но там Си никому не нужен, используют С++. Последний, собственно, нормально подойдет и для ОС с драйверами. Например, Apple для драйверов выбрала С++ и ООП интерфейс developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html#//apple_ref/doc/uid/TP0000012-TPXREF101
Что до линукса, то смотря на их забавные попытки, по сути, реализовать C++ на Си в той же VFS, то там тоже не видно причин не использовать С++. Просто Линус против, да и время сыграло свою роль. В то время компиляторы вполне возможно могли быть не так хороши.
И вряд ли предоставит. Студия это не конструктор для сообщества. Это самодостаточный продукт. Рослин всяко внедрен в систему настолько, что отключить просто так его не получится. А делать это ради решарпера… Пусть решарпер вот и крутится, он плагин. Не может — его проблема. Делайте свою IDE. Мне понятна сторона разработчика плагина, что ему все мешает, но это абсурд.
Эм, а вы думали там любого дурачка в олимпиадника превращают? Задача факультета таких детей выявить и развить их потенциал. Насчет неплохо, скажите это соперникам университета. Они готовят неплохо, а ИТМО уже множество раз занимает первые места
Основной принцип ООП — это то, что мы работем не с функциями и данными, а с данными, заключенными в объект ВМЕСТЕ с методами, которые эти данные обрабатывают.
Ну тогда все еще проще. Go прям православный ООП язык.
И теперь наверняка начнет падать, потому что рослин много чего умеет сам. Крайний в любом случае решарпер. Продукт свой МС вольна делать так, как захочет. Хочется улучить анализ кода своими силами — их право, пользователи только в выигрыше. Ведь основная часть аудитории таки решарпером не пользуется.
Судя по тому, что я слышал от собственно родителей, ситуация со школами там идентичная. Детей не учат каким-то практическим знаниям, а дают академические знания. Я после получения подобного обучения могу сказать только спасибо, что давали и то, и другое, но больше именно академического. На счет практики, мы в школе в фотошопе на информатике рисовали и очень рад этому до сих пор. При чем со слоями, использованием эффектов, фильтров, рендеринга и т.п. Не приходится с нуля осваивать такой сложный инструмент. Для меня сейчас выглядит важнее именно то, что дали знания. Это позволило освоить практику правильно и не с пустой головой. Зато как печально видеть этих горе практиков, которые не понимают элементарных вещей того, что они делают.
Еще как поощрается, только в своих терминах, которые тем не менее покрывают принципы ООП. Опять начинаются эти придирки к словам вместо того, чтобы смотреть на суть вещей. В Go есть объекты, есть интерфейсы, есть иерархии (да, немного не такие, к каким мы привыкли, те менее есть). Поощрается взаимодействие между ними. Более того, на нем никак иначе и писать невозможно.
Что до раста, то беглый просмотр в гугле приводит к выводу, что Rust мультипарадигменный язык, в том числе и объектно-ориентированный. Это просто не копия какого-то другого языка.
Опять эта тема. Является он объектно-ориентированным, потому что покрывает все его принципы. Это тоже самое, что smalltalk и С++. Последний не обязан быть SmallTalk, чтобы быть ООП языком. Тоже самое с Go — это другой язык, но инкапсуляцию, наследование и полиморфизм своими фичами он вполне покрывает. Именно в этом определение ООП языков и не надо тут выдумывать науку из этого целую.
То что он известен и понятен не делает его заведомо хорошим и правильным. И аргумент в пользу void* тогда должен звучать как «так причин и известно остальным, так принято в языке», а не выдумать аргументы, который, по сути, ложны.
Не утверждают. Судя по тексту, надеются и верят, не более.
А технология не вызывает доверия. Какие-то мутные алгоритмы, эвристики, анализы, чтобы попасть в аккаунт. В сравнении с двухфакторной авторизацией, не нужно получается даже пароля. Заполучил телефон=заполучил доступ к аккаунтам. Ведь информация не успеет так быстро измениться до той степени, что перестанет пускать.
А так, в настройках LDAP можно использовать фильтры, чтобы ограничить аутентификацию по принадлежности к какой-то группе, что собственно у нас и сделано.
Ох уж эти контрол фрики. Подобные рассуждения обычно свойственны, простите уж, мало опытным программистам. Они вечно хотят все контролировать, все делать сами, знать обо всем на свете. Я помню по себе, когда в ObjC с ручного управления памяти перешли на автоматический подсчет ссылок. И аргументы для самого себя у меня были теже самые — нафиг мне это надо, лучше я сам буду все делать, сам буду знать, что там творится и как. Если что сломается, то сам и починю. В какой-то момент просто приходит озарение.
Низкий уровень Си является огромным его минусом и всегда таким будет. Минусом это перестает быть только тогда, когда задача требует этого. Именно требует. Ядро ОС требует. Драйвера требуют. Игры — игры автора никаким местом не требуют. Это просто прихоть автора, ничем объективно не обоснованная. А вот игры ААА уровня, особенно для консолей — требуют. Но там Си никому не нужен, используют С++. Последний, собственно, нормально подойдет и для ОС с драйверами. Например, Apple для драйверов выбрала С++ и ООП интерфейс developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html#//apple_ref/doc/uid/TP0000012-TPXREF101
Что до линукса, то смотря на их забавные попытки, по сути, реализовать C++ на Си в той же VFS, то там тоже не видно причин не использовать С++. Просто Линус против, да и время сыграло свою роль. В то время компиляторы вполне возможно могли быть не так хороши.
Ну тогда все еще проще. Go прям православный ООП язык.
Что до раста, то беглый просмотр в гугле приводит к выводу, что Rust мультипарадигменный язык, в том числе и объектно-ориентированный. Это просто не копия какого-то другого языка.