Если udp датаграмму послать, то да, она физически уйдёт в сеть, независимо от того, есть ли у нее получатель. Собственно, отправитель даже не узнает, получил ее кто-то или нет.
И да, если много получателей то экономичнее бросать широковещательными, но это только в рамках локалки. Фильтры броадкасты в глобальную сеть не выпустят.
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть. Любой, кто завладеет характеристиками может их запомнить и логиниться на всех сайтах, куда мы ходим. Тоесть биометрия может выступать разве что дополнением к какому-то другому средству аунтефикации.
Вопрос: «Аффинное преобразование по трем точкам на плоскости»
А почему получается, что для выполнения алгоритма нужны три точки, Ведь для восстановления преобразования достаточно двух? Что будет, если выходной треугольник, который я задам будет неравен/неподобен входному?
В этой статье присутствует ложная дихотомия функционального программирования и ООП. Эти подходы совершенно не исключают друг-друга.
Совсем непонятно про наследование. В каком месте функциональное программирование отменяет концепцию наследования???
Функциональное программирование позволяет получить строгий вывод в терминах объектов. Функциональная парадигма в части своей основной идеи интуитивна ничуть не менее кошечек и собачек.
Я думаю, в конечном итоге zencad тоже будет сопрягать два изделия, совмещая определенные ЛСК (собственно, он уже почти так делает). Но конечно, вместо названий будет прямое указание, что и куда ставить. Названия — это не для скриптов.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
Язык си может быть обработан интерпретатором.
И это не будет нарушением стандарта.
Собственно, я думаю, причина всех этих минусов в том, что вы в своём посте включили компилятор в язык.
Язык он сферический в вакууме. Стандарт создан, конечно, с расчетом на то, как именно язык будут использовать, но записан он очень оторвано от реализации.
Завтра у нас появится транслятор, скармливающий программы на языке в надмашинный мирровой квазигипермозг, который посмотрев на код будет без всякой компиляции сразу выдавать результат выполнения…
Так все и было. Сначала был один компилятор. Потом их стало три. Каждый со своими правилами. И тогда вместо одного языка стало три. Умные дяди почесали затылки и выкатили стандарт на язык. Именно на язык, а не на конкретный компилятор.
И сказали так: О, Компиляторы! Вы цари и боги, и вольны делать все что хотите, покуда не нарушаете стандарт, иначе несоответствующими стандарту заклеймлены будете.
Таким образом, стандарт — это, конечно, просто бумажка. Но компилятор должен этой бумажке соответствовать. Для того она и существует.
Я имею сказать по этому поводу. Эволюции надо рассматривать в долгосрочной перспективе. Неэфективные решения эволюционно нестабильны. Через миллион лет все может поменяться.
На самом деле, никто не мешает написать myprintf напрямую через write. Это будет прекрасно работать. Можно даже обойтись без glibc совсем. Но glibc предлагает решение среднее по больнице, которое подходит в 98% случаев. И да, оно зачастую избыточно, но работает как часы…
Тут есть два момента. Во первых puts работает с буфферизацией, то есть прежде чем выдать что-то во внешний мир, он сбрасывает данные в буффер, копит их там, а потом уже выдаёт все разом. Это делается для минимизации количества системных вызовов в частности и операций в пространстве ядра — драйверах вообще.
Но это пол беды. Логика работы с буфером находится в динамической библиотеке, доступ к которой пользовательская программа имеет через таблицу указателей на функции.
Вот и получается, что мы сначала делаем jump в динамическую либу, потом кидаем данные в буффер… И, только если левая пятка сподобится, вызываем write…
Насколько такая цепочка оправдана… Вопрос открытый.
И да, если много получателей то экономичнее бросать широковещательными, но это только в рамках локалки. Фильтры броадкасты в глобальную сеть не выпустят.
Идея с биометрией плохо применима в интернете. Нужно передавать биометрические характеристики в сеть. Любой, кто завладеет характеристиками может их запомнить и логиниться на всех сайтах, куда мы ходим. Тоесть биометрия может выступать разве что дополнением к какому-то другому средству аунтефикации.
Не могу не поделиться этой видюшкой :):
Это, конечно, вообще не основное назначение zencad, но такое тоже можно.
P.S. Версия zencad 1.0 постепенно выходит на финишную прямую. Месяца через два-три, полагаю, можно будет торжественно объявить релиз.
Выглядит впринципе неплохо, но все равно не взлетит.
А почему получается, что для выполнения алгоритма нужны три точки, Ведь для восстановления преобразования достаточно двух? Что будет, если выходной треугольник, который я задам будет неравен/неподобен входному?
Совсем непонятно про наследование. В каком месте функциональное программирование отменяет концепцию наследования???
Функциональное программирование позволяет получить строгий вывод в терминах объектов. Функциональная парадигма в части своей основной идеи интуитивна ничуть не менее кошечек и собачек.
По поводу np.array: В дальнейшем я вообще постараюсь убрать или спрятать поглубже слассы vector и point. Будем как раз с np.array работать. Мне кажется, это в духе питона и удобно для использования стороннего софта.
И это не будет нарушением стандарта.
Собственно, я думаю, причина всех этих минусов в том, что вы в своём посте включили компилятор в язык.
Язык он сферический в вакууме. Стандарт создан, конечно, с расчетом на то, как именно язык будут использовать, но записан он очень оторвано от реализации.
Завтра у нас появится транслятор, скармливающий программы на языке в надмашинный мирровой квазигипермозг, который посмотрев на код будет без всякой компиляции сразу выдавать результат выполнения…
И это никак не повлияет на сам язык.
Так все и было. Сначала был один компилятор. Потом их стало три. Каждый со своими правилами. И тогда вместо одного языка стало три. Умные дяди почесали затылки и выкатили стандарт на язык. Именно на язык, а не на конкретный компилятор.
И сказали так: О, Компиляторы! Вы цари и боги, и вольны делать все что хотите, покуда не нарушаете стандарт, иначе несоответствующими стандарту заклеймлены будете.
Таким образом, стандарт — это, конечно, просто бумажка. Но компилятор должен этой бумажке соответствовать. Для того она и существует.
Но это пол беды. Логика работы с буфером находится в динамической библиотеке, доступ к которой пользовательская программа имеет через таблицу указателей на функции.
Вот и получается, что мы сначала делаем jump в динамическую либу, потом кидаем данные в буффер… И, только если левая пятка сподобится, вызываем write…
Насколько такая цепочка оправдана… Вопрос открытый.