Не думаю, чтобы у кого-то часто читающего код на С++ первый вариант вызывал какие-то сомнения. Скорее второй избыточен для этого конкретного случая.
А если оно в коде достаточно активно используется - я бы вообще вынес это дело в отдельную функцию, где этот случай проще будет отлавливать и дебажить, если что.
iljaGolubev, ты нагородил ерунды, тебя ткнули носом.
Вместо того, чтобы задуматься, ты оскорбился и продолжаешь тупить и спорить.
Нам, собственно, и не впилось тебя воспитывать. Хочешь быть дураком - да пожалуйста. Не хочешь быть дураком - посмотри на ответы и на код еще пару раз, прежде чем кричать "не верно" - может, дойдет, о чем речь.
iljaGolubev, вероятно, в этом случае в коде, скорее всего, будет полезно последнее из значений, возвращенных getClientIps - и логично поставить его первым.
Выделяешь мышкой теги к вопросу, гуглишь, сразу попадаешь на страницу со списком функций РНР для работы с датой и временем. Сначала ищешь те, которые сделают всю работу за тебя, потом отчаиваешься, включаешь голову и находишь парочку, которых достаточно для этих архисложных вычислений.
Antony, в хэллоуворд можно парой строчек всобачить использование STL с ошибкой - и красочность ругани gcc по дебрям шаблонов затмит даже сборку ядра ;)
Кстати, заодно избавляемся от необходимости build clean :)))
writer_2159, лучше просто не хвататься за первое, что пришло в голову, и не разводить шифрование там, где вы же сами будете вынуждены его похерить ради поиска по этому полю.
Навешивание замков - это не безопасность. Безопасность - это когда удобно всем, кому можно, и невозможно тем, кому нельзя. Про первую часть слишком часто забывают, и это приводит к тому, что старательно выстроенное исключительно по второй - не работает.
/dev/random довольно быстро обрывает вывод cat - то ли нулевым значением, то ли одним из служебных, не разбирался.
А для циклической пересборки совершенно ни к чему тягать такие тяжести, как ядро, хэллоуворд будет крутиться ничуть не хуже.
writer_2159, цимес как раз в том, что ключ должен лежать тут же, на сервере, раз вы собрались на нем же делать расшифровку. И вся затея лишается смысла.
Елена, нет, отчего же. Вполне возможны полностью статические сайты, которым не нужно от сервера ничего, кроме открытия предварительно сверстанных страниц по ссылке.
Но, судя по упоминанию CMS, фреймворков и конструкторов, вам нужны совсем другие технологии.
Мысль такая: шифрование данных на сервере, которому эти самые данные нужны расшифрованными, подобно хитрому замку, рядом с которым на гвоздике висит ключ.
