Программирование[10]

Инструмент созидания искусства.

ну если говно это искусство, то да

DomikTS- написал 10 часов назад:

главное определиться - язык это

Клоун у пидарасов. Я думал, все знают.

Just.Doit написал 14.11.2021 в 12:03:

Grohuf написал 14.11.2021 в 11:45:

GoldRobot написал 14.11.2021 в 10:17:

Vova написал 14.11.2021 в 09:16:

выходят из ваших ИТМО бабы не могущие по списку пройтись

сексист

Показать больше  

Бабы работают в профессиях, где не сложно работать. Присутствие баб сильно демпингует оплату труда и выдавливает мужчин. Но в IT рынке такая острая нехватка рабочих рук, что даже несмотря на то, что среди ручных тестировщиков женщин где-то 50%, все равно оплата труда высокая и достаточная для мужчин.

тфу блять

как же этого убого

просто пиздец

 

 

Дуит реально с ума сошел

Жесть

ля чо придлагает

революция нахер
https://github.com/hsutter/708

Vova написал 20 минут назад:

Just.Doit написал 14.11.2021 в 14:03:

Grohuf написал 14.11.2021 в 13:45:

GoldRobot написал 14.11.2021 в 12:17:

Vova написал 14.11.2021 в 11:16:

выходят из ваших ИТМО бабы не могущие по списку пройтись

сексист

Показать больше   Показать больше  

Бабы работают в профессиях, где не сложно работать. Присутствие баб сильно демпингует оплату труда и выдавливает мужчин. Но в IT рынке такая острая нехватка рабочих рук, что даже несмотря на то, что среди ручных тестировщиков женщин где-то 50%, все равно оплата труда высокая и достаточная для мужчин.

тфу блять

как же этого убого

просто пиздец

 

 

 

Дуит реально с ума сошел

 

Жесть

ну может ему запрещено быть сексистом из-за жены + общества, где он живет; но ведь и раньше у него не было ничего сексистского в его мессагах

CriErr написал 5 минут назад:

ля чо придлагает

революция нахер
https://github.com/hsutter/708

Эм но ведь

in - f(const &x) / f(x)

inout - f(&x)

out - f(&x) - разницу для внешнего пользователя с inout не несет, кроме редких случаев

move - f(&&x)

forward - f(auto x)

2е не понял. У нас  и так рво всегда смувит если можно. А если не можно, не смувит?

GoldRobot написал 1 минуту назад:

CriErr написал 16 минут назад:

ля чо придлагает

революция нахер
https://github.com/hsutter/708

Показать больше  

Эм но ведь

in - f(const &x) / f(x)

inout - f(&x)

out - f(&x) - разницу для внешнего пользователя с inout не несет, кроме редких случаев

move - f(&&x)

forward - f(auto x)

 

2е не понял. У нас  и так рво всегда смувит если можно. А если не можно, не смувит?

это предложение в ИСО, там гит есть пдф с объяснениями по всей хуйне в деталях с табличками примерами сейчас -предлагаю вот так
если инетресно.

основная задумка, как я понял, уйти от того чтобы в декларации писать "что я делаю" к тому "что я буду с этим делать" и дать компилятору выбирать самому
так как в стандарт идет, там на месте компилятор и проверит чтобы ты не жульничал и не пробовал писать в "ИН" параметр и читать из "АУТ" параметра, который врайт онли.
ну и офк, вручную написать по старинке сможешь как всегда.

Я прям очень за это предложение сейчас, но экспертам на пд придется объяснить почему хуйня и мнение мое хуйня.

Первое почему хуйня, это дублирование существующего функционала. Не опять, а снова. Столько лет апгрейдились до теймплейтов, до ауто, и всего прочего.

С++ и так очень большой язык, с л о ж н а. Ну да ладно, это другой толк.

Итого, я так понимаю, чисто что бы отделить out от inout? Я, даже не знаю. Челики const то не пишут когда получают параметр который не должны менять, а ты о таком пишешь.

Но, вообще, это полезно для других случаев. Сейчас ты не можешь сделать conditional move параметр без теймплейтов и прописывания std::forward. Появилось auto &&x, но тогда ты не указываешь тип. Можно написать через концепт CONCEPT auto &&x, но это рак и оверкил.

Это нужно, например, когда ты принимаешь какую-то жирную стрингу и хочешь ее смувить к себе если это возможно, а если нет, то скопировать. и начинается дрочь void f(auto &&str){...std::forward<decltype(str)>)(str)...};.

Либо ты всегда по value принимаешь, но тогда у тебя лишний конструктор вызовется даже если челоик сделает std::move.

И вот для таких вещей, это прям ОЧЕНЬ нужная вещь. Но я думаю это легко можно сделать просто разрешив указывать тип перед auto, это все что нужно.

Кстати, раз зашла про стандарт плюсов, то не кажется ли вам, что вся хуйня вокруг итераторов - нереально юзелесс поебота? То есть вся эта абстракция - полная хуйня. Ее в каких-нибудь современных языках копируют?

То есть вот у меня есть алгоритм сортировки. В 99.99% случаев я буду сортировать вектор. Или же делать кучу из вектора.

Алгоритмы типа std::any_of или transform - жутко кринжовая хуйня, которая непонятно зачем существует. В результате наворотили говна, которое приходится расхлебывать и все непонятно ради чего.

И как так вообще получилось, что из вполне адекватного языка Си получилась такая поебень как си++?

Челы просто Гессе перечитали 

С каждым постом дуита все меньше в европу хочется, кек. Ему там походу со всех щелей в голову повесточкой срут, так и с ума сойти можно.

@Just.Doit, у вас там собирают митинги чтоб рассказать как опасны мужчины, что нужно в приоритете брать женщин и цветных на работку и подобное? Расскажи плиз, интересно!!!

Ты раньше мб и не был нацистом, но вот так кринжово резко не реагировал на такое

GoldRobot написал 2 часа назад:

Первое почему хуйня, это дублирование существующего функционала

Не дублирование.
Весь этот функционал это замена текущим комбинациям функционала под одним именем.
Ты пишешь хочу
(In Int32 Var)
а компилятор смотрит что такое Инт32, и изза того что его в функцию передаешь чтобы она могла читать из этого "In", решает что это (const Int32 Var).
тип ты этой своей напрямую сказанной идеей как ты будешь пользоваться переменной - "In", даешь компилятору возможность выбрать именно тот тип передачи который будет нужен.

Мне звучит как огромный спектр оптимизаций возможен, ибо эффективно говоря, они именно этим движением убрают конст_каст, если у компилятора есть ГАРАНТИЯ что оно не поменяется, там же чудеса можно творить.
Там есть куча деталей и наверное все продумано для всех типов, но я не шарю.
А для себя лично, я бы писал лучше код с In/Out/Move - вместо текущих референсов и не игрался с названием (TraceResult& OutTrace) а (Out TraceResult Trace) показывал что это результат вот так выводит функция, вроде то же самое но на уровне языка а не договоренности в названии.
Особенно мув, так как он на этапе компиляции гарантирует что то по окончанию функции "из переменной будет вызван мув", значит кастомный дестрактор вызывать не нужно.
Тип юник птр проверять не надо, кинул внутрь и все, если мув в коде не вызывается нигде не скомпилируется иди нахер.
Как это реализовано и не додумываю я хз ибо там 40 страниц и я только глазами просмотрел.

Grohuf написал 51 минуту назад:

Кстати, раз зашла про стандарт плюсов, то не кажется ли вам, что вся хуйня вокруг итераторов - нереально юзелесс поебота? То есть вся эта абстракция - полная хуйня. Ее в каких-нибудь современных языках копируют?

То есть вот у меня есть алгоритм сортировки. В 99.99% случаев я буду сортировать вектор. Или же делать кучу из вектора.

Алгоритмы типа std::any_of или transform - жутко кринжовая хуйня, которая непонятно зачем существует. В результате наворотили говна, которое приходится расхлебывать и все непонятно ради чего.

И как так вообще получилось, что из вполне адекватного языка Си получилась такая поебень как си++?

 

они уже давно признались что обосрались с итераторами.
Мне они нравятся иногда, я когда то парсер писал и передавать итератор в функцию было очень удобно, так что один юзкейс я видел.

Grohuf написал 49 минут назад:

Кстати, раз зашла про стандарт плюсов, то не кажется ли вам, что вся хуйня вокруг итераторов - нереально юзелесс поебота? То есть вся эта абстракция - полная хуйня. Ее в каких-нибудь современных языках копируют?

 

Не кажется.

В современных языках, типа питона, все просто нахуй копируют. И итератор там невозможен без какихнибудь ебанутых оберток, что иногда дико мешает.

Беглый гугл показал что в шарпе Enumerator есть.

Я в целом чето не сильно понял, в чем плохи итераторы? 

Буков дохуя, рли.
Я даже по памяти не смогу итератор наверное написать для std класов без auto, там же пиздец декларация класса.

CriErr написал 5 минут назад:

Весь этот функционал это замена текущим комбинациям функционала под одним именем.

Ты имеешь в виду вырезать все старое нахуй? Запретить писать const, && и прочее? Или что?

CriErr написал 5 минут назад:

Тип юник птр проверять не надо, кинул внутрь и все, если мув в коде не вызывается нигде не скомпилируется иди нахер.

А потом появится "optional in"? Ну, не всегда ведь читать нужно? Вдруг у тебя только за одним ифом чтение.

CriErr написал 7 минут назад:

а компилятор смотрит что такое Инт32, и изза того что его в функцию передаешь чтобы она могла читать из этого "In", решает что это (const Int32 Var).

Ну, для этого, уже есть const, он ничем не отличается. И все эти оптимизации компилятор может сделать и сейчас, и делает, ведь он анализируя твой код видит пишешь ты в этот референс, али нет. 

CriErr написал 2 минуты назад:

Буков дохуя, рли.
Я даже по памяти не смогу итератор наверное написать для std класов без auto, там же пиздец декларация класса.

 

decltype(map)::iterator it{}; 

CriErr написал 11 минут назад:

дестрактор

GoldRobot написал 1 минуту назад:

Ну, для этого, уже есть const, он ничем не отличается. И все эти оптимизации компилятор может сделать и сейчас, и делает, ведь он анализируя твой код видит пишешь ты в этот референс, али нет. 

не дальновидный он ведь, особенно если стак будет глубокий и куча функций одна в другой.

Вот стринг например передавать это же рак пиздец.
foo(In std::string Var) для компилятора будет означать что ты передаешь эту строку, из нее будут ТОЛЬКО ЧИТАТЬ и никогда не поменяют, ничего и ни как
значит ему не надо ничего делать вообще, ни копи констракторов вызывать, ни в стринг вью превращать, просто тот же адрес какой был у оригинальной передать дальше в функцию и все.
А щас твои конст рефренсы ниче не значат, ибо конст каст есть и если компилятор не видит достаточно глубоко и доказать не может что ничего менять не будут, то поинтер ему создать придется, а это рак.

Ну тоесть я что хочу сказать, текущий подход работает, и работает отлично, за исключением некоторой вербозности.

И в теории можно было бы заменить, "но есть нюанс". У тебя есть функции/конструкторы, у которых логика и поведение в целом меняется в зависимости от того, что им передали. rvalue или lvalue, перегрузка всмысле. В языке есть прям хелперы, которые могут тебе сказать какого типа этот референс.

Тоесть придется делать уже In, InMove, и соответственно перегрузку по ним. А ведь я так понял основной перк в том, что бы оно все "автоматом".

Так же я вижу еще одно неудобство. Вот сейчас тебе этот параметр нужен, спору нет, все круто. А через два года разработки тебе пришлось рефакторнуть, и пришли к тому что этот параметр НЕ нужен больше на чтение. И выкидывать как бы очень сильно не хочется, сломается совместимость старого кода. Рефакторнуть сразу везде ты не можешь. И вот, тебе уже нужен InDeprecated 

Вообще, может в пропозале все круто и это описано, нужно бы почитать. Но лень.

GoldRobot написал 13 минут назад:

Я в целом чето не сильно понял, в чем плохи итераторы? 

В большинстве случаев неудобны в использовании. Синтаксис использования многословен. Попытка пропихнуть везде итераторы привели к тормозному std::unordered_map (в котором для реализации итераторов пришлось использовать списки). Код с итераторами в большинстве случаев плохо читабелен. Ну и вообще выглядят как говно.

CriErr написал 1 минуту назад:

А щас твои конст рефренсы ниче не значат, ибо конст каст есть и если компилятор не видит достаточно глубоко и доказать не может что ничего менять не будут, то поинтер ему создать придется, а это рак.

Так они не для евридей юза сделаны, а по делу для хаков. Ниразу в жизни не приходилось использовать, только mutable поля.

С этим пропозалом аналог const_cast нужен будет, я гарантирую это. Не ебу зачем, но нужен будет 

Ну и Референс==Поинтер, в целом. Внутри, насколько знаю, это буквально одно и тоже. С точки зрения абстрактной машины с++ да, разное, но в реальности увы.

CriErr написал 4 минуты назад:

Вот стринг например передавать это же рак пиздец.

я ожидаю в будующем (std::string auto &&str). И там дальше уже в зависимости от вызывающего кода, это либо реф у тебя, либо валуе, либо можешь мувать от туда через форвард.

Не нужно рассматривать только с точки зрения вызываемого кода, иногда оптимальный вариант зависит от вызывающего. При применении одной и тойже функции, иногда в нее можно смувить, а иногда - нельзя.

send(std::move(str)) - можно смувить

return 0;

send(std::move(str), cb = [str](){log << "sent str:" << str;}) - уже нельзя.

return 0;