По идее, женщин с макияжем должно, в принципе распознавать хуже.
Изменение формы глаз и бровей, например, асимметрии, тоже.
Кстати говоря, небольшая подтяжка глаз и бровей, условно говоря тонкими нитками (а-ля волос), будет существенно изменять рисунок лица в контрольных точках. И она абсолютно незаметна.
Эта хрень очень напоминает то, на чем мы пытались писать в школе алгоритмы.
(Грустно) Россия страна изобретателей велосипедов.
Хотите графический язык? Это называется FBD. На нем программируют промышленные контроллеры. Хотите сложнее? Есть LabView, которому ваша Дракон и в пометки не годится.
Но принципиально ничего не меняется. Пока программист не в теме, и не обладает знаниями в предметной области, такие вещи будут повторяться. Ни одна система программирования не является экспертной системой, чтобы ловить алгоритмические ошибки
Очень интересно послушать, что про результаты автоматизации говорит персонал. А то на бумаге гладко выглядит. Но вот захотелось ночному клиенту сосисок. А аппарат не работает.
И что насчёт безопасности? Облако вещь чудесная, пока интернет есть. Да и хакеры не дремлют.
Чтобы автоматизировать объект повышенной опасности через облако надо ОЧЕНЬ крепко подумать
Отсутствие полноценного описания ошибок, возникающих при использовании данного продукта, делает его использование крайне рисковым. Только для любительских поделок. Например, если с удаленной камерой пропадает связь, процесс можно только убить. Ни на какие команды входного потока ffmpeg не реагирует. Вопросы о некоторых ошибках годами висят на разных форумах без ответа. Как обычно. Сделан продукт — мучайтесь с ним сами. Задавать вопросы некому.
Во-первых, голосование за комметарий должно быть открытое. А во-вторых, каждый плюс или минус необходимо обосновывать, т.е комментировать. И за флуд в этих комментариях — наказывать. Таким образом голосующие несут ответственность за выбор. И естественным образом "не читал, но осуждаю" выставляется на всеобщее обозрение.
Т.е не нравится комментарий, нажимаешь на минус и пишешь обоснование ниже розового цвета. Нравится- нажимаешь плюс и пишешь слова поддержки салатового цвета. Нейтрально- серого. Таким образом — дискуссии укорачиваются. И взаимная вежливость улучшается. В теории
Проблема с файлом подкачки следующая: он занимает дефицитное место. Например на компьютере установлено 16 Гб ОЗУ. А накопитель SSD 120Гб. Что у нас по умолчанию получится? 16 Гб с накопителя долой. И ещё 16 Гб отожрет гибернация. Четверть накопителя (причем честных гигабайт, а не десятичных) занята, можно сказать, впустую.
Вы удивитесь, но под Labview я тоже пишу многопоточные приложения, причем любой цикл, включающий хоть один вызов функции, АВТОМАТИЧЕСКИ оформляется потоком. Но это не отменяет последовательную обработку ошибок внутри потока, существенно упрощая ее восприятие.
Вам ведь знакома система контроля ошибок в Labview. Про какой стек вы говорите? Внутри функции проверяется входная ошибка. Классический входной контроль. Обработчик ошибок, если вообще есть или нужен, выполняется в конце потока. И можно быть уверенным в том, что последовательность операций внутри потока будет выполнена всегда, независимо от ошибок. Это тоже бывает очень важно. И сильно влияет на качество программного кода.
В пределах однопоточного последовательно выполняемого кода ЗАЧЕМ try catch городить для обработки пользовательских (имеется в виду ошибок, определяемых разработчиком функции) ошибок? Вот ответ на какой вопрос я пытаюсь получить.
событийность я вижу в том, что в момент формирования ошибки выполнение функции прерывается и управление переходит в секцию catch, минуя весь последующий код. В результате чего очень геморройно встраивать в код вещи, которые должны быть выполнены независимо от пользовательских ошибок вызываемых функций. Я уж не говорю про то, что при обертывании try catch большого объема кода, больше одного вызова функции, теряется информация о источнике исключения.
зачем каждый раз оборачивать в try catch, если надо просто проверить ошибку выполнения функции? Какой в сакральный смысл в событийности для последовательного выполнения?
Хорошо. А если вам надо проигнорировать определенную ошибку (с конкретным кодом) на выходе func_B? т.е продолжить выполнение следующих функций. А остальные обработать.
Версии Labview выходят каждые пол-года. Сначала релиз, потом с сервис-паками. Поэтому с COBOL не сравнивайте. Сообщество разработчиков насчитывает не менее сотни тысяч человек. Это лучшая система разработки для автоматизации производства, является промышленным стандартом в США. Ближайший к нему Сименс, но по удобству проектирования он катастрофически проигрывает.
За счет того, что обработка исключений реализована на уровне среды разработки и выполнения. А формат информации об ошибке не отдан на откуп разработчику ПО, а интегрирован в экосистему начиная с самого нижнего уровня. В любом месте, НЕ ПРЕРЫВАЯ ВЫПОЛНЕНИЯ, ошибку можно 1. зафиксировать ее факт. 2. выполнить действия 3. описать ее 4. сбросить, установить, скопировать. И что самое главное, прозрачно отдать на верхний уровень. И быть уверенным в том, что ее верхний уровень однозначно сможет обработать. И все это используя одну структуру. Эта структура является базовой конструкцией, такой-же, как и вещественные и строчные типы. Программист только ее заполняет нужными данными. Единое соглашение, в отличие от зоопарка, характерного для более гибких языков.
Поэтому в случае, если ID клиента не найден, я просто заполняю данную структуру с кодом ошибки и возвращаю как результат выполнения функции. Защищенные секции не требуются. Следующая функция может даже не знать (и не обязана знать), что там перед ней должно было быть вызвано, она вначале проверяет — есть ли входная ошибка или нет. Если нет ошибок, то выполняется основной код. И так далее по цепочке. В конце функционального блока можно посмотреть, была ли ошибка и какая. И решить, что с ней делать.
Это просто другой подход к программированию.
Изобрели его еще в 90-х. Как минимум версия Labview 4.0 в 1995 году работала с таким обработчиком ошибок. Причем с тех пор в неизменном виде.
Можете минусить сколько угодно. Странно только, что вы недовольны тем, что что-то просто существует. И главное спорить с тем, что десятилетиями используется.
Ну вы хоть для начала поинтересуйтесь, что из себя представляет система разработки LabView. А потом теории выдвигайте. Вы бы еще разработчикам под Step7 эти претензии предъявляли.
Проблемы, которые вы описываете, отсутствуют как класс в данных средах. Потому что разработчики хорошо поработали над этим велосипедом.
Изменение формы глаз и бровей, например, асимметрии, тоже.
Кстати говоря, небольшая подтяжка глаз и бровей, условно говоря тонкими нитками (а-ля волос), будет существенно изменять рисунок лица в контрольных точках. И она абсолютно незаметна.
Эта хрень очень напоминает то, на чем мы пытались писать в школе алгоритмы.
(Грустно) Россия страна изобретателей велосипедов.
Хотите графический язык? Это называется FBD. На нем программируют промышленные контроллеры. Хотите сложнее? Есть LabView, которому ваша Дракон и в пометки не годится.
Но принципиально ничего не меняется. Пока программист не в теме, и не обладает знаниями в предметной области, такие вещи будут повторяться. Ни одна система программирования не является экспертной системой, чтобы ловить алгоритмические ошибки
Очень интересно послушать, что про результаты автоматизации говорит персонал. А то на бумаге гладко выглядит. Но вот захотелось ночному клиенту сосисок. А аппарат не работает.
И что насчёт безопасности? Облако вещь чудесная, пока интернет есть. Да и хакеры не дремлют.
Чтобы автоматизировать объект повышенной опасности через облако надо ОЧЕНЬ крепко подумать
Отсутствие полноценного описания ошибок, возникающих при использовании данного продукта, делает его использование крайне рисковым. Только для любительских поделок. Например, если с удаленной камерой пропадает связь, процесс можно только убить. Ни на какие команды входного потока ffmpeg не реагирует. Вопросы о некоторых ошибках годами висят на разных форумах без ответа. Как обычно. Сделан продукт — мучайтесь с ним сами. Задавать вопросы некому.
Во-первых, голосование за комметарий должно быть открытое. А во-вторых, каждый плюс или минус необходимо обосновывать, т.е комментировать. И за флуд в этих комментариях — наказывать. Таким образом голосующие несут ответственность за выбор. И естественным образом "не читал, но осуждаю" выставляется на всеобщее обозрение.
Т.е не нравится комментарий, нажимаешь на минус и пишешь обоснование ниже розового цвета. Нравится- нажимаешь плюс и пишешь слова поддержки салатового цвета. Нейтрально- серого. Таким образом — дискуссии укорачиваются. И взаимная вежливость улучшается. В теории
Проблема с файлом подкачки следующая: он занимает дефицитное место. Например на компьютере установлено 16 Гб ОЗУ. А накопитель SSD 120Гб. Что у нас по умолчанию получится? 16 Гб с накопителя долой. И ещё 16 Гб отожрет гибернация. Четверть накопителя (причем честных гигабайт, а не десятичных) занята, можно сказать, впустую.
А вы можете сделать прошивку с минимальными задержками в передаче изображения и с интерфейсом GigE Vision? А также с честным WDR?
Вам ведь знакома система контроля ошибок в Labview. Про какой стек вы говорите? Внутри функции проверяется входная ошибка. Классический входной контроль. Обработчик ошибок, если вообще есть или нужен, выполняется в конце потока. И можно быть уверенным в том, что последовательность операций внутри потока будет выполнена всегда, независимо от ошибок. Это тоже бывает очень важно. И сильно влияет на качество программного кода.
error = func_A(a);
if (!error)
{ error = func_B(v);
if (!error)
{error = func_C©
if (!error)
{error = func_D()}
}}}
Тогда как предлагается
func_A(a, error);
func_B(v, error);
func_C(c, error);
func_D(error);
if (error->status) { printf («ошибка код %d, расшифровка %s», error->code, error->source) }
void func_B(int a, t_error *error)
{ if (!(error->status))
{
…
if (a == 0) {error->status = true; error->code = 232; error->source = «операнд равен нулю»; return}
}
}
что лучше? писать кучу «бесполезных» ifов в коде или вынести проверку в функцию?
Поэтому в случае, если ID клиента не найден, я просто заполняю данную структуру с кодом ошибки и возвращаю как результат выполнения функции. Защищенные секции не требуются. Следующая функция может даже не знать (и не обязана знать), что там перед ней должно было быть вызвано, она вначале проверяет — есть ли входная ошибка или нет. Если нет ошибок, то выполняется основной код. И так далее по цепочке. В конце функционального блока можно посмотреть, была ли ошибка и какая. И решить, что с ней делать.
Это просто другой подход к программированию.
Можете минусить сколько угодно. Странно только, что вы недовольны тем, что что-то просто существует. И главное спорить с тем, что десятилетиями используется.
Проблемы, которые вы описываете, отсутствуют как класс в данных средах. Потому что разработчики хорошо поработали над этим велосипедом.