- 1
- 2
- 3
- 4
Chunk* Chunk::findChunk(int x, int y, int z, ptrdiff_t& index) noexcept
{
return const_cast<Chunk*>(const_cast<const Chunk*>(this)->findChunk(x, y, z, index));
}-
C++ / Говнокод #21942
−16
8888
Запостил:
jangolare,
05 Января 2017
Follow us!
Зафайли на них багу значит. Даже Степанов не знает, как сделать по-другому:
Question:
This mean a radical change of mind from both imperative and OO thinking. What are the benefits, and the drawbacks, of this paradigm compared to the "standard" OO programming of SmallTalk or, say, Java?
Answer:
My approach works, theirs does not work. Try to implement a simple thing in the object oriented way, say, max. I do not know how it can be done. Using generic programming I can write:and(you do need both & and const &). And then I define what strict weak ordered means. Try doing it in Java. You can't write a generic max() in Java that takes two arguments of some type and has a return value of that same type. Inheritance and interfaces don't help. And if they cannot implement max or swap or linear search, what chances do they have to implement really complex stuff? These are my litmus tests: if a language allows me to implement max and swap and linear search generically - then it has some potential.
-- http://www.stlport.org/resources/StepanovUSA.html
Правда, он тут смело стреляет всем нам в ногу, возвращая константную ссылку вместо значения, ну да ладно.
Люди сравнивают время, которое им нужно потратить на написание нормально работающего кода на boost.asio, прикручивание веб-интерфейса к своему cишному бинарю, выбор либ для поддержки юнит-тестирования, юникода, времени, файловой системы, xml/json/csv энкодеров и т.д. с временем, которое нужно потратить на написание Max/Min для нужных типов интов (или даже использование ифов), и хавают.
См. https://golang.org/pkg/
Внезапно, зачастую лучше. Лучше просто взять из стандартной библиотеки (может, даже, не идеального качества, хотя я лично откровенных косяков не видел), чем выбирать, вендорить, следить за обновлениями, интегрировать в сборку, етц. И так для каждой херни.
Для тулов вообще идеально -- залил тулу в гитхаб, ставь на любую машину через
go get http://github.com/my/favorite-tool.
В тыщу раз лучше чем
apt-get all the fucking dev deps && configure && make && make install && oh-shi-how-will-i-update-this-crap
Не так давно писать прототип сервера на го: получаем http-запрос, проверяем куки, выковыриваем метаданные и фоточки из multipart/form-data, складываем в тёплое сухое место.
3 часа работы -- сервер готов и работает. Для C++, если с нуля -- задача на несколько дней минимум.
Это было в Я. Библиотеки там есть много для чего, проблема в том, что это был прототип бэкэнда для мобильного приложения. Получение дырки, в которую могут ходить клиенты из внешней сети — процедура длительная и требующая проверок безопасников.
Поэтому в период начальной разработки, когда не было ещё понятно, что из этого получится, использовали внешний инстанс, на который, как ты понимаешь, бинарники, собранные в интранете, заливать нехорошо, да и просто не получится: внутри всё линкуется динамически и ставится через deb-пакеты специальной тулой.
Го собирает всё в один бинарник, который можно просто скопировать на инстанс с локалки.
го принципиально всё всегда линкует статически? А как же всякие классические проблемы когда есть СУБД Foo и клиент к ней libfoo, и они вместе обновляются админом и не совместимы со старыми версиями?
Интересно, как админ может это нормально сделать на кластере с N инстансами БД и парой сотен клиентов, желательно с нулевым простоем?
Да и непотяно, как это связано с динамической линковкой. Бинарник надо перезапускать, чтобы подцепилась новая версия динамической либы. Чем отличается (залить новую либу + перезапуск) от (залить новый бинарь + перезапуск)?
Классическая проблема совсем другая — ты починил критический баг в какой-нибудь либе для нормализации юникода. Отлично, теперь тебе надо пересобрать и зарелизить стотыщ проектов.
У меня магазин_по_продаже_хомячков же. У меня нет кластера.
>>Чем отличается
Вот ровно тем, что пересобирать ничего не надо.
>>Отлично, теперь тебе надо пересобрать и зарелизить стотыщ проектов.
Имхо это та же проблема, вид с боку.
Наверное я еще должен сказать что в памяти придется держать 100500 копий одного кода если у тебя 100500 приложений его статически влинковало, но наверное это является проблемой в 2017м
есть такие охуенно умные гипервизоры, которые дедуплицируют страницы памяти
Думаю, там memcmp.
А нельзя взять какой нить apache и скомпилироваться к нему модулем?
Или это такой пруф-оф-концепт которому сразу надо уметь 10К подключений?
У нас через пару недель одобрили внешние дырки, multipart/form-data превратился в protobuf, тёплое сухое место превратилось в очередь загрузки, и прототип можно было спокойно закопать, свою роль он с честью выполнил.
Эта проблема аффектит 0.1% случаев и решается за 15 минут скриптом.
Так что Apache не нужен низачем.
Sweet dreams, мой первый веб сервер
закопайте
>>модпхп
а почему нельзя его как FastCGI?
http://php.net/manual/ru/install.fpm.php
Чтобы этого не было -- придумали php safemode, который с одной стороны всё равно иногда имел дыры, а с другой не давал людям делать нормальные вещи (например, запускать внешнее приложение).
Некоторые админы так отчаялись, что запустили PHP как CGI с SUID (или стики?) бит, чтобы скрипт исполнялся от имени его владельца, и у них потом было охулиард процессов.
Даже не знаю что сейчас живут шареды. Наверное имадж докера запускают
А еще в нем в каждой 2-3 версии пхп латали дыры. Кстати, как они это сейчас решили?
>делать нормальные вещи (например, запускать внешнее приложение).
На шаред хостинге? Зачем?
хахаха
бугагага
Безопасный режим в PHP - это попытка решить проблему безопасности на совместно используемых серверах. Несмотря на то, что концептуально неверно решать эту проблему на уровне PHP, но поскольку альтернативы уровня веб-сервера или операционной системы на сегодняшний день отсутствуют, многие пользователи, особенно провайдеры, используют именно защищенный режим.
Внимание
Данная возможность была помечена УСТАРЕВШЕЙ начиная с версии PHP 5.3.0 и была УДАЛЕНА в версии PHP 5.4.0.
--------
>>На шаред хостинге? Зачем?
Когда я был маленький, админы не умели обычно настроить функцию mail в php.ini, и слать спам надо было вызывая mail (или даже sendmail, лол!) напрямую.
В ту пору я наелся говна с сейфмодой.
Ну еще иногда он не давал прав писать в соседнюю папку (уровенем выше, кажется) а это вполне можно хотеть
Таки я не понял, как изолируются юзеры между собой?
ХМЛ - реализован от силы 10% от стандарта.
ЯМЛ - чуть меньше половины.
Ясон - есть пару косяков, но архитектура такая ублюдочная, что подмывает переделать.
Но такого фейла как зависимости в Го - это еще поискать нужно. То, что лежит на поверхности - да, кажестся простым, но... иногда, например, нужно использовать две версии одной библиотеки, и на это у Го нет решений. Бинарная несовместимость всего со всем, отсутствие загружемых модулей, неработающая компиляция шаред библиотек.
Го, как и все гугловские опенсорс проекты примечателен непродуманностью, очень частичной реализацией и толпами прозелитов восхваляющими данный проект.
Сравнение скорости написания серверов на Го и С++ мне не понятно: на Го есть кривожопая библиотека http. В которой уже реализован сервер - чего его еще писать? Поддерживать это - говно, да трудно и накладно, а писать его вообще не нужно. На С++ поди нужно все самому делать, ну и проблемы поддержки будут пропорциональны разработке.
То, что идёт с golang, называется Standard Library в противовес Other Packages. Кавычки не нужны.
> стандарта у Го нет
А для чего он нужен? У java тоже стандарта нет, только спецификация. У Go тоже спека есть, правда, не такая подробная, как у java. Вот уж у кого точно не будет стандарта, так это у Python, в котором каждая первая мелочь определяется референсной реализацией.
> ХМЛ - реализован от силы 10% от стандарта.
Откуда цифры? Где посмотреть табличку, какие детали, описанные RFC не реализованы?
> кривожопая библиотека http
Что с ней не так?
> В которой уже реализован сервер - чего его еще писать?
Что непоятного? Да, в том и смысл, что ничего писать не нужно, вменяемая реализация есть из коробки. В плюсах нужно найти реализацию, придумать, как интегрировать её с другими либами, понять, как её собирать, грамотно включить её билд (система сборки может отличаться от того, что используется в проекте), етц.
> у Го нет решений
Скопировать разные версии в разные каталоги проекта и переписать в них импорты? Как эта проблема рашается в питоне (когда нужно libxx-1.0 и libxx-2.0)?
У Явы есть стандарт - все эти JSR-ы - это жабий стандарт. Вот так вот. Над ним работают, обсуждают, чего-то принимают, чего-то не принимают. А в Го есть группа независимых долбоебов, которые как хотят, так и делают. Я уже такого насмотрелся с адобовским Флексом, больше не хочется.
ХМЛ не описан в РФЦ, это раз. Для него есть стандарты. В полном объеме ХМЛ включает в себя DTD, XSL(T), XQuery, XPath... и еще по мелочам. То что Гугл реализовал - это вообще слезы. Очевидно в Гугле они всем остальным не пользуются, и поэтому в "стандартную" библиотеку ушло только то говно, которое они для себя написали. И теперь у человека желающего реализовать стандарт в полном объеме получается облом: "стандартную" библиотеку не дополнить изза уебищной системы экспортирования символов, а писать отдельную - так ею не будут пользоваться.
Изкоробочная реализация ХТТП в Го вменяемая? - ох лол, да ты вообще ею просто никогда не пользовался, и как обычно пиздишь с важным видом. Там столько феерического говна, что даже в Го "комьюнити" состоящем на 146% из фанбоев Гугла ее решили переписать. Она юзабильна примерно на столько же, на сколько и SimpleHTTPServer в Питоне.
Подожди, тоесть нужно вручную переименовывать какие-то названия в коде? А как же Го вендор? Вручную я могу все что угодно таким способом совместить. Но в чем тогда перимущество использования Го-вна? И почему нужно сразу с Питоном сравнивать. Почему не с Явой? Да и, опять же, это только один из множества недостатков. Модули, шаред библиотеки и т.д. - с этим-то что делать?
Думаю, через два года ты будешь гнать и на питон.
А соседняя команда пересядет на Go, напишет проект из свалит бухать.
во-вторых
>>На нем только одноразовые скрипты писать.
чувакам из этого списка https://www.shuup.com/en/blog/25-of-the-most-popular-python-and-django-websites/ стало очень обидно
зы: хотя я тоже думаю что статическая тупизация обычно лучше чем ее отсутствие
Веб-сайты это такая вещщ где или можно тесты прогнать или сломалось - и хуй с ним, зарепортят. Статическая типизация много где нервы спасает.
сема, ты научился бы уже пепы читать, чтоли
https://docs.python.org/3/library/typing.html
http://ideone.com/mflswV
В следующий раз осторожнее вафельницу раззевай.
Где она?
Проверять ее или не проверять это право тулзы (кстати, такие тулзы уже есть) а вовсе не обязананность
Это хуйня а не статическая типизация. Ты обосрался. Признай это.
До сих пор я от тебя слышал исключительно админскую хуйню. Можешь раскроешь людям свою квалификацию?
Так бывает у тех, кто к IT отношения не имеет
Трепло, так ты расскажешь нам что-нибудь из упомянутого тобой CS или тебя признать опущем-пиздаболом?
Что будет если твоя функция с хинтами таки вернет что-то с не хинтованным типом, потому что например дергает не хинтованную функцию? Какая польза от этой срани без проверок в рантайме?
А еще ты ничего не знаешь про программирование, не пиздел бы.
https://en.wikipedia.org/wiki/Type_system#Static_type_checking
Static type checking is the process of verifying the type safety of a program based on analysis of a program's text (source code). If a program passes a static type checker, then the program is guaranteed to satisfy some set of type safety properties for all possible inputs.
Заметь: нигде не сказано что что-то должно проверяться при компиляции или интерпретации.
А вот и утилиты:
https://github.com/python/typing/issues/200
вполне может быть.
все скриптояпы проходят такой путь: пых, js, actionscript итд
The Python Standard Library
https://docs.python.org/3/library/
Очевидно, на питоне пишут в точности такие же "долбоебы"
> Там столько феерического говна
Как обычно, очень много конкретики.
> В полном объеме ХМЛ включает в себя DTD, XSL(T), XQuery, XPath
Жирновато будет весь этот маразм в стандартную либу тянуть.
> У Явы есть стандарт - все эти JSR-ы
Не подскажешь, какая международная организация по стандартизации управляет этим процессом?
> Почему не с Явой?
А что в яве будет, если в classpath окажется две либы разных версий? Подсказка: ничего хорошего.
> Модули, шаред библиотеки и т.д. - с этим-то что делать?
Начтём с того, что они изначально в типичной го-программе редко нужны. По просьбам трудящихся появился linkshared Не знаю, в какой оно там стадии, мне всегда статическая линковка нужна была.
> как обычно пиздишь с важным видом
К сожалению, со стороны ты именно так и выглядишь.
Смотря для чего, одна большая жирная со всем этим добром на чистом го врядли найдётся, да и желающих заниматься переписыванием, думаю, человека полтора. Мне всегда хватало того, что есть в libxml2, поэтому я бы начал с .
Правда, сходу не понятно, почему там половина объектов вручную удаляется, кажется разумным напрячь GC в биндингах (runtime.SetFinalizer(), вот это всё).
Ну я бы настолько не обобщал... XML Schema, которую wvxvw почему-то забыл упомянуть - весьма полезная штука. XPath тоже няшный.
С этим трудно не согласиться. В плюсах я для этого тоже использовал schematron-апишку из libxml2. Я согласен, что Go-шного пакета не достаточно, чтобы строить серьёзный бизнес вокруг XML, но его вполне достаточно, если нужно по-быстрому распарсить документ/составить реквест для REST-запроса/прочитать какой-нибудь конфиг/генерить RSS ленту/etc.
Но главная разница она в другом. Скажем, мне нравится Ява, но не нравится как Оракл реализовал ArrayList. Я могу взять и написать свой JDK, и надеятся, что другие разработчики будут им пользоваться, присылать мне патчи, тестировать и т.д. Почему так? - потому что есть стандарт. Стандарт дает возможность обойти первотапочников. И это важно не только в програмировании. Что происходит с Го? - ну, напишу я свою реализацию Го следуя моему пониманию документации, а в следующем Го релизе, про который я еще ничего не знаю, они часть выбросят, часть поменяют, и моя реализация станет некондиционной - никто не пользуется - патчи мне не шлет - я не могу использовать чужие библиотеки - проект сдох.
Что не так с ХТТП пакетом в Го? - ОК, в Го есть два таких пакета net/http и net/rpc. Написаны, вобщем-то теми же людьми. Но вот net/http предоставляет библиотечную функцию которая сразу делает запрос и обрабатывает ответ, а для реализации центрального концепта net/rpc - rpc.Client нужны две функции: посылающая запрос и обрабатывающая ответ. И эти два куска говна несовместимы между собой. А еще в Го нетворкинге они постоянно где-то забывают использовать таймауты которые им внешний код передает. И всякие функции типа net.DialTimeout могу забочить програму не смотря на название. Но мне просто места не хватит все описать.
> вот net/http предоставляет библиотечную функцию которая сразу делает запрос и обрабатывает ответ, а для реализации центрального концепта net/rpc - rpc.Client нужны две функции: посылающая запрос и обрабатывающая ответ
Опять какая-то каша: говорили о http сервере, пошли претензии к rpc-клиенту. Ну ок, так а в чём претензия? О каких двух функциях rpc.Client идёт речь? Я вижу только func (*Client) Call и func (*Client) Go.
> несовместимы между собой
Ну и не совсем понятно, почему и как библиотека для удобной работы с конкретным общим протоколом HTTP должна быть "совместима" с узкоспециализированным средством для RPC-коммуникации go-программ.
Так https://golang.org/pkg/net/rpc/#DialHTTP ?
Наверное.
В Яве есть Мейвен, который решит проблемы разных версий библиотек, это тяжело, но решаемо. Есть возможность загрузить разные версии библиотек в разные класс лоадеры. Но в Го просто нет модулей, так что там с этой проблемой еще не столкнулись.
Ок, давай тогда определим, о каких модулях идёт речь, поскольку сходу можно назвать минимум три смысла слова "модуль"
1) Модуль как часть программы, которая может быть скомпилирована независимо от других, имеющая публичный интерфейс, скрывающая детали реализации. Это модули из Pascal или Dlang.
2) Динамически загружаемый модуль: файл с исполняемым кодом, который может быть загружен и выполнен после старта основной программы.
3) Модули в смысле ML как объекты языка.
Модули (1) — это очень нужная вещь, которая в Go, разумеется, есть и называется package. Они также поддерживаются рантаймом, поскольку могут определять инициализаторы, которые рантайм выполнит в правильном порядке.
Я решил, что ты говоришь о модулях (2). Они полезны, когда основная часть кода и плагины пишутся независимыми людьми, что верно, к примеру, для Eclipse или Emacs. На моей практике бэк-энд разработчика я такое видел примерно один раз, и то я так и не понял, зачем их туда воткнули. Почти всегда можно зашить все модули в основной бинарь и контролировать активное подмножество через какой-нибудь конфиг. В частности, я вот прямо сейчас пишут код, который такое делает. В языке без "модулей".
> Мейвен, который решит проблемы разных версий библиотек
Да, сейчас, придёт и все решит он тебе. Если ты зависишь от разных версий библиотеки, мавен выберет тебе какую-то одну. Останется только надеется, что авторы либы не сломали внешний API.
А если вдруг в разных либах оказались одни и те же классы, никакой мавен не спасёт. Это не гипотетическая ситуация: я лично натыкался на такое, когда кто-то умный порезал и завендорил зависимости в jar, не переименовав пакеты зависимостей.
Не пролезут же, темплейты не умеют в оверлоад...
А если серьезно, в std тоже только const версия max
Самое смешное, что const-ссылка тут как раз менее безопасна (парадокс). В не-const ссылку временный объект не засунешь (если у тебя не VS, конечно).
Кажется, кому-то пора менять ник.
const ref продлевает объекту жизнь, только если присвоить ему объект по значению. Т.е.
уже года 3 как
к сожалению, на говнокоде это доступно только для Ultimate VIP аккаунтов за $1999/year, а меня жаба давит столько платить
Но 3_14dar'а же кто-то забанил. Шах и мат, аадминисты.
Пробрался пешкой в твой тыл, проверь.
Ну-ну, тривиальная транформация программы делает её невалидной:
Царь одобряет. Вдруг StrictWeakOrdered тяжёлый.