Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
package main
import "log"
func foo(x int) (int, error) {
return x + 1, nil
}
func main() {
x := 5
if x % 2 == 1 {
x, err := foo(x)
if err != nil {
log.Fatalf("Error")
}
log.Println(x)
}
log.Println(x)
}
Счастливой отладки, суки.
https://godbolt.org/z/6GWsq7W7q
Запостил: 
3_dar,
29 Июня 2022
Follow us!
Нет силенок изучить что-то посерьезнее?..
Что такое FUNCDATA?
>The Go compiler outputs an abstract, portable form of assembly that doesn't actually map to any real hardware.
понятно. LLVM очередной
Хочешь пельменную? Изволь писать var.
https://govnokod.ru/26961#comment576189
А вот я за давание в ибло за случайное затенение.
Хочешь затенить (бывают такие лагоритмы, где удобно затенять) -- ставь подавляющую собачку
https://ideone.com/LqUzte
Ахаха. Выбрось его на помойку
скажи
env: {
browser: true,
node: true,
},
и будет заябись
https://eslint.org/docs/latest/rules/no-undef#environments
Но вообще обсёр GCблядей и их ручное управление ресурсами это прича во языцех: Джависты тоже такой хуец сосут, и всякие питонисты тоже.
И только в божественных языках типа C++ и ObjC со siwft все закрывается само
А он абсолютно всегда ругается? Понятное дело, что большинство адекватных людей реализуют dispose по каноничному паттерну, когда в Dispose() для очистки анменеджед ресурсов используется тот же самый код, что и в финализаторе, тогда конечно GC.SuppressFinalize(this) необходим, чтоб по второму кругу одно и то же не делать. Да даже если нет финализатора, то ничего страшного от этой строки не случится.
Но что если говнокодер решил реализовать dispose по-своему, потому что он так видит? Например, в финализаторе чистятся анменеджед ресурсы, а в Dispose() в силу каких-то неведомых причин — только менеджед. Если в таком случае воспользоваться подсказкой анализатора и добавить SuppressFinalize, то после вызова Dispose() до анменеджед ресурсов дело никогда не дойдёт!
>обсёр GCблядей и их ручное управление ресурсами
Да это вообще пиздец. Сначала они говорят, у нас же тут GC, говнокодь спокойно, не думай ни о чём, сборщик мусора говно за тобой подберёт. Но на деле ты сидишь и вилкой чистишь дёргаешь Dispose() (хорошо хоть юзинги есть, всё лучше, чем Dispose() явно вызывать), а потом в рантайме охуеваешь от того, что уже задиспоженный объект оказывается где-то ещё использовался...
Потом оказывается, что ресурсы это не только память.
Потом оказывается, что ресурсы нужно освобождать как-то по особому (Жаба обсирается со своими незапускающимися финализаторами и прикручивает костыли)
Потом оказывается, что на компьютере запущена не только твоя программа, ресурсами надо делиться и освобождать их СЕЙЧАС, а не когда GC раздуплится. (Обсираются все, прикручивают костыли)
Потом говорят, что ресурсы — это не только память, и предлагают представить открытые файлы.
Потом предлагают смешать память и файлы.
Когда зомбируемый предлагает закрыть ресурсы, чтобы дать поработать другим программам, зомбирующий повторяет: «Зачем? Зачем?»
Он возвращает DirectBuffer (такое окошко в неуправляему память), которое никак не уничтожить кроме как через GC
Еще раз по буквам: заммапленный в память файл нельзя закрыть!
У дотнетблядей MemoryMappedFile хотя бы IDisposable, а у жабойобов нет
Жавайобы ловко выходят из положения
https://stackoverflow.com/questions/2972986/how-to-unmap-a-file-from-memory-mapped-using-filechannel-in-java/19447758#19447758
>ByteBuffer.allocateDirect(4096);
Ахаха. В Йажу завезли malloc/free.
Какое русное управление памятью )))
Edit 1:
> sun.misc.Cleaner
Блять, и предлагают использовать кишки jvm из пакета sun.*
А в следующей жвм это выпилят нахуй.
Write once — debug everywhere.
Edit 2:
Пхахахах. В приведённом ответе они пошли ещё дальше и т.к. 9й жове всё сломали, они... используют другой класс из кишком жвм jdk.internal.misc.Unsafe.
Пиздец²
Во-первых он не отличается интерфейсом от обычного буффера, и узнать можно только в рантайме.
Некоторый кот идет в byte[] (который есть в обычном буффере) и падает если буфер дайрект
Я использовал direct buffer для общения с либами, котоыре умеют неуправляемую память, бо писаны на си, и подключены чирез JNI/JNA
В частности zstd, xxhash, и кто-то для реализации http2 (апаче поди)
JCEF так же передает указатель на DirectBuffer.
Можно налажать, и упасть врантайме
Во-вторых, когда у тебя кончается неуправляемая память, ты получаешь OOM, но в дампе ты видишь хуй, потому что все yourkitы и прочие профилировщики показывают тебе только кучу
ну и третий багор это невозможность сделать free (ну или close в случае mmap) без платформозависимой рефлексии
Ой, не могу. Там весь ответ достоен отдельного поста.
>From the MappedByteBuffer javadoc:
> A mapped byte buffer and the file mapping that it represents remain valid until the buffer itself is garbage-collected.
> Try calling System.gc()? Even that's only a suggestion to the VM.
В любой непонятной ситуации вызывай System.чисти-чисти-чисти()
> The method covered in other answers that employs ((DirectBuffer) byteBuffer).cleaner().clean() doesn't work on JDK 9+ (even in reflective form) without displaying an An illegal reflective access operation has occurred warning.
> This will stop working altogether in some future JDK version.
> Fortunately sun.misc.Unsafe.invokeCleaner(ByteBuffer ) can make that exact same call for you without the warning: (from OpenJDK 11 source):
Нет, ну почему жавухи такие выблядки?
Нахуя было делать шалаш из костылей, обмазанных говном, а потом ломать обратную совместимость?
Надо еще потом вручную dispose у детей дергать
https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose
куча бойлерплейта
Есть еще вот такая писька, это попытка превратить хендлеры в управляемые ресурсы
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.safehandl e
А какой-нить свифтер с ARC наверное со смеху лопнет
Если бы там было явно var, то инею бы понял, что он декларирует какую-то другую пельменную, и та тенит эту
Однако ловкое смешивание декларации с присваиванием сыграло с пастором злую шутку
Вот в ЙС как не напишешь, всё понятно и работает логично.
Ещё я пробовал ворнинг какой-то из goвна вымучить. Но флаги тотально уебанские, ничего полезного оно не высирает.
This issue now tracks various proposals that have been made, among them:
* disallow shadowing outer variables
* allow arbitary expressions on the lhs
* don't require something new on the lhs
По военной дороге
Шел в борьбе и тревоге
Боевой двенадцатый год этого сраного issue
Какое Goвно )))
Справедливости ради в gcc/clang/g++/clang++ с кобенацией -Wall -Wextra -Wpedantic не пишет ничего.
Нужен явный -Wshadow.
С кровавых не пришедшие полей,
Не в землю эту полегли когда-то,
А превратились в белых лошадей.
У нас в перле например есть два скоупа: my и our. Первый работает на уровне блоков, второй -- на уровне модуля (по сути это как автоматическая и глобальная пельменная в няшке)
Можно и не указывать my/our, но тогда тебя выебет стрикт мод и критик в придачу
а у пыха я не понимаю, что где определяется
В целом, неявная декларация это скорее плохо
-------
фанни факт: в перл4 был только our, и это порождало бугурт. По счастью, многие программисты современные тогда еще не родились
У нас в «PHP», например есть два скоупа. global и local.
Первый работает на уровне функций, второй на уровне мудуля.
Чтобы взять глобальную пельменную в функции нужно объявить её через слово global (или взять в спец. масиве)
> а у пыха я не понимаю, что где определяется
https://ideone.com/kgtER4
> В целом, неявная декларация это скорее плохо
В «PHP» всё явно. Именно поэтому я за «PHP».
EDIT: * ещё есть третий режим, это захват внешних пельменных в лямбды через use ()
А кудахтушки только кудахтают: «Да вот у нас в пёрле, да вот у нас в питоне. РНР это фууу».
А в реальности, уже лет пять как PHP — это чемпионский скриптовый язык.
Причём он сливает даже конпелируемую Йажу. Которой нужна кастомная реализация ArrayGLista без боксинга чтобы показать что-то приличное.
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-php-performance-benchmark-2016/
> The clear winner among the script languages is… PHP 7.
> Yes, that’s not a mistake. Apparently the PHP team did a great job! The rumor that PHP 7 is really fast confirmed for this particular benchmark test.
Java 8 (non-std lib) slower 27%
Притом что в PHP используются компоненты сугубо из коробки:
https://github.com/famzah/langs-performance/blob/master/primes.php
* язык компилируемый, есть Hotspot и JIT. Потому он работает почти так же быстро как Сишка
* язык удобный, высокоуровневый с богатой стандартной библиотекой, лямбдами, форычами и прочими плюшками
Только вот дело в том, чтобы Йажа заработала на скоростях, сопоставимых с Сишкой, нужно
а) отказаться от форычей, лямбд, стримов
б) из-за боксинга отказаться от стандартных коллекций, списков, очередей и прочих контейнеров.
Придётся писать руками свои контейнеры IntList, или брать third party либы.
То есть писать в стиле, похожем... на Сишку.
Всегда было забавно, как добавление «удобного лаконичного синтакса» часто добавляло нового смешного майндфака.