|
2.4, KonstantinB (ok), 13:08, 17/02/2017 [^] [^^] [^^^] [ответить]
| +18 +/– |
Производительность подняли, gc-паузу сократили, что еще надо?
То, что в языке никаких принципиальных изменений, только мелкие улучшения - это отлично. Go должен оставаться простым и пригодным для изучения за несколько дней, это его основное преимущество.
| |
|
3.9, Аноним (-), 13:23, 17/02/2017 [^] [^^] [^^^] [ответить]
| –7 +/– |
> gc-паузу сократили, что еще надо?
Вообще gc убрать, сам буду кучу чистить.
| |
|
|
5.20, Аноним (-), 14:04, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete?
| |
|
6.27, Василий Теркин (?), 14:27, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> И-и-и-и? Это опция активирует в Go невидимые ранне функции/операторы, типа, free()/delete?
И потом, если уж так чешется, берешь исходники, форкаешь и дописываешь нужный функционал. Осилишь?
| |
|
7.31, Аноним (-), 14:48, 17/02/2017 [^] [^^] [^^^] [ответить]
| +5 +/– |
Полный бред. Давай мы теперь всё будем по любому поводу форкать и переписывать под себя, это ведь легко, быстро и абсолютно нормально... Тогда и смысла в языках нет, у каждого был бы свой, удобный, лично для себя,.... если всё бы было так, как Вы описываете. Но все не так, не надо писать бред.
| |
|
|
9.58, Аноним (-), 15:15, 17/02/2017 [^] [^^] [^^^] [ответить] | –6 +/– | Это не мой бред выше по ветке Меня CPP полностью устраивает ну почти , и на гу... текст свёрнут, показать | |
|
|
11.106, Аноним (-), 17:29, 17/02/2017 [^] [^^] [^^^] [ответить] | –4 +/– | Не угадали Владею 3-мя разговорными языками, c , qml, javascript, php, html, s... текст свёрнут, показать | |
|
|
9.63, Аноним (-), 15:21, 17/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Даже в CPP уже лет 5 как ручное освобождение памяти считается дурным тоном Есть... текст свёрнут, показать | |
|
10.193, angra (ok), 12:31, 18/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Их вообще-то там много и каждый со своими достоинствами и недостатками А еще ес... текст свёрнут, показать | |
|
|
|
7.79, Аноним (-), 15:57, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Лучше бы сделали опцию, которая включает/отключает сборщик мусора при запуске Go. Ну и delete/free. И пусть каждый решает сам, как лучше в каждом конкретном случае. Язык и компиляторы не должны ограничивать свободу действий.
| |
|
8.112, Аноним (-), 17:41, 17/02/2017 [^] [^^] [^^^] [ответить] | –2 +/– | Сборщика мусора не должно быть совсем Есть куча техник обойтись без него и слеж... текст свёрнут, показать | |
|
9.126, _ (??), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить] | +/– | и при этом есть куча языков где всё так и сделано Вот и юзайте их, Д,Б С ... текст свёрнут, показать | |
|
|
|
6.155, KonstantinB (ok), 18:45, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
И что же будет с библиотеками, которые полагаются на gc? Все переписывать с какими-нибудь
if (runtime.gcDisabled) {
free(slice)
}
?
Не надо этого в go. Он вполне завершен и целостнен в своем дизайне. При этом он, разумеется, не универсален. Если нужен жесткий реалтайм и gc-паузы категорически неприемлемы, стоит изначально выбрать другой язык.
| |
|
|
4.18, Аноним (-), 13:59, 17/02/2017 [^] [^^] [^^^] [ответить]
| +10 +/– |
> Вообще gc убрать, сам буду кучу чистить.
Тогда бери лопату и дуй чистить кучу.
| |
|
|
2.6, Аноним (-), 13:11, 17/02/2017 [^] [^^] [^^^] [ответить]
| +18 +/– |
Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд.
Вот это весело, вот это адреналин.
| |
|
3.176, anonnchick (?), 21:35, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>Нет бы запилить несовместимый Golang 3.0 и %%%ться с ним 25 лет подряд.
Ветка 3.0 идет строго после 2.7
| |
|
|
|
2.10, Аноним (10), 13:27, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
а тебе какой нужен? а то я через плагин к Intellij Idea отлично дебажу ещё со старых версий go
| |
|
1.3, Nexor (?), 13:07, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
100 МИЛЛИсекунд? В оригинале написано 10 МИКРОсекунд... кто то ошибся, но я больше склоняюсь к ошибке в исходном тексте, т.к. иначе звучит нереально
| |
|
2.14, angra (ok), 13:47, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно не помешает некоторым рассказывать про секундные зависания из-за gc.
| |
|
3.38, Я. Р. Ош (?), 14:52, 17/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> что конечно не помешает некоторым рассказывать про секундные зависания из-за gc.
что не помешает некоторым фанатикам бугуртить, когда их священную корову еретики смеют в чем то обвинять
| |
|
4.141, _ (??), 18:14, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Обвинить - это предъявить доказательства. У _цивилизованных_ людей а не у <your nick name>
| |
|
3.54, Аноним (-), 15:10, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Где-то мы уже слышали эти сказки… Ах да — Оракол тоже всем любит рассказывать про "pausless GC". В смысле — в JVM можно ручками и паузы в сотые наносекунды поставить. Только наблюдаемые подвисания при неаккуратном выделении объектов никуда от этого не деваются. И при достижении предельной фрагментация всё так же идёёт полная сборка (или compacting, что по факту не лучше).
| |
|
4.147, Comdiv (ok), 18:24, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Было бы странно при неаккуратном выделении памяти чего-то хотеть. Free/delete тоже далеко не бесплатны, а при неаккуратном выделении вообще ведут к катастрофе.
| |
|
5.192, angra (ok), 12:16, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Поддержу, некоторые наивно считают, что наличие gc избавляет от необходимости думать о выделении памяти. Но именно на работу с памятью обращается первое внимание при оптимизации кода на go.
| |
|
|
3.205, Кай (?), 19:13, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Миллисекунды были версии три назад, теперь речь действительно о микро, что конечно
> не помешает некоторым рассказывать про секундные зависания из-за gc.
А зачем тогда вообще нужно ручное управление памятью, если GC столь быстр?
| |
|
|
|
2.12, Andrey Mitrofanov (?), 13:37, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Это версия компилятора или новая версия стандарта?
Нет стандарта, кроме версии компайлера. ///про пророка писать тут===>>>
| |
|
1.13, angra (ok), 13:44, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python.
А создатели то и не знают, что они оказывается из питона заимствовали. Они думали, что из algol-60/pascal/modula/oberon и csp/squeak/newsqueak/alef.
> что позволяет добиться производительности, сопоставимой с программами на языке Си.
С явой, плюсами, но не с С. На нишу С go никогда не претендовал.
| |
|
2.152, Comdiv (ok), 18:32, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> С явой, плюсами, но не с С. На нишу С go никогда
> не претендовал.
Это потому что Вы сужаете изначально широкую нишу С, от которой постоянно откусывают другие языки. Тот же компилятор Go изначально был написан на C, который затем был заменён самим Go. Компилятор - это ниша C или нет? Как по мне, пересечений ниш С и Go хватает.
| |
|
3.191, angra (ok), 12:11, 18/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
А если я на perl сделаю прототип видеокодека, будешь ли ты считать видеокодеки нишей perl?
| |
|
4.195, Comdiv (ok), 15:05, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А если я на perl сделаю прототип видеокодека, будешь ли ты считать
> видеокодеки нишей perl?
В самом вопросе содержатся 1-а манипуляция и 1-а логическая ошибка, правильней было бы задавать его так:
> А если я на каком-нибудь языке сделаю прототип видеокодека, будете ли Вы считать
> что в нишу этого языка входит создание видеокодеков?
Если отвечать на исправленный вопрос, то да. Если Вы справитесь с задачей так же хорошо, как и разработчики первой версии компилятора Go, написавшие его на Си, то безусловно да. Именно в практических задачах определяется применимость языка, задающая его нишу. И если и можно утверждать, что в нишу Perl не входит создание видеокодеков, то именно потому, что за разумное времени практически значимый видеокодек написать на Perl не получится.
| |
|
|
|
1.15, Аноним (-), 13:47, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
>добавлены средства для принудительного завершения соединений
Я был более лучшего мнения об этом ЯП, заточенном на сетевые приложения. Т.е. только сейчас он научился делать FIN-FIN/ACK, RST?
| |
|
|
3.209, Аноним (-), 20:41, 18/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Опеннет превратился в ЛОР.
>HTTP Server Graceful Shutdown
>The HTTP Server now has support for graceful shutdown using the new Server.Shutdown method and abrupt shutdown using the new Server.Close method.
Изучай теперь, и не говори мне что выставление опции != FIN/FIN-ACK.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms738547%28v=vs.
Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT (кои составляет примерно 2 минуты и забивает список используемых сокетов). А ты знаешь к чему ведет graceful shutdown? Нет? Знаешь когда его можно юзать, а когда -- нет? Спорю, что не знаешь.
Всё. Прощай опеннет. Одно школье и нубасы кругом.
| |
|
4.211, angra (ok), 20:59, 18/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Могу тебе сразу ответить, что будет при Graceful Shutdown: опускается этап TIMEWAIT
Возможно это вызовет у тебя нервный смех, но это опять не о том. И если бы ты удосужился почитать описание методов, а не левую статью мелкомягких, то может быть и сам бы это понял.
> Всё. Прощай опеннет. Одно школье и нубасы кругом.
Вот это молодец, полностью поддерживаю твое решение. Как говорится в одной известной песне "убей их всех... начни с себя"
| |
|
5.215, Аноним (-), 21:12, 18/02/2017 [^] [^^] [^^^] [ответить] | –2 +/– | Ах да, мега чистильщик сообщений Вот пруфы ЗА ТЕБЯ я дам Как обычно Ты же с Л... большой текст свёрнут, показать | |
5.218, Аноним (-), 21:35, 18/02/2017 [^] [^^] [^^^] [ответить] | +/– | Офигеть терминология в гугле И пруфы аналитиков просто сыпятся https go goog... большой текст свёрнут, показать | |
|
|
|
|
3.210, Аноним (-), 20:49, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Открой ты RFC 793 и прочитай кто что должен. Нубасы хреновы не знают, что делает accept(), что делает shutdown(), что делает connect(). Куда вы лезете со своими бреднями?
| |
|
|
5.227, Аноним (-), 12:35, 20/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
И что ты нашел? Что ты хочешь доказать? Что ты вообще пытаешься сказать, кроме как попытаться выставиться себя умником, выскочкой. Смотрю в школах совсем все плохо, выскочек раньше били ногами.
Итак, по делу. Кто должен вызывать shutdown() на сокет? Приложение? ОС? Мифические существа внутри коробки, что называется компьютер, а для тебя процессор?
Можешь ли ты внятно строить свои мысли, а, существо?
| |
|
|
7.231, Аноним (-), 20:43, 20/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>а много таких прикладных приложений которые дёргают сискол ОС shutdown() ?
Столько же сколько дергают сискол accept().
http://man7.org/linux/man-pages/man2/accept.2.html
И только не говори, что accept() НЕ посылает пакеты по TCP. Такие как SYN/ACK, ACK. Их посылает ОС. Сама. Без спросу. Когда солнце взойдет на западе и сядет на востоке. Тогда отправится пакет ACK. Все. Я добрый пока что. Иди учи сишку и читай маны.
| |
|
|
|
|
|
|
1.21, Owlet (?), 14:05, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> В модуль sort добавлена новая функция Slice, упрощающая сортировку данных с типом slice
Вот для чего, дети, нужны дженерики. Чтобы не было по своей функции сортировки для каждого вида последовательностей.
| |
|
2.24, Аноним (-), 14:20, 17/02/2017 [^] [^^] [^^^] [ответить]
| +6 +/– |
Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в Россию.
| |
|
3.105, Andrey Mitrofanov (?), 17:20, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию, а не в
> Россию.
Потому что "и сами они довольно неискренние, и самовар у них" неоткровенный? :D
| |
3.194, Michael Shigorin (ok), 13:03, 18/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Читая такие откровения, понимаешь почему кодирование оутсорсят в Индию,
> а не в Россию.
Потому что у нас -- разработчики, а не кодеры? Боюсь, Вы всё же приукрашиваете.
| |
|
4.212, Аноним (-), 21:01, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>Потому что у нас -- разработчики, а не кодеры? Боюсь, Вы всё же приукрашиваете.
Потому что ворье. Потому что Альт стоит как последняя винда в коробке.
А в Индии как раз все дешево и сердито. Между прочим не видел ни одного русского разраба на андроиде, который мог тянуть фулстак разработку. А индусов полно. И все у них очень качественно.
Жду рассказа про очевидные вещи #2.
| |
|
|
2.160, KonstantinB (ok), 18:55, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Вот отсутствие дженериков в том или ином виде - это действительно недостаток.
Но каноничные джава-дженерики не подойдут к модели типов go. Наверное, можно было бы решить вопрос, разрешить писать реализации по умолчанию для интерфейсов, но слишком неявно получается.
| |
|
1.26, Ilya Indigo (ok), 14:24, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
> Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python.
В бочку с мёдом добавили ложку дёгтя.
| |
|
2.44, Аноним (-), 15:00, 17/02/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
Это как раз была ложка меда, тщательно выскребенная и отцеженная из бочки с дёгтем.
| |
|
3.179, Led (ok), 22:26, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это как раз была ложка меда
Этот "мёд" уже один раз кто-то ел.
| |
|
|
1.55, Аноним (-), 15:11, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт.
| |
|
2.65, Аноним (-), 15:29, 17/02/2017 [^] [^^] [^^^] [ответить]
| +9 +/– |
> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
> никаких проблем это не создаёт.
Совершенно никаких, даром что USE-AFTER-FREE входит в 20ку самых эксплуатируемых уязвимостей. Примерчик с пылу с жару:
CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
| |
|
3.68, Аноним (-), 15:35, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Мне кажется люди просто не знаю, что уже давно проблема ручного контроля освобождения памяти решена std::unique_ptr. Все до сих пор считают что там, где нет сборщика мусора, надо писать что-то вроде:
> TYPE n = new TYPE()
> .....
> // много кода
> delete n;
Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик.
| |
|
|
5.77, Аноним (-), 15:55, 17/02/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается он через определенные промежутки времени. Т.ч. в языке со сборщиком мусора объекты могут жить дольше, но не меньше. И при этом дольше - это обычно во много раз дольше. В с++ даже локальный объект можно удалить автоматически до выхода из функции просто ограничив ему область видимости фигурными скобками. В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.
| |
|
6.86, Аноним (-), 16:10, 17/02/2017 [^] [^^] [^^^] [ответить]
| +7 +/– |
> Сборщик мусора не удалит объект, пока на него есть ссылки. И запускается
> он через определенные промежутки времени.
Фееричные-познания-в-теме-рука-лицо.жпг
> В с++ даже локальный
> объект можно удалить автоматически до выхода из функции просто ограничив ему
> область видимости фигурными скобками. В том же Go он будет жить
> еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.
Опять тайные знания? На самом деле есть только один GC, а еscape анализ придумка маркетологов?
| |
|
7.121, Аноним (-), 17:52, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ветка про сборщик мусора, а не про Go. Везде разные реализации сборщика.
| |
|
6.90, Аноним (-), 16:23, 17/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> В том же Go он будет жить еще несколько мс после завершения функции, пока сборщик не соизволит пошевелиться.
Go использует стандартную реализацию стека. Все локальные переменные будут удалены* мгновенно при возврате из функции, аналогично с/с++.
*Указатель на стек вернется в состояние до вызова функции.
| |
|
7.97, hoopoe (ok), 16:47, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
там же замыкания на уровне языка реализованы... как их на стек положить?
| |
|
8.125, Мяут (ok), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить] | +2 +/– | Там компилятор автоматически определяет, нужно ли переменную на стеке создавать ... текст свёрнут, показать | |
|
9.172, Аноним (-), 21:11, 17/02/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Еще зависит от размера и типа переменной и от самой функции, как она вызывается ... текст свёрнут, показать | |
|
|
|
|
5.78, Аноним (-), 15:56, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Системы с ограниченными ресурсами самое то, чтобы распылять их на потуги сборщика и висящие неиспользуемые объекты, которые он непонятно когда удалит.
| |
|
6.156, Аноним (-), 18:48, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
На автоматическое управление памятью тратятся вычислительные ресурсы машины.
На ручное управление памятью тратятся временные ресурсы программиста.
Говорить о том, какой выбор оптимальнее можно только в конкретных случаях. Например, если использовать ручное управление памятью и потерять на это месяц работы, мы заработаем примерно $10000, а если направим время программистов на написание фичи X, то заработаем примерно $15000, 15000 > 10000 -> нет смысла тратить время на ручное управление памятью.
| |
|
7.173, Аноним (-), 21:14, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Написали уже, оптимальный - умные указатели. Никакого тебе сборщика мусора и ручного освобождения памяти. Месяц вы никак не потеряете, обернуть вызов new в умный указатель - пара секунд.
> TYPE *p = new TYPE();
в
> std::unique_ptr<TYPE> p(new TYPE());
И всё.
| |
|
|
5.80, Аноним (-), 15:57, 17/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и т.д.
| |
|
6.88, Василий Теркин (?), 16:13, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Краши уже в прошлом, есть статические анализароры, умные указатели, диапазонные циклы и
> т.д.
Вы серьезно?
| |
|
7.124, Аноним (-), 17:55, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
Для меня да. Ваш уровень знания языка вероятно гораздо ниже, раз краши для вас обыденность.
| |
|
|
|
4.94, Ordu (ok), 16:30, 17/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Мне кажется люди просто не знаю, что уже давно проблема ручного контроля
> освобождения памяти решена std::unique_ptr. Все до сих пор считают что там,
> где нет сборщика мусора, надо писать что-то вроде:
>> TYPE n = new TYPE()
>> .....
>> // много кода
>> delete n;
> Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а
> не когда соизволит сборщик.
Если бы всё было так просто, то мемликов бы не было. Вообще нигде не было бы, даже в ассемблере. Иногда хочется иметь ссылку на объект в разных стековых фреймах, а иногда ещё и в структурке хранить её удобно. А ещё иногда объект прямо или косвенно ссылается сам на себя, тогда даже ref_count не всегда спасает.
| |
|
5.108, Аноним (-), 17:35, 17/02/2017 [^] [^^] [^^^] [ответить] | –3 +/– | А не всё так просто Но и не всё так ужасно Как это В ассемблере же ни смарт-п... большой текст свёрнут, показать | |
|
6.158, Ordu (ok), 18:51, 17/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Потому что до тех пор, пока у нас есть указатель вписывающийся в идею uniq_ptr, ... большой текст свёрнут, показать | |
|
7.165, Аноним (-), 19:31, 17/02/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Не всегда просто Легко забыть сделать delete перед return в середине функции О... большой текст свёрнут, показать | |
|
8.168, Ordu (ok), 20:10, 17/02/2017 [^] [^^] [^^^] [ответить] | +3 +/– | Вот нефиг писать исключительно на C Попробуй пописать на C или asm годик, теб... большой текст свёрнут, показать | |
|
9.175, Аноним (-), 21:21, 17/02/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Может так и есть, но ведь так удобно Выяснил, что больше делать нечего, и до... большой текст свёрнут, показать | |
|
10.178, Ordu (ok), 22:17, 17/02/2017 [^] [^^] [^^^] [ответить] | +/– | Ну, много чего есть удобного, что потом может выйти боком Для этого и придумыва... большой текст свёрнут, показать | |
|
|
|
|
6.184, анонимчик (?), 23:23, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>В С++ есть решение из коробки, std::shared_ptr. Помогает в большинстве случаев.
который на каждый чих мьютекс блокирует.. проще на питоне написать и слипы повставлять.
| |
|
|
6.164, Ordu (ok), 19:26, 17/02/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Во всех этих случаях требуется пересмотр архитектуры приложения.
Требуется. И что? Ну пересмотришь ты её, а дальше что? Будешь переписывать пару сотен тысяч строк кода? Или ты до сих пор веришь в миф 90-х годов о том, что программу можно спроектировать заранее так, чтобы потом не возникало проблем с архитектурой?
| |
|
7.182, Аноним (-), 23:06, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Или ты до сих пор веришь в миф 90-х годов о том, что программу можно
> спроектировать заранее так, чтобы потом не возникало проблем с архитектурой?
Это "стало мифом", когда стало модно быть балбесом.
| |
|
8.185, Ordu (ok), 00:03, 18/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Может быть Но я склонен разделять мнение этих 95 , которые считают, что проблем... большой текст свёрнут, показать | |
|
|
|
|
4.118, Аноним (-), 17:49, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Нет, не решена. Программист должен изначально знать нужен ему unique_ptr или shared_ptr, а может weak_ptr?
В языках с GC об этом можно просто не думать, там везде shared_ptr.
Это ещё не говоря о том, насколько замусоривается код:
fun() -> std::unique_ptr<std::array<std::shared_ptr<Node>>>;
| |
|
5.131, Аноним (-), 18:00, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
shared_ptr, а уж тем более weak_ptr - это вообще наиредчашие случаи. Я за 15 лет программирования shared_ptr использовал только один раз.
А код замусоривается потому что неправильно пишете.
Вот это вот:
> std::unique_ptr<std::array<std::shared_ptr<Node>>>
очевидно неправильная конструкция, надо разбираться, почему такая х получилась.
| |
|
6.149, Аноним (-), 18:25, 17/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Не думаю, что редчайшим случаем является ситуация, когда неизвестно кто из владе... большой текст свёрнут, показать | |
|
7.177, Аноним (-), 21:43, 17/02/2017 [^] [^^] [^^^] [ответить] | –1 +/– | Ситцация, когда нужен shared_ptr Такая ситуация является просто очень редкой П... большой текст свёрнут, показать | |
|
|
|
4.189, Андрей (??), 07:25, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Но нет, объект удаляется автоматически, и тогда, когда это нужно программисту, а не когда соизволит сборщик.
А что с динамическим выделением объекта? Он-то выделится тогда, когда это нужно программисту, но от этого не легче, так как алгоритм выделения в куче не ограничен константным временем. А всё дело во времени: не хочется иметь непредвиденных задержек. Так вот с GC они и так уже небольшие, а что с выделением в куче?
| |
|
5.200, Аноним (-), 17:49, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Какой аллокатор напишешь - так и будет выделяться. А GC никогда не был и не будет предсказуем.
| |
|
6.223, Андрей (??), 15:48, 19/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Какой аллокатор напишешь
Так можно и язык свой написать. Я говорю о тех, что под капотом в glibc и в stdlibc++. По-умолчанию (начиная с какого-то размера объекта, наверное), он тоже не предсказуем. Да ещё и куча фрагментируется.
| |
|
|
|
3.104, Аноним (-), 17:19, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
>> никаких проблем это не создаёт.
> CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
Абы ляпнуть чтоль?
Ядро Linux написано НЕ на С++. Ваш Кэп.
| |
|
4.110, Василий Теркин (?), 17:37, 17/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>>> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
>>> никаких проблем это не создаёт.
>> CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
> Абы ляпнуть чтоль?
> Ядро Linux написано НЕ на С++. Ваш Кэп.
Писали бы на С++ вообще бы Линукса до сих пор не было.
| |
|
5.113, Аноним (-), 17:42, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к С++ был, так или нет?
| |
|
6.145, Василий Теркин (?), 18:19, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Что за перевод темы такой? Пассаж про CVE-2016-7117 не в тему к
> С++ был, так или нет?
Все в тему. С и ассемблер тоже без мусорки. Но и без ООП со всякими с++ плюшками. Поэтому разрабы до сих пор не рискуют переводит код ядра на с++. Слишком большой код и слишком малдо времени, чтобы его отладить.
| |
|
|
4.174, Аноним (-), 21:17, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Ядро Linux написано НЕ на С++. Ваш Кэп.
На Go что ли? Если серьезно, причем здесь ядро вообще?
| |
|
3.183, Аноним (-), 23:23, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> > Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
> > никаких проблем это не создаёт.
> Примерчик с пылу с жару:
> CVE-2016-7117 - критическая дыра в ядре Linux Рейтинг опасности 10/10
Ядро Linux это примерчик того, что в C++ нужен сборщик мусора?
Ну вот как, как к таким умозаключениям приходят?
P.S.
Эта критическая дыра не зависит от сборщика мусора в C++,
так как ядро Linux не на C++ написано.
| |
|
2.93, Аноним (-), 16:26, 17/02/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
Да-да, С++ нахваливают, что память нужно вручную освобождать и юзают при этом умные указатели
| |
|
3.134, Аноним (-), 18:03, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Как раз вручную память освобождать не следует. И язык позволяет обходится без этого непотребства и сборщика мусора одновременно.
| |
|
2.96, Толл (?), 16:35, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и никаких проблем это не создаёт.
Сильное утверждение. Проверять я его, конечно же, не буду. (с)
| |
|
3.135, Аноним (-), 18:05, 17/02/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
Вот и создатели Go не стали. И получилось что имеем - большой костылище для решение проблемы, решаемой простой структурой - умным указателем.
| |
|
4.154, Mike Lee (?), 18:45, 17/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Точно. Засунем все в смартпоинтеры, потрахаемся с копированием, удалим auto_ptr потому что не работает, добавим мув семантики, но будем понтоваться, что сборщик мусора не нужен.
| |
|
5.201, Аноним (-), 17:56, 18/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Смарт поинтеры нужны в единичных случаях, т.к. обычно достаточно контейнеров. В мув семантике ничего сложного нет, rvalue ссылки + конструктор перемещения, осваивается минут за 10. Смарт поинтера по сути 2 - unique_ptr для единоличного владения и shared_ptr для множественного. Проблемы по сути нет, а уж воротить для её решения GC - верх иди
| |
|
|
|
2.98, Василий Теркин (?), 17:05, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Никогда не понимал, зачем нужен сборщик мусора? В С++ его нет, и
> никаких проблем это не создаёт.
Прогони в С++
class Node {
public:
Node* next;
};
for (int i = 0; i < 10000000; i++) {
Node* v = new Node();
}
А потом в С#
class Node
{
public Node next;
}
for (int l = 0; l < 10000000; l++)
{
var v = new Node();
}
Если в сях еще прикрутить delete, то ты поймешь преимущество GC сишарпа по рантайму. Да, конечно, примерчик так себе, но показателен. Аллокаторы тоже жрут ресурсы, представь себе!
| |
|
3.139, Аноним (-), 18:11, 17/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Да, конечно, примерчик так себе, но показателен
Не показателен. Так никто не пишет. Для С# это вполне нормальный код, т.к. разработчик не должен знать как всё устроено внутри и язык не должен выполнять код буквально. C++ же дает гарантии, что код будет выполнен точно так, как напишет программист. Поэтому программист должен понимать как и что работает, и писать правильно.
| |
|
4.143, Аноним (-), 18:17, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Поэтому программист должен понимать как и что работает, и писать правильно.
Только вот считающих, что уж они понимают, как что-то работает, во все времена было больше
действительно понимающих. Особенно, если важна не только принципильная схема, но и нюансы.
| |
4.151, Василий Теркин (?), 18:31, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Да, конечно, примерчик так себе, но показателен
> Не показателен. Так никто не пишет. Для С# это вполне нормальный код,
> т.к. разработчик не должен знать как всё устроено внутри и язык
> не должен выполнять код буквально. C++ же дает гарантии, что код
> будет выполнен точно так, как напишет программист. Поэтому программист должен понимать
> как и что работает, и писать правильно.
Ну тогда напиши код для cpp "правильно", сделав тоже самое, но за меньшее время чем это делается сишарпе. Задачка-то простая.
| |
|
5.202, Аноним (-), 17:59, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Решение предельно простое, не выделять память 10000000 раз, как ииот.
| |
|
|
3.150, Ivan (??), 18:30, 17/02/2017 [^] [^^] [^^^] [ответить] | +3 +/– | Не хочется кормить тролля, но один раз отвечу Данный пример ничего полезного не... большой текст свёрнут, показать | |
|
|
5.167, Аноним (-), 19:45, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
А что про Python и Ruby скажете? Скорость разработки на них выше, чем на Java. И, подозреваю, выше, чем на Go. Считаете, что дольше надо будет добиваться РАБОТОСПОСОБНОГО решения?
| |
|
6.228, Василий Теркин (?), 14:56, 20/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну вроде оба этих языка относятся к интерпретируемым(за исключением отдельно привязываемых костылей). И у обоих есть сборщики мусора. И если решение на этих языках конкретных задач более эффективно, чем на GO или С++, то я отношусь к этим языкам весьма положительно. И буду дальше добиваться РАБОТОСПОСОБНОГО приложения, по причине того, что НЕРАБОТОСПОСОБНЫЕ никому не нужны, кроме их авторов.
| |
|
|
|
|
|
1.64, Аноним (64), 15:26, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Осторожно, влюбиться в него очень просто.
При этом уровень вхождения выше среднего, из-за настроек, что отсекает Гкодеров типа PHP.
| |
|
2.70, Аноним (-), 15:39, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в язык. Настроить может любой другой человек, помимо программиста. А программисту знать настройки чтобы писать код - не нужно.
| |
|
3.75, Василий Теркин (?), 15:49, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Всё ровным счетом наоборот. И настройки не относятся к уровню вхождения в
> язык. Настроить может любой другой человек, помимо программиста. А программисту знать
> настройки чтобы писать код - не нужно.
Разве что программисту на бэйсике. А уж CPP-программеру, например, без знания настроек компилятора... Совсем худо.
| |
|
4.81, Аноним (-), 16:00, 17/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> sudo apt-get install qt-sdk
или если под виндой - скачать и поставить sdk с оф.сайта.
Дальше можно писать код. Чтобы собрать - надо нажать кнопочку в левом нижнем углу. И ни капельки не худо.
| |
|
5.82, Аноним (-), 16:02, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Хотя в конкретном случае Qt Creator достаточно, он сам подтянет зависимости
| |
|
|
|
|
1.91, Аноним (-), 16:25, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А если на этой штуке игровой движок накатать, все будет совсем плохо? Как оно по сравнению с С++ по производительности
| |
|
2.142, Аноним (-), 18:15, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Со сборщиком мусора придётся побороться. Но эта проблема всех больших проектов на подобных языках. Сборщик начинает захлёбываться без подсказок.
| |
2.153, Аноним Аналитег (?), 18:36, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Думаю игровых движков должно быть мало как раз из-за gc, который может создавать неожиданные паузы. Тут то лучше пусть и не быстрый real time чем неожиданный возникший stop the world. В жабе такие вещи решаются тюнингом работы gc как например в Revenge of the titans, количество используемых ключей и параметров к jvm для запуска меня удивило.
| |
|
1.95, Аноним (-), 16:31, 17/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
func g() // !
{ // НЕВЕРНО
}
if x {
} // !
else { // НЕВЕРНО
}
func g(){ // ВЕРНО
}
if x {
} else { // ВЕРНО
}
После этого язык GO для меня не сущесвует
| |
|
2.99, Аноним (-), 17:06, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
func g()// НЕВЕРНО
{
}
>>После этого язык GO для меня не сущесвует
Платят за количество строк?
Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку:
int
main()
{
//овнокод.
}
выглядит инфернально.
| |
|
3.136, Аноним (-), 18:05, 17/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Платят за количество строк?
Нет, просто такой код легче читать.
> Я знаю эти удаки на С/С++ еще и возвращаемый тип переносят на отдельную строку
Представьте себе, иногда не лишено смысла. Но вы можете продолжать писать код в одну строку, если хотите.
Любой язык, который навязывает стиль оформления, ущербный по определению.
// другой Аноним
| |
3.186, Аноним (-), 04:38, 18/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
int
main()
Это оправдано, потому что в отличие от хелловордов, в реальном коде это выглядит как-то так:
static inline struct node *
node_create(const char *key, const char *value, int flags, size_t size)
{
...;
}
| |
3.220, Аноним (-), 22:16, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Да-да, ты прав:
https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/crtstuff.c?view=markup
277 static inline void
278 deregister_tm_clones (void)
279 {
280 void (*fn) (void *);
281
282 #ifdef HAVE_GAS_HIDDEN
283 func_ptr *end = __TMC_END__;
284 // Do not optimize the comparison to false.
285 __asm ("" : "+g" (end));
286 if (__TMC_LIST__ == end)
287 return;
288 #else
289 if (__TMC_LIST__[0] == NULL)
290 return;
291 #endif
Кругом дураки, а ты самый-самый. Иди возьми пирожок.
| |
|
|
3.148, Аноним (-), 18:24, 17/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
При том, что это явно замедляет разработку, а они борются за каждую секунду разработчика
| |
|
4.187, Аноним (-), 04:39, 18/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Просто баранье упёрство, хотя там напрашивается warning, а не error
| |
4.196, angra (ok), 15:36, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ты просто не понимаешь, что экономить на до не на спичках(уменьшение времени на набор текста), а на водке(уменьшение времени затрачиваемого на отладку).
| |
|
|
2.103, Аноним (-), 17:18, 17/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Форматирование переносом строк для чайников, том 2.
func g ()
{
// верно
}
func g
(
)
if x
{
/
*
а
т
л
и
ч
н
а
*
/
}
| |
2.146, Аноним (-), 18:21, 17/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Я предпочитаю так:
>if x {
>...
>}
>else {
>...
>}
А с функциями зависит от количества аргументов. Например часто так получается:
>// ----------------------------
>func g(TYPE arg1,
> TYPE arg2,
> TYPE arg3,
> ....)
>{
>...
>}
Но у маленьких функцию пишу так:
>// ----------------------------
>func g() {
>...
>}
Т.к. функции отделены комментарием, не принципиально где будет открывающая фигурная скобка, всё равно всё видно сразу. Но в Go работает только последний вариант.
| |
|
3.188, Аноним (-), 04:41, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>func g(TYPE arg1,
> TYPE arg2,
> TYPE arg3,
> ....)
Если тебе такое понадобилось, с высокой вероятностью эту функцию стоит переделать: слишком длинный список аргументов, неиспользование typedef или слишком длинные имена параметров.
| |
|
2.197, angra (ok), 15:43, 18/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> После этого язык GO для меня не сущесвует
Одной из основных целей при разработке go и его дальнейшем развитии была и остается скорость сборки. Успех в этой области складывается в том числе и из таких вот мелочей. Но у таких ограничений есть и бонус - не надо ставить ';' в конце строк.
Чтобы тебя окончательно добить, сообщу страшную вещь, на go принято пропускать код через форматировщик. В результате у всех код в одном визуальном стиле. Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП.
| |
|
3.207, Аноним (-), 20:19, 18/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Так что для самовыражения в форматировании действительно лучше выбрать другой ЯП.
На мой взгляд предложенное форматирование в Go - самовыражение его разработчиков. В моём круге общения такой стиль считается неправильным и не приемлем.
| |
|
4.224, Андрей (??), 15:59, 19/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Неправильный стиль? Синтаксически корректный стиль оформления кода не бывает неправильным! Неприемлемый - пожалуйста. На вкус и цвет, как говорится.
А какой из общепринятых K&R, GNU, original Berkeley, Linux,.. приемлем? Или тот, что в js с jquery?
| |
4.232, Аноним Аналитег (?), 21:15, 20/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> В результате у всех код в одном визуальном стиле.
> В моём круге общения такой стиль считается неправильным и не приемлем
Мой опыт говорит, что в каждом монастыре свой code convention. Причем каждый кейс обоснуют. Многие ide позволяют подробно задать параметры форматтера. Слышали про collective code ownership?
| |
|
|
|
|