Т.е. без создания промежуточной структуры и копирования в неё данных вообще никак? )
А где тут статическая проверка корректности соответствия полей базы данных полям класса? )
НС>Какую работу? Вставку данных из какого то источника? Ты правда думаешь что у линка с базовым сценарием какие то проблемы? Или тебе интересно, можно ли к внешнему классу навесить метаданные? Можно. Но не нужно.
Я не сомневаюсь что можно сделать всё что угодно. Меня интересует вопрос какой ценой. Тем более, что ты же заявил что в C# (в отличие от C++) имеется в наличие "качественный доступ к БД"... )
_>>Вроде как абсолютно тривиальная задача НС>Тогда накой черт ты ее сюда притащил?
Так почему-то пока ни один любитель LINQ так и не привёл точного аналога этого самого моего тривиального кода.
НС>В 10 раз — сама формулировка "сохранение состояний" при работе с РСУБД — прекрасный способ прострелить себе ногу. Никогда так не делай. Работа с БД должна быть отдельно, а какие то классы, у которых совсем другое назначение — отдельно. SRP здесь особенно важен.
Если ты займёшься отмазками в стиле любителей продукции Apple (типа если у нас это не реализовано, то значит это и не нужная возможность), то смысла в нашей дискуссии не будет вообще.
A>Кстати, спорное преимущество. Вот вызываешь ты с виду безобидную функцию, а она фигакс и унутрях переключается на другой поток, а все твои thread locals оставляет в предыдущем. Например, errno.
Некоторые ограничения всё же есть, да. И желательно знать, или хотя бы представлять, что внутри делает и ожидает код, который будет прерываться yield'ом.
Кстати, например для Python'а есть gevent на базе корутин — она может на ходу патчить стандартные сокеты, так что код работающий с ними остаётся неизмененным. gevent
The example above used gevent.socket for socket operations. If the standard socket module was used it would took it 3 times longer to complete because the DNS requests would be sequential. Using the standard socket module inside greenlets makes gevent rather pointless, so what about module and packages that are built on top of socket?
That’s what monkey patching for. The functions in gevent.monkey carefully replace functions and classes in the standard socket module with their cooperative counterparts. That way even the modules that are unaware of gevent can benefit from running in multi-greenlet environment.
#!/usr/bin/python
# Copyright (c) 2009 Denis Bilenko. See LICENSE for details.
"""Spawn multiple workers and wait for them to complete"""
urls = ['http://www.google.com', 'http://www.yandex.ru', 'http://www.python.org']
import gevent
from gevent import monkey
# patches stdlib (including socket and ssl modules) to cooperate with other greenlets
monkey.patch_all()
import urllib2
def print_head(url):
print'Starting %s' % url
data = urllib2.urlopen(url).read()
print'%s: %s bytes: %r' % (url, len(data), data[:50])
jobs = [gevent.spawn(print_head, url) for url in urls]
gevent.joinall(jobs)
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>Пока не пытался, но мысль интересная. Особенно если вспомнить, дырка в программе на С++ — это дырка в одной программе, а дырка в .net фреймворке (кои находят регулярно) — это дырка в куче разных программ. С каким коэффициентом масштабировать будем?
Ну так и сравнивай дырку во фреймворке с дыркой в libc++ или STL Хотя я не понимаю, с чего это вдруг стремишься увести разговор в сторону инфраструктуры языков? Мы говорили о телодвижениях обеспечении защищенности кода в конечных приложениях их же разработчиками.
KV>>Потому что в коде на управляемом языке их совершать не нужно. ХГД>Что именно не нужно совершать на управляемом языке? Вот написано, например "не используйте кодировок кроме utf-8 без острой необходимости" — где здесь лишнее по сравнению с PHP телодвижение?
Т.е. совсем потерял контекст? Ок, я помогу восстановить: "лишними" я назвал телодвижения, описанные в разделе "C and C++ security" документа (http://cppcms.com/wikipp/en/page/secure_programming#C.and.C...Security). Собственно с этого началась вся ветка. О UTF-8 речь вообще не шла. Далее, ты заявил, что проверка UTF-8 на корректность является специфическим для веба телодвижением. Я возразил тебе, аргументировав тем, что во-первых ошибки обработки юникода в нативных приложениях имеют куда более серьезные последствия (нужно объяснять разницу между BoF в нативе и XSS в вебе?), а во-вторых тем, что мне и моим коллегам в ходе анализа нескольких сотен реальных и нетривиальных веб-приложений такие ошибки не встретились. Твою дальнейшую реакцию на это я прокомментировал в предыдущем сообщении.
По делу и в рамках контекста обсуждения — есть что возразить?
Здравствуйте, Хон Гиль Дон, Вы писали:
ХГД>То что тут продемонстрировано, сильно напоминает Image: it1261567955.jpg и прочие продукты творчества скучающих сисадминов.
Не знаю читал ли ты все тут понаписанное, но совершенно очевидно, что общее недоумение вызывает не то, что он делает, а то почему он это делает.
Здравствуйте, Sheridan, Вы писали:
S>Проблема в том, что они не говорят, они навязывают. Даже после того что я говорю им что это скорее хобби. Это вторая проблема: они видимо не могут понять что программирование на с++ может быть хобби. У них в головах профессиональные цепочки действий для реализации проетов выстраиваются. А мне эти цепочки неинтересны. S>Это как если бы я начал коллекционировать марки, а все вокруг начали мне навязывать коллекционирование значков. Мне глубоко пофиг, мне марки нравятся.
Если б так и было тебе б никто и слова не сказал. Но ты же обычно начинаешь с утверждений типа "я сделаю быстрый и качественный код".
ХГД>>Пока не пытался, но мысль интересная. Особенно если вспомнить, дырка в программе на С++ — это дырка в одной программе, а дырка в .net фреймворке (кои находят регулярно) — это дырка в куче разных программ. С каким коэффициентом масштабировать будем?
KV>Ну так и сравнивай дырку во фреймворке с дыркой в libc++ или STL
В STL дырки, внезапно, находят значительно реже. Потому что он на порядок проще фреймворка. И libc++ тоже.
KV>Хотя я не понимаю, с чего это вдруг стремишься увести разговор в сторону инфраструктуры языков? Мы говорили о телодвижениях обеспечении защищенности кода в конечных приложениях их же разработчиками.
Ну и, что тут может предпринять разработчик, для обеспечения защищенности конечного приложения? Примерно ничего, то есть таки можно сидеть на попе ровно?
KV>Т.е. совсем потерял контекст? Ок, я помогу восстановить: "лишними" я назвал телодвижения, описанные в разделе "C and C++ security" документа (http://cppcms.com/wikipp/en/page/secure_programming#C.and.C...Security). Собственно с этого началась вся ветка. О UTF-8 речь вообще не шла. Далее, ты заявил, что проверка UTF-8 на корректность является специфическим для веба телодвижением.
Акценты чуть другие. Я имел в виду следующее — все что ты назвал лишним, и так общее место при программировании на C++, кроме utf-8, которую таки да, вне веба проверять на корректность никто не приучен. И, собственно, я бы хотел получить пояснения именно про якобы "лишнее", безотносительно юникода, так как ничего лишнего, по сравнению с более опасными стилями программирования на С++, там не заметил.
KV> Я возразил тебе, аргументировав тем, что во-первых ошибки обработки юникода в нативных приложениях имеют куда более серьезные последствия (нужно объяснять разницу между BoF в нативе и XSS в вебе?), а во-вторых тем, что мне и моим коллегам в ходе анализа нескольких сотен реальных и нетривиальных веб-приложений такие ошибки не встретились. Твою дальнейшую реакцию на это я прокомментировал в предыдущем сообщении.
Отлично, только я про них не спрашивал и они меня мало интересуют, ибо давно известно откуда что берется и как с этим бороться. Если есть страшилки, специфичные для utf-8 — с интересом выслушаю.
KV>По делу и в рамках контекста обсуждения — есть что возразить?
Я так понял, по поводу "лишних телодвижений" я никакой конкретики не дождусь?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, genre, Вы писали:
G>Если б так и было тебе б никто и слова не сказал. Но ты же обычно начинаешь с утверждений типа "я сделаю быстрый и качественный код".
Я говорил что сделаю его быстро?
Здравствуйте, genre, Вы писали:
ХГД>>То что тут продемонстрировано, сильно напоминает Image: it1261567955.jpg и прочие продукты творчества скучающих сисадминов.
G>Не знаю читал ли ты все тут понаписанное, но совершенно очевидно, что общее недоумение вызывает не то, что он делает, а то почему он это делает.
Очевидно же — скучно человеку. Что в этом странного или необычного? С тем же успехом мог бы игрушечные мотоциклы из деталей хардов собирать
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
G>>Если б так и было тебе б никто и слова не сказал. Но ты же обычно начинаешь с утверждений типа "я сделаю быстрый и качественный код". S>Я говорил что сделаю его быстро?
Не быстро, а быстрый. Ты говорил, например вот это
Здравствуйте, Хон Гиль Дон, Вы писали:
G>>Не знаю читал ли ты все тут понаписанное, но совершенно очевидно, что общее недоумение вызывает не то, что он делает, а то почему он это делает. ХГД>Очевидно же — скучно человеку. Что в этом странного или необычного? С тем же успехом мог бы игрушечные мотоциклы из деталей хардов собирать
Так. Еще раз. Дело не в том, что он делает, а зачем он это делает.
Писать сайты на с++ если очень хочется — да пожалуйста.
Писать сайты на с++ потому что хочется написать максимально быстрый код сборки страницы — глупо.
Здравствуйте, Хон Гиль Дон, Вы писали: ХГД>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Ну так и сравнивай дырку во фреймворке с дыркой в libc++ или STL ХГД>В STL дырки, внезапно, находят значительно реже. <...> И libc++ тоже.
Кто и на какой выборке сравнивал?
ХГД>Ну и, что тут может предпринять разработчик, для обеспечения защищенности конечного приложения? Примерно ничего, то есть таки можно сидеть на попе ровно?
"Тут" это где? В своем коде?
ХГД>Акценты чуть другие. Я имел в виду следующее — все что ты назвал лишним, и так общее место <b>при программировании на C++</b>
Дык именно, что при программировании на С++. Я не утверждал о том, что С++ программист был бы вынужден совершать лишние телодвижения, занимаясь разработкой веб-приложений, по сравнению с десктопными. Я утверждал, что разработка веб-приложения на С++ с точки зрения обеспечения защищенности требует больше телодвижений, чем оная, например, на C#. Просто в силу того, что там нет необходимости думать о провисании указателей, следить за переполнениями буферов, кучи, целочисленных типов, форматных строк (если их кто-то еще использует), разыменованиями нулевых указателей и т.п.
Конкретно же с юникодом вышла непонятка: ты (и процитированный гайд по защищенности) говорите об угрозе появления в UTF-8 строках последовательностей байт, не предусмотренных стандартом. Я же почему-то решил, что мы говорим о недостаточной обработке кодировок, в результате которой в код может прилететь строка большего размера, чем выделенный под нее буфер. Тут моя неправда, признаю: то, о чем говорил ты, действительно характернее для веба, либо сетевых приложений, активно работающих с текстовыми форматами всевозможной разметки.
ХГД>Если есть страшилки, специфичные для utf-8 — с интересом выслушаю.
Вообще все известные мне внезапности, связанные с обработкой юникода (в т.ч. и в плане появления в строках некорректных последовательностей) собраны, как ни странно на unicode.org: http://www.unicode.org/reports/tr36/
, ну и мне лень весь тред перекапывать, где-то там было еще про производительность.
У тебя аналогии вообще не выстраиваются, надо пояснять? В данном контексте "быстрый" == "качественно" помимо остального. На всякий случай поясню и это: "остальное" == "надёжно, красиво, понятный код итд"
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>>Ну так и сравнивай дырку во фреймворке с дыркой в libc++ или STL ХГД>>В STL дырки, внезапно, находят значительно реже. <...> И libc++ тоже.
KV>Кто и на какой выборке сравнивал?
Я, на выборке майкрософтовских фиксов для .Net framework и CRT.
ХГД>>Ну и, что тут может предпринять разработчик, для обеспечения защищенности конечного приложения? Примерно ничего, то есть таки можно сидеть на попе ровно?
KV>"Тут" это где? В своем коде?
Да где угодно, включая такие телодвижения, как написать в ООН и Майкрософт.
ХГД>>Акценты чуть другие. Я имел в виду следующее — все что ты назвал лишним, и так общее место <b>при программировании на C++</b>
KV>Дык именно, что при программировании на С++. Я не утверждал о том, что С++ программист был бы вынужден совершать лишние телодвижения, занимаясь разработкой веб-приложений, по сравнению с десктопными. Я утверждал, что разработка веб-приложения на С++ с точки зрения обеспечения защищенности требует больше телодвижений, чем оная, например, на C#. Просто в силу того, что там нет необходимости думать о провисании указателей, следить за переполнениями буферов, кучи, целочисленных типов, форматных строк (если их кто-то еще использует), разыменованиями нулевых указателей и т.п.
А, всего то. С этим бы и спорить не стал. Хотя даже такая формулировка не вполне соответствует текущему положению дел, в C++ в большинстве случаев есть выбор, писать безопасно или не очень. И из перечисленных проблем (при выборе в пользу безопасности) следить приходится разве что за переполнением целочисленных типов и буферов (в библиотеки пока не всё загнали, постоянно приходится велосипеды писать).
ХГД>>Если есть страшилки, специфичные для utf-8 — с интересом выслушаю.
KV>Вообще все известные мне внезапности, связанные с обработкой юникода (в т.ч. и в плане появления в строках некорректных последовательностей) собраны, как ни странно на unicode.org: http://www.unicode.org/reports/tr36/
Да, любопытно. При этом, значительная часть из них применима и к скриптовым/управляемым языкам.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Дык именно, что при программировании на С++. Я не утверждал о том, что С++ программист был бы вынужден совершать лишние телодвижения, занимаясь разработкой веб-приложений, по сравнению с десктопными. Я утверждал, что разработка веб-приложения на С++ с точки зрения обеспечения защищенности требует больше телодвижений, чем оная, например, на C#. Просто в силу того, что там нет необходимости думать о провисании указателей, следить за переполнениями буферов, кучи, целочисленных типов, форматных строк (если их кто-то еще использует), разыменованиями нулевых указателей и т.п.
С одной стороны можно применять различные техники на C++ чтобы снизить вероятность всех этих проблем — например автоматическая runtime проверка границ диапазонов (внутри типа), безопасные типы а-ля safe_int вместо встроенных и т.д и т.п. С другой стороны все эти же проблемы есть и в C#, как минимум из-за наличия unsafe секций.
Но, справедливости ради, если взять сферическую среднестатистическую программу на C++ и сравнить её с аналогом на C# — то в первом случае всех этих угроз будет больше.
Тем не менее, если говорить с точки зрения "абсолютной" безопасности — мала вероятность появления уязвимости определённого рода, или нет — не так важно, главное что эта вероятность не нулевая.
В этом плане, как мне видится, код использующий внутри какие-то опасные конструкции должен помечаться так, чтобы тот кто его использовал сразу бы видел это.
Например Haskell-евская монада IO — если где-то внизу call-tree кто-то делает ввод/вывод — то об этом будет знать даже корень дерева, и никак не сможет проигнорировать (есть конечно хак unsafePerformIO — но представим что его нет).
Если говорить в терминах C# — то код использующий внутри unsafe, по-хорошему должен показывать это в своей сигнатуре, и каждый кто его вызывает транзитивно подцепляет эту заразу. То есть все небезопасные конструкции должны оставлять какой-то транзитивный след, причём желательно дифференцировано, т.е. у каждого типа конструкции свой отпечаток.
Здравствуйте, genre, Вы писали:
ХГД>>Да, есть кстати и другие причины писать сайты на С++
G>например.
Ты не поверишь — в ряде случаев это может быть проще и дешевле
Например, у нас есть коробочный продукт — некая числомотилка. Под винду, написана на плюсах. Надо к ней запилить вебморду. Твой выбор?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
EP>Тем не менее, если говорить с точки зрения "абсолютной" безопасности — мала вероятность появления уязвимости определённого рода, или нет — не так важно, главное что эта вероятность не нулевая. EP>В этом плане, как мне видится, код использующий внутри какие-то опасные конструкции должен помечаться так, чтобы тот кто его использовал сразу бы видел это. EP>Например Haskell-евская монада IO — если где-то внизу call-tree кто-то делает ввод/вывод — то об этом будет знать даже корень дерева, и никак не сможет проигнорировать (есть конечно хак unsafePerformIO — но представим что его нет). EP>Если говорить в терминах C# — то код использующий внутри unsafe, по-хорошему должен показывать это в своей сигнатуре, и каждый кто его вызывает транзитивно подцепляет эту заразу. То есть все небезопасные конструкции должны оставлять какой-то транзитивный след, причём желательно дифференцировано, т.е. у каждого типа конструкции свой отпечаток.
И если мы вдруг захотим сделать маленькое быстрое unsafe-ядро. 500 раз проверим его силами кучи экспертов, и они сделают заключение что дыр нет. Но потом все равно придется знать во всей программе, что у нас все unsafe? Тоже не очень здорово.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Хотя я не понимаю, с чего это вдруг стремишься увести разговор в сторону инфраструктуры языков? Мы говорили о телодвижениях обеспечении защищенности кода в конечных приложениях их же разработчиками.
