- 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));
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−16
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));
}
8888
Elvenfighter 05.01.2017 16:15 # +1
roman-kashitsyn 05.01.2017 16:23 # +3
guestinho 05.01.2017 17:20 # 0
roman-kashitsyn 05.01.2017 17:28 # +1
Зафайли на них багу значит. Даже Степанов не знает, как сделать по-другому:
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
Правда, он тут смело стреляет всем нам в ногу, возвращая константную ссылку вместо значения, ну да ладно.
guestinho 05.01.2017 17:47 # 0
roman-kashitsyn 05.01.2017 18:01 # +1
Люди сравнивают время, которое им нужно потратить на написание нормально работающего кода на boost.asio, прикручивание веб-интерфейса к своему cишному бинарю, выбор либ для поддержки юнит-тестирования, юникода, времени, файловой системы, xml/json/csv энкодеров и т.д. с временем, которое нужно потратить на написание Max/Min для нужных типов интов (или даже использование ифов), и хавают.
См. https://golang.org/pkg/
wvxvw 05.01.2017 19:03 # 0
roman-kashitsyn 05.01.2017 19:56 # +3
Внезапно, зачастую лучше. Лучше просто взять из стандартной библиотеки (может, даже, не идеального качества, хотя я лично откровенных косяков не видел), чем выбирать, вендорить, следить за обновлениями, интегрировать в сборку, етц. И так для каждой херни.
Для тулов вообще идеально -- залил тулу в гитхаб, ставь на любую машину через
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++, если с нуля -- задача на несколько дней минимум.
defecate-plusplus 05.01.2017 20:15 # +1
roman-kashitsyn 05.01.2017 23:21 # 0
Это было в Я. Библиотеки там есть много для чего, проблема в том, что это был прототип бэкэнда для мобильного приложения. Получение дырки, в которую могут ходить клиенты из внешней сети — процедура длительная и требующая проверок безопасников.
Поэтому в период начальной разработки, когда не было ещё понятно, что из этого получится, использовали внешний инстанс, на который, как ты понимаешь, бинарники, собранные в интранете, заливать нехорошо, да и просто не получится: внутри всё линкуется динамически и ставится через deb-пакеты специальной тулой.
Го собирает всё в один бинарник, который можно просто скопировать на инстанс с локалки.
barop 05.01.2017 23:25 # 0
го принципиально всё всегда линкует статически? А как же всякие классические проблемы когда есть СУБД Foo и клиент к ней libfoo, и они вместе обновляются админом и не совместимы со старыми версиями?
roman-kashitsyn 05.01.2017 23:58 # +2
Интересно, как админ может это нормально сделать на кластере с N инстансами БД и парой сотен клиентов, желательно с нулевым простоем?
Да и непотяно, как это связано с динамической линковкой. Бинарник надо перезапускать, чтобы подцепилась новая версия динамической либы. Чем отличается (залить новую либу + перезапуск) от (залить новый бинарь + перезапуск)?
Классическая проблема совсем другая — ты починил критический баг в какой-нибудь либе для нормализации юникода. Отлично, теперь тебе надо пересобрать и зарелизить стотыщ проектов.
barop 06.01.2017 00:11 # +1
У меня магазин_по_продаже_хомячков же. У меня нет кластера.
>>Чем отличается
Вот ровно тем, что пересобирать ничего не надо.
>>Отлично, теперь тебе надо пересобрать и зарелизить стотыщ проектов.
Имхо это та же проблема, вид с боку.
Наверное я еще должен сказать что в памяти придется держать 100500 копий одного кода если у тебя 100500 приложений его статически влинковало, но наверное это является проблемой в 2017м
defecate-plusplus 06.01.2017 00:18 # 0
есть такие охуенно умные гипервизоры, которые дедуплицируют страницы памяти
guestinho 06.01.2017 00:22 # 0
barop 06.01.2017 00:27 # 0
defecate-plusplus 06.01.2017 00:35 # 0
Думаю, там memcmp.
defecate-plusplus 05.01.2017 23:33 # 0
barop 05.01.2017 23:40 # 0
А нельзя взять какой нить apache и скомпилироваться к нему модулем?
defecate-plusplus 05.01.2017 23:46 # 0
barop 05.01.2017 23:52 # 0
Или это такой пруф-оф-концепт которому сразу надо уметь 10К подключений?
guestinho 05.01.2017 23:57 # 0
roman-kashitsyn 06.01.2017 00:07 # 0
У нас через пару недель одобрили внешние дырки, multipart/form-data превратился в protobuf, тёплое сухое место превратилось в очередь загрузки, и прототип можно было спокойно закопать, свою роль он с честью выполнил.
guestinho 06.01.2017 00:09 # 0
3_14dar 05.01.2017 23:53 # 0
barop 05.01.2017 23:57 # 0
Эта проблема аффектит 0.1% случаев и решается за 15 минут скриптом.
Так что Apache не нужен низачем.
Sweet dreams, мой первый веб сервер
guestinho 05.01.2017 23:59 # 0
barop 06.01.2017 00:01 # 0
закопайте
>>модпхп
а почему нельзя его как FastCGI?
http://php.net/manual/ru/install.fpm.php
barop 06.01.2017 00:05 # 0
Чтобы этого не было -- придумали php safemode, который с одной стороны всё равно иногда имел дыры, а с другой не давал людям делать нормальные вещи (например, запускать внешнее приложение).
Некоторые админы так отчаялись, что запустили PHP как CGI с SUID (или стики?) бит, чтобы скрипт исполнялся от имени его владельца, и у них потом было охулиард процессов.
Даже не знаю что сейчас живут шареды. Наверное имадж докера запускают
3_14dar 06.01.2017 00:18 # 0
А еще в нем в каждой 2-3 версии пхп латали дыры. Кстати, как они это сейчас решили?
>делать нормальные вещи (например, запускать внешнее приложение).
На шаред хостинге? Зачем?
barop 06.01.2017 00:22 # 0
хахаха
бугагага
Безопасный режим в PHP - это попытка решить проблему безопасности на совместно используемых серверах. Несмотря на то, что концептуально неверно решать эту проблему на уровне PHP, но поскольку альтернативы уровня веб-сервера или операционной системы на сегодняшний день отсутствуют, многие пользователи, особенно провайдеры, используют именно защищенный режим.
Внимание
Данная возможность была помечена УСТАРЕВШЕЙ начиная с версии PHP 5.3.0 и была УДАЛЕНА в версии PHP 5.4.0.
--------
>>На шаред хостинге? Зачем?
Когда я был маленький, админы не умели обычно настроить функцию mail в php.ini, и слать спам надо было вызывая mail (или даже sendmail, лол!) напрямую.
В ту пору я наелся говна с сейфмодой.
Ну еще иногда он не давал прав писать в соседнюю папку (уровенем выше, кажется) а это вполне можно хотеть
3_14dar 06.01.2017 01:11 # 0
Таки я не понял, как изолируются юзеры между собой?
wvxvw 05.01.2017 22:04 # 0
ХМЛ - реализован от силы 10% от стандарта.
ЯМЛ - чуть меньше половины.
Ясон - есть пару косяков, но архитектура такая ублюдочная, что подмывает переделать.
Но такого фейла как зависимости в Го - это еще поискать нужно. То, что лежит на поверхности - да, кажестся простым, но... иногда, например, нужно использовать две версии одной библиотеки, и на это у Го нет решений. Бинарная несовместимость всего со всем, отсутствие загружемых модулей, неработающая компиляция шаред библиотек.
Го, как и все гугловские опенсорс проекты примечателен непродуманностью, очень частичной реализацией и толпами прозелитов восхваляющими данный проект.
Сравнение скорости написания серверов на Го и С++ мне не понятно: на Го есть кривожопая библиотека http. В которой уже реализован сервер - чего его еще писать? Поддерживать это - говно, да трудно и накладно, а писать его вообще не нужно. На С++ поди нужно все самому делать, ну и проблемы поддержки будут пропорциональны разработке.
roman-kashitsyn 05.01.2017 23:12 # 0
То, что идёт с golang, называется Standard Library в противовес Other Packages. Кавычки не нужны.
> стандарта у Го нет
А для чего он нужен? У java тоже стандарта нет, только спецификация. У Go тоже спека есть, правда, не такая подробная, как у java. Вот уж у кого точно не будет стандарта, так это у Python, в котором каждая первая мелочь определяется референсной реализацией.
> ХМЛ - реализован от силы 10% от стандарта.
Откуда цифры? Где посмотреть табличку, какие детали, описанные RFC не реализованы?
> кривожопая библиотека http
Что с ней не так?
> В которой уже реализован сервер - чего его еще писать?
Что непоятного? Да, в том и смысл, что ничего писать не нужно, вменяемая реализация есть из коробки. В плюсах нужно найти реализацию, придумать, как интегрировать её с другими либами, понять, как её собирать, грамотно включить её билд (система сборки может отличаться от того, что используется в проекте), етц.
> у Го нет решений
Скопировать разные версии в разные каталоги проекта и переписать в них импорты? Как эта проблема рашается в питоне (когда нужно libxx-1.0 и libxx-2.0)?
wvxvw 06.01.2017 00:30 # 0
У Явы есть стандарт - все эти JSR-ы - это жабий стандарт. Вот так вот. Над ним работают, обсуждают, чего-то принимают, чего-то не принимают. А в Го есть группа независимых долбоебов, которые как хотят, так и делают. Я уже такого насмотрелся с адобовским Флексом, больше не хочется.
ХМЛ не описан в РФЦ, это раз. Для него есть стандарты. В полном объеме ХМЛ включает в себя DTD, XSL(T), XQuery, XPath... и еще по мелочам. То что Гугл реализовал - это вообще слезы. Очевидно в Гугле они всем остальным не пользуются, и поэтому в "стандартную" библиотеку ушло только то говно, которое они для себя написали. И теперь у человека желающего реализовать стандарт в полном объеме получается облом: "стандартную" библиотеку не дополнить изза уебищной системы экспортирования символов, а писать отдельную - так ею не будут пользоваться.
Изкоробочная реализация ХТТП в Го вменяемая? - ох лол, да ты вообще ею просто никогда не пользовался, и как обычно пиздишь с важным видом. Там столько феерического говна, что даже в Го "комьюнити" состоящем на 146% из фанбоев Гугла ее решили переписать. Она юзабильна примерно на столько же, на сколько и SimpleHTTPServer в Питоне.
Подожди, тоесть нужно вручную переименовывать какие-то названия в коде? А как же Го вендор? Вручную я могу все что угодно таким способом совместить. Но в чем тогда перимущество использования Го-вна? И почему нужно сразу с Питоном сравнивать. Почему не с Явой? Да и, опять же, это только один из множества недостатков. Модули, шаред библиотеки и т.д. - с этим-то что делать?
wvxvw 06.01.2017 00:35 # 0
CHayT 06.01.2017 00:43 # +8
guest 06.01.2017 00:55 # +6
Думаю, через два года ты будешь гнать и на питон.
roman-kashitsyn 06.01.2017 01:31 # +2
А соседняя команда пересядет на Go, напишет проект из свалит бухать.
barop 06.01.2017 01:42 # 0
во-вторых
>>На нем только одноразовые скрипты писать.
чувакам из этого списка https://www.shuup.com/en/blog/25-of-the-most-popular-python-and-django-websites/ стало очень обидно
зы: хотя я тоже думаю что статическая тупизация обычно лучше чем ее отсутствие
3_14dar 06.01.2017 08:56 # +2
Веб-сайты это такая вещщ где или можно тесты прогнать или сломалось - и хуй с ним, зарепортят. Статическая типизация много где нервы спасает.
barop 10.01.2017 13:08 # 0
сема, ты научился бы уже пепы читать, чтоли
https://docs.python.org/3/library/typing.html
guest 10.01.2017 13:20 # 0
http://ideone.com/mflswV
В следующий раз осторожнее вафельницу раззевай.
barop 10.01.2017 13:27 # 0
guest 10.01.2017 13:37 # 0
Где она?
barop 10.01.2017 13:40 # 0
guest 10.01.2017 13:38 # 0
barop 10.01.2017 13:40 # 0
Проверять ее или не проверять это право тулзы (кстати, такие тулзы уже есть) а вовсе не обязананность
guest 10.01.2017 13:42 # +1
barop 10.01.2017 13:45 # 0
guest 10.01.2017 13:59 # 0
Это хуйня а не статическая типизация. Ты обосрался. Признай это.
barop 10.01.2017 14:07 # −1
guest 10.01.2017 14:11 # 0
barop 10.01.2017 14:13 # 0
guest 10.01.2017 14:23 # 0
barop 10.01.2017 14:38 # 0
guest 10.01.2017 15:03 # 0
barop 10.01.2017 15:39 # 0
guest 10.01.2017 15:46 # +1
До сих пор я от тебя слышал исключительно админскую хуйню. Можешь раскроешь людям свою квалификацию?
barop 10.01.2017 15:54 # 0
Так бывает у тех, кто к IT отношения не имеет
guest 10.01.2017 16:11 # +1
Трепло, так ты расскажешь нам что-нибудь из упомянутого тобой CS или тебя признать опущем-пиздаболом?
Что будет если твоя функция с хинтами таки вернет что-то с не хинтованным типом, потому что например дергает не хинтованную функцию? Какая польза от этой срани без проверок в рантайме?
guestinho 10.01.2017 16:24 # +1
А еще ты ничего не знаешь про программирование, не пиздел бы.
barop 10.01.2017 16:28 # 0
guestinho 10.01.2017 16:44 # 0
barop 10.01.2017 16:48 # 0
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
guest 10.01.2017 13:41 # 0
guest 10.01.2017 13:44 # +1
barop 10.01.2017 13:45 # +1
вполне может быть.
все скриптояпы проходят такой путь: пых, js, actionscript итд
roman-kashitsyn 06.01.2017 01:15 # 0
The Python Standard Library
https://docs.python.org/3/library/
Очевидно, на питоне пишут в точности такие же "долбоебы"
> Там столько феерического говна
Как обычно, очень много конкретики.
> В полном объеме ХМЛ включает в себя DTD, XSL(T), XQuery, XPath
Жирновато будет весь этот маразм в стандартную либу тянуть.
> У Явы есть стандарт - все эти JSR-ы
Не подскажешь, какая международная организация по стандартизации управляет этим процессом?
> Почему не с Явой?
А что в яве будет, если в classpath окажется две либы разных версий? Подсказка: ничего хорошего.
> Модули, шаред библиотеки и т.д. - с этим-то что делать?
Начтём с того, что они изначально в типичной го-программе редко нужны. По просьбам трудящихся появился linkshared Не знаю, в какой оно там стадии, мне всегда статическая линковка нужна была.
> как обычно пиздишь с важным видом
К сожалению, со стороны ты именно так и выглядишь.
3_14dar 06.01.2017 01:24 # 0
roman-kashitsyn 06.01.2017 01:52 # 0
Смотря для чего, одна большая жирная со всем этим добром на чистом го врядли найдётся, да и желающих заниматься переписыванием, думаю, человека полтора. Мне всегда хватало того, что есть в libxml2, поэтому я бы начал с .
Правда, сходу не понятно, почему там половина объектов вручную удаляется, кажется разумным напрячь GC в биндингах (runtime.SetFinalizer(), вот это всё).
3_14dar 06.01.2017 02:22 # 0
bormand 06.01.2017 08:06 # +2
Ну я бы настолько не обобщал... XML Schema, которую wvxvw почему-то забыл упомянуть - весьма полезная штука. XPath тоже няшный.
roman-kashitsyn 06.01.2017 13:21 # 0
С этим трудно не согласиться. В плюсах я для этого тоже использовал schematron-апишку из libxml2. Я согласен, что Go-шного пакета не достаточно, чтобы строить серьёзный бизнес вокруг XML, но его вполне достаточно, если нужно по-быстрому распарсить документ/составить реквест для REST-запроса/прочитать какой-нибудь конфиг/генерить RSS ленту/etc.
guest 06.01.2017 22:26 # 0
wvxvw 06.01.2017 09:59 # 0
Но главная разница она в другом. Скажем, мне нравится Ява, но не нравится как Оракл реализовал ArrayList. Я могу взять и написать свой JDK, и надеятся, что другие разработчики будут им пользоваться, присылать мне патчи, тестировать и т.д. Почему так? - потому что есть стандарт. Стандарт дает возможность обойти первотапочников. И это важно не только в програмировании. Что происходит с Го? - ну, напишу я свою реализацию Го следуя моему пониманию документации, а в следующем Го релизе, про который я еще ничего не знаю, они часть выбросят, часть поменяют, и моя реализация станет некондиционной - никто не пользуется - патчи мне не шлет - я не могу использовать чужие библиотеки - проект сдох.
Что не так с ХТТП пакетом в Го? - ОК, в Го есть два таких пакета net/http и net/rpc. Написаны, вобщем-то теми же людьми. Но вот net/http предоставляет библиотечную функцию которая сразу делает запрос и обрабатывает ответ, а для реализации центрального концепта net/rpc - rpc.Client нужны две функции: посылающая запрос и обрабатывающая ответ. И эти два куска говна несовместимы между собой. А еще в Го нетворкинге они постоянно где-то забывают использовать таймауты которые им внешний код передает. И всякие функции типа net.DialTimeout могу забочить програму не смотря на название. Но мне просто места не хватит все описать.
roman-kashitsyn 06.01.2017 16:37 # 0
> вот net/http предоставляет библиотечную функцию которая сразу делает запрос и обрабатывает ответ, а для реализации центрального концепта net/rpc - rpc.Client нужны две функции: посылающая запрос и обрабатывающая ответ
Опять какая-то каша: говорили о http сервере, пошли претензии к rpc-клиенту. Ну ок, так а в чём претензия? О каких двух функциях rpc.Client идёт речь? Я вижу только func (*Client) Call и func (*Client) Go.
> несовместимы между собой
Ну и не совсем понятно, почему и как библиотека для удобной работы с конкретным общим протоколом HTTP должна быть "совместима" с узкоспециализированным средством для RPC-коммуникации go-программ.
bormand 06.01.2017 16:38 # 0
roman-kashitsyn 06.01.2017 16:50 # +1
Так https://golang.org/pkg/net/rpc/#DialHTTP ?
bormand 06.01.2017 18:33 # 0
Наверное.
wvxvw 06.01.2017 09:59 # 0
В Яве есть Мейвен, который решит проблемы разных версий библиотек, это тяжело, но решаемо. Есть возможность загрузить разные версии библиотек в разные класс лоадеры. Но в Го просто нет модулей, так что там с этой проблемой еще не столкнулись.
roman-kashitsyn 06.01.2017 13:11 # 0
Ок, давай тогда определим, о каких модулях идёт речь, поскольку сходу можно назвать минимум три смысла слова "модуль"
1) Модуль как часть программы, которая может быть скомпилирована независимо от других, имеющая публичный интерфейс, скрывающая детали реализации. Это модули из Pascal или Dlang.
2) Динамически загружаемый модуль: файл с исполняемым кодом, который может быть загружен и выполнен после старта основной программы.
3) Модули в смысле ML как объекты языка.
Модули (1) — это очень нужная вещь, которая в Go, разумеется, есть и называется package. Они также поддерживаются рантаймом, поскольку могут определять инициализаторы, которые рантайм выполнит в правильном порядке.
Я решил, что ты говоришь о модулях (2). Они полезны, когда основная часть кода и плагины пишутся независимыми людьми, что верно, к примеру, для Eclipse или Emacs. На моей практике бэк-энд разработчика я такое видел примерно один раз, и то я так и не понял, зачем их туда воткнули. Почти всегда можно зашить все модули в основной бинарь и контролировать активное подмножество через какой-нибудь конфиг. В частности, я вот прямо сейчас пишут код, который такое делает. В языке без "модулей".
> Мейвен, который решит проблемы разных версий библиотек
Да, сейчас, придёт и все решит он тебе. Если ты зависишь от разных версий библиотеки, мавен выберет тебе какую-то одну. Останется только надеется, что авторы либы не сломали внешний API.
А если вдруг в разных либах оказались одни и те же классы, никакой мавен не спасёт. Это не гипотетическая ситуация: я лично натыкался на такое, когда кто-то умный порезал и завендорил зависимости в jar, не переименовав пакеты зависимостей.
guest8 08.03.2020 14:27 # −999
bormand 08.03.2020 14:33 # 0
guest8 08.03.2020 15:15 # −999
gost 08.03.2020 14:04 # 0
guest8 08.03.2020 14:20 # −999
bormand 05.01.2017 17:51 # +1
roman-kashitsyn 05.01.2017 18:02 # 0
bormand 05.01.2017 18:05 # 0
Не пролезут же, темплейты не умеют в оверлоад...
roman-kashitsyn 05.01.2017 18:21 # +3
bormand 05.01.2017 18:29 # 0
Antervis 10.01.2017 11:56 # +1
А если серьезно, в std тоже только const версия max
guest 10.01.2017 12:11 # 0
roman-kashitsyn 10.01.2017 13:13 # 0
Самое смешное, что const-ссылка тут как раз менее безопасна (парадокс). В не-const ссылку временный объект не засунешь (если у тебя не VS, конечно).
guestinho 10.01.2017 16:49 # 0
defecate-plusplus 10.01.2017 17:00 # 0
roman-kashitsyn 10.01.2017 17:16 # +4
Кажется, кому-то пора менять ник.
const ref продлевает объекту жизнь, только если присвоить ему объект по значению. Т.е.
defecate-plusplus 10.01.2017 17:54 # +3
уже года 3 как
к сожалению, на говнокоде это доступно только для Ultimate VIP аккаунтов за $1999/year, а меня жаба давит столько платить
bormand 10.01.2017 18:31 # +1
defecate-plusplus 10.01.2017 18:37 # +1
bormand 10.01.2017 18:38 # +3
Но 3_14dar'а же кто-то забанил. Шах и мат, аадминисты.
huge_cock 10.01.2017 19:01 # −1
bormand 10.01.2017 19:53 # +3
Пробрался пешкой в твой тыл, проверь.
roman-kashitsyn 10.01.2017 17:13 # +2
Ну-ну, тривиальная транформация программы делает её невалидной:
guestinho 10.01.2017 17:24 # +1
bormand 05.01.2017 18:30 # 0
Царь одобряет. Вдруг StrictWeakOrdered тяжёлый.
roman-kashitsyn 05.01.2017 17:39 # +3
jangolare 05.01.2017 17:44 # 0