Павел Остапенко @mt_
User
Information
- Rating
- Does not participate
- Location
- Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Chief Technology Officer (CTO)
Optimization of business processes
Development management
Mentoring
FullStack
Agile
Только что написал статью, посвящённую идеологии управления ресурсов в U++. За счёт неё удаётся побеждать всю или почти всю головную боль с утечками памяти.
Pick- называю более «привычным» термином «разрушающее копирование» в 4 пункте, попутно разбирая семантику этого действия в нашем контексте. В одной из предыдущих статей меня поправили, что, пользуясь необщепринятыми понятиями, я путаю аудиторию. Тогда я перевёл всё на стандартный язык.
Отсюда, ваш подход — вполне возможно, хорош внутри вашего специфического объекта (максимум — пула объектов). Что касается программ «с птичьего полёта» — то подход другой.
Хочу только заметить, что здесь важнее само соглашение. Иначе, Вы прекрасно сами понимаете: есть 100500 способов обойти любую константность и прочее, сделав всё что угодно.
А так же, моя библиотека сверхбезопасной многопоточности на sequential processes.
Извините, не удержался.)
В остальном — просто не хочу оффтопить. И гуй, и поддержка всего от быстрых контейнеров до SSL, там не просто есть, а очень сильно есть. )
В нашем случае, оно сводится к тому, что, получив (выкрав) исходники, злоумышленник узнает алгоритм генерации «соли» и сведёт задачу к достаточно простой вычислительной задаче: GPU-перебору словарь + известная соль.
Первый шаг сделан: яваскрипт постепенно превращается из интерпретируемого языка в компилируемый.
Дальше — вопрос логики и новых редакций стандартов.
Вот где действительно развернётся будущая битва за производительность.
И здесь бы, пожалуй, помог отказ от классической синхронизации потоков с использованием мьютексов и прочих семафоров. Для браузерного программирования более адекватным будет параллельное программирование через обмен сообщениями между объектами, работающими в разных потоках. Это, конечно, создаёт не только возможности, но и сопутствующие проблемы.
С одной стороны, де-факто отсутствие разделяемой памяти упростит расширение на сколь угодно большое количество ядер. С другой стороны, появляется масса проблем, связанных как с самим подходом (задержки и прочее), так и увязкой этого с визуализацией DOM. Похоже, это дело браузеров будущего.
Очевидно, что они не тетрис там пишут.
Вирус — вполне очевидное оружие любой современной армии.
С моей точки зрения, в следующей статье было бы неплохо как раз обсудить этот новый язык разметки, который «рендерится» в CSS/HTML.
И теперь мой к Вам вопрос: с чем Вы предлагаете сравнивать? Какие у нас есть альтернативы, по сравнению с которыми мы могли бы назвать данные технологии сравнительно бесполезными, либо сравнительно полезными?
К примеру, ВАЗ 2106 следует оценивать не только по неким характеристикам, но и сравнительно. Когда у меня не было никакой машины, и ВАЗ решал мне массу проблем (разумеется, создавая массу новых). Но при этом всём, был сравнительно полезным. Когда у меня появилась иномарка, те же задачи стали решаться с гораздо меньшим количеством проблем. ВАЗ 2106 стал сравнительно бесполезен и был продан.
Мы же взрослые люди, уважаемый автор. Давайте исходить из реальности.
Вы считаете что HTML/CSS — плохи?
Предлагайте альтернативы. Давайте их обсуждать.
Причём обсуждать в реальном комплексе проблем, связанных с необходимостью менять инфраструктуру крупными корпорациями и т.д.
Речь идёт о двух совершенно разных процессах. С одной стороны — аберрация хромосом, с другой — димеризация нуклеотидов. Причём аберрация хромосом происходит под воздействием других механизмов, например появления сильнейших свободных радикалов.