Обнуляется не весь буффер, только если длина строки короче, чем нужно было скопировать символов.
If, after copying the terminating null character from src, count is not reached, additional null characters are written to dest until the total of count characters have been written.
Всё зависит от использования. Обычно обнуление очень удобно. Если у вас строка записалась не полностью или вообще не записалась, вы всегда можете глянуть, где она закончится. Многие наоборот считают, что новый интерфейс не интуитивен. Я его не использую, ибо в большинстве UNIX он отсутствует.
Я привёл ссылку http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm в эссе. strcat_s() и strcpy_s() как раз не особо полезны, в C99 ввели 'n' функции: strncat() и strncpy(). Существенная разница в том, что 's' функции не используют errno, а возвращают код ошибки. Это было бы хорошо, если б не совместимость и усложение прототипов. Очень сложный вопрос, что лучше.
Windoпроблемы. ;-) Ни в ISO C11, ни в POSIX они не deprecated ни в коей мере. Более того, не знаю, как в новой версии VC, а ещё недавно порядок параметров в прототипы MS функций не был совместим с Annex K из C11. То есть MS продвинули свои safe функции в ISO C, но парни из комитета взяли и сделали версии функций, не совместимые вообще ни с одной существующей реализацией! В общем, такие дела.
Вы, видимо, пишете скринсейверы для iOS, если бы вы писали в Mac OS X визуальный редактор для численных рассчётов с использованием кроссплатформенных C / C++ либ с сотнями функций, вы были бы иного мнения. Бридж — не нативная поддержка.
Но писать на ObjC ради того что можно подключать с++ либу это выглядит крайне странно, потому что это крайне редкий.
Что, что простите? Вы, серьёзно? Вообще говоря, многие крупные (и не очень) проекты пишутся по следующей схеме: низкоуровневые функции — C, модель — С++, контроллеры и интерфейс — Objective-C. И городить переходники для сотен вызовов — вот это странно. Собственно, целевая аудитория у Swift — прогеры игр (причём не блещущих физикой и графикой, либо пищущих движки с нуля) и небольших iOS приложений. Apple уже не знает, чем ещё привлечь людей, скоро вообще на радость школьникам на HTML перейдут.
Приводить все примеры из Annex K бесполезно, ибо он почти нигде не реализован, и где мы взяли код ошибки: из errno, или вернули из функции — не принципильно.
In long: с научной позиции оно так и получается. В научном подходе теория объективно считается лучше, если она задействует меньше специальных случаев и исключений. Чем меньше изначальных аксиом, тем лучше. Приветствуется универсальность — чем шире область применения, тем лучше. Теория языков программирования — вполне математична и формальна, и к ней применимы все те же нормы. Причины этих явлений, я сдесь излагать не буду, ибо боюсь соврать, но они вполне объективы, и хорошо изложены у Карла Поппера и Дэвида Дойча.
Возвращаясь к нашим баранам, можно сказать, что парадигма основанная на наследовании — всего лишь частный случай прототипной парадигмы. Просто ввели один специальный вид объектов с особыми свойствами, классы. Вопрос чистоты вполне объективен, и не имеет отношения ни к удобству, ни к бедности. А считать ли концепцию удобной или бедной — дело вкуса и привычки.
ООП в базовом виде состоит всего лишь из двух постулатов:
всё есть объект
объекты взаимодействуют через посылку сообщений
Всё прочее, включая классы, не более чем приятное дополнение. Увы, C++ слишком исказил восприятие многих людей.
Существует две главные парадигмы в ООП: основанная на наследовании (class based) и прототипах (prototype based). В первой к общей идее добавили третий пункт:
всё есть объект
объекты взаимодействуют через посылку сообщений
объекты являются экземплярами классов
Обе они взаимозаменямы, каждую из них можно эмулировать через другую. Но прототипная считается более 'чистой' ибо обходится меньшим числом пунктов. Примером её реализации является язык Self (ну и повсеместно известный JavaScript). Ну и к вопросу, озвученному в статье: после изложенного должно быть очевидно, что пытаться обойтись одной композицией (иными словами эмулировать прототипы) на языке, использующем наследование будет несколько некомфортно. Вот и всё.
Можно ссылку на репу? Интересно глянуть. Вообще проблема, ибо longjmp() не умеет прыгать 'в никуда', ей нужен конкретный буфер с сохранённой средой. Значит, эти буферы в общем случае должны быть глобальными и уникальными. И их нужно генерить неким автоматическим способом (препроцессором?). Я ещё не изучал существующие реализации, мож попробую напишу свою.
Я считаю, что в клиентском коде (обычной юзерской проге) не нужно. Я умеренный противник исключений, ибо они прерывают обычный поток выполнения, что противоречит принципу структурного программирования. Но в системном программировании они могут быть очень полезны. Приведённый Вами пример хорош, пока у вас throw прямо в блоке try, а если оно во вложенном вызове функции и в другом файле — придётся сильнее изловчиться.
Подробнее:
http://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions
http://stackoverflow.com/questions/2169016/mac-solution-for-safe-alternatives-to-unsafe-c-c-standard-library-function
https://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx
strcat_s()иstrcpy_s()как раз не особо полезны, в C99 ввели 'n' функции:strncat()иstrncpy(). Существенная разница в том, что 's' функции не используют errno, а возвращают код ошибки. Это было бы хорошо, если б не совместимость и усложение прототипов. Очень сложный вопрос, что лучше.Что, что простите? Вы, серьёзно? Вообще говоря, многие крупные (и не очень) проекты пишутся по следующей схеме: низкоуровневые функции — C, модель — С++, контроллеры и интерфейс — Objective-C. И городить переходники для сотен вызовов — вот это странно. Собственно, целевая аудитория у Swift — прогеры игр (причём не блещущих физикой и графикой, либо пищущих движки с нуля) и небольших iOS приложений. Apple уже не знает, чем ещё привлечь людей, скоро вообще на радость школьникам на HTML перейдут.
In short: авторами ООП концепции.
In long: с научной позиции оно так и получается. В научном подходе теория объективно считается лучше, если она задействует меньше специальных случаев и исключений. Чем меньше изначальных аксиом, тем лучше. Приветствуется универсальность — чем шире область применения, тем лучше. Теория языков программирования — вполне математична и формальна, и к ней применимы все те же нормы. Причины этих явлений, я сдесь излагать не буду, ибо боюсь соврать, но они вполне объективы, и хорошо изложены у Карла Поппера и Дэвида Дойча.
Возвращаясь к нашим баранам, можно сказать, что парадигма основанная на наследовании — всего лишь частный случай прототипной парадигмы. Просто ввели один специальный вид объектов с особыми свойствами, классы. Вопрос чистоты вполне объективен, и не имеет отношения ни к удобству, ни к бедности. А считать ли концепцию удобной или бедной — дело вкуса и привычки.
Они и не пришли им на смены, а создали новые ниши. Lisp, Haskell, Erlang и C живут в своих.
Всё прочее, включая классы, не более чем приятное дополнение. Увы, C++ слишком исказил восприятие многих людей.
Существует две главные парадигмы в ООП: основанная на наследовании (class based) и прототипах (prototype based). В первой к общей идее добавили третий пункт:
Обе они взаимозаменямы, каждую из них можно эмулировать через другую. Но прототипная считается более 'чистой' ибо обходится меньшим числом пунктов. Примером её реализации является язык Self (ну и повсеместно известный JavaScript). Ну и к вопросу, озвученному в статье: после изложенного должно быть очевидно, что пытаться обойтись одной композицией (иными словами эмулировать прототипы) на языке, использующем наследование будет несколько некомфортно. Вот и всё.
longjmp()не умеет прыгать 'в никуда', ей нужен конкретный буфер с сохранённой средой. Значит, эти буферы в общем случае должны быть глобальными и уникальными. И их нужно генерить неким автоматическим способом (препроцессором?). Я ещё не изучал существующие реализации, мож попробую напишу свою.Я считаю, что в клиентском коде (обычной юзерской проге) не нужно. Я умеренный противник исключений, ибо они прерывают обычный поток выполнения, что противоречит принципу структурного программирования. Но в системном программировании они могут быть очень полезны. Приведённый Вами пример хорош, пока у вас throw прямо в блоке try, а если оно во вложенном вызове функции и в другом файле — придётся сильнее изловчиться.