разве обычное слово может быть торговой маркой ?

Даже цвет может быть, а тут целое слово! ;) Копирасты сильно упарываются…

panic это когда тестируешь код во время разработки очень полезно, чтоб сразу как что-то пошло не так, как ожидается, сразу остановить выполнение и начать там чинить. Если паник вылетает у юзера, значит либо код не дописали, либо тестировали плохо (ну там есть такие подводные камни, что паники могут вылетать из библиотечного кода, если использовать его ошибочно. Очень спорное решение конечно, но что имеем то имеем)

Кодить что именно?

Многое. Микросервисы, десктопный софт (втч игры, редакторы всякие, обработку данных, браузер убийцу фаерфокса в конце концов). Впрочем микросервисы и прочую бизнесс логику можно еще и на хаскеле удобно делать. Короче раст он как молоток. Если что-то имеет смысл забивать, зачастую удобнее забивать именно им.

Почему плюсы устарели? Они же превосходят Rust по функционалу, по скорости... Где видно это самое устаревание?

Стоп а разве обычное слово может быть торговой маркой ? Насколько я понимаю Rust не может торговой это слово.

Типа: https://store.steampowered.com/app/252490/Rust/

А вот к примеру Mozilla Rust - может.

Обычное слово может быть торговой маркой (товарным знаком), но только в случае если оно для обозначаемого товара является скорей фантазийным, чем идентифицирующим. Например, для шариковой ручки нельзя зарегистрировать ТМ со словом «ручка», разве только это слово будет неохраняемым, т.е. как бы частью ТМ, но которую могут использовать и другие.

По Rust могу сказать что. Это слово вроде как с англ. переводится как «ржавчина». Т.е. к ПО и к ЯП не имеет вообще никакого отношения. Соответственно для них это фантазийное слово и его можно регистрировать как ТМ для ПО или ЯП.

Аналогично и с Windows. Очевидно, что «Окна» к ПО не имеют отношения. Сейчас, конечно, ситуация чуть изменилась и фактически под словом «окно» можно понимать как окно в стене, так и окно программы. Но раньше было не так и слово Windows для ПО регистрировать было нормально. Ну и про Windows можно сказать, что теперь эта ТМ является общеизвестной и ассоциация у потребителя с чем-то иным вряд ли будет возникать.

Причём после регистрации узко определённого цвета год за годом подают в суд на других за использование похожих цветов и… проигрывают.

Плюсы плетутся в хвосте по фичам. Если брать C++20, он уже во многом догоняет раст по стандартной либе + move semantics есть, но нормального lifetime чекинга там нет и никогда не будет. Ну и концепты в плюсах не популярны и вообще проигрывают трейтам в элегантности. Единственная фича плюсов, которой в расте не хватает - это возможности использовать значения в дженериках. Ну а эксепшены - это спорный момент. Макросы раста позволяют писать код, не сильно уступающий С++ по выразительности.

Если брать C++20, он уже во многом догоняет раст по стандартной либе

Ну библиотеки это наоборот сильная сторона C++, есть же Boost, зачем %чтототам% иметь именно в std::?

но нормального lifetime чекинга там нет и никогда не будет

Чем плохи -Wlifetimes из clang?

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

Чем плохи -Wlifetimes из clang

Тем, что ни я ни автора 99.9999% кода на С++ о них не слышали. Хороши только те лайфтаймы, без проверки которых не компилится ни одна либа в мире

Компилируется ли опенссл с лайфтаймами раста? Свои проекты собирать с -Wlifetimes ничего не мешает то. Или проблема в том что их можно выключить? Ну это да, надеюсь кто нибудь сделает сборку где все будет вместе удобно собранно, а опции зашиты (если есть что то подобное киньте линк плиз). Иначе придется делать мне...

oroti (o-гниль-i)

Звучит не очень стабильно. Юзернейм выше был прав: нужно в морозилку.

Я правильно ВАС понимаю что если

• Открою фирму по изготовлению пластиковых окон то могу без проблем назвать : Microsoft ?

• Или к примеру выпускать бумажные ежедневники (блокноты) и назвать их ipad ?

P.S. Какие бы не были правилы игры они применимы к обеим сторонам (с) не помню кто уже сказал.

и то и то уже занято. можешь назвать макрофёрм или юдупа

Компилируется ли опенссл с лайфтаймами раста?

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

Проблемы у CPP не только с лайфтаймами и их уже не исправить никакими костылями.

десктопный софт

для этого уже есть GTK, Qt, свифты, котлины и т.п.

браузер убийцу фаерфокса в конце концов

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

Впрочем микросервисы и прочую бизнесс логику можно еще и на хаскеле удобно делать

а, ясно, ты что-то курил. Извиняюсь!

Скоро десктопного софта не останется.

moderator, убери этого тся/ться придурка отсюда

А кем занято ?

Где видно это самое устаревание?

В размере спеки. Добавлять функции == распухшим языком сложно ворочать. Удалять == получится другой язык. А с 79го года человечество узнало про программы кое-что новое, появились новые желания и возможжности. Т.ч. на свалку, можно с почётом.

Открою фирму по изготовлению пластиковых окон то могу без проблем назвать : Microsoft ?

Вообще без проблем. Если, конечно, такая торговая марка уже не зарегистрирована.

pederust

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

Вообще без проблем. Если, конечно, такая торговая марка уже не зарегистрирована.

А понятно. Раньше не было компов и никто не регал обычные слова. Потом появились компы, ввели кучу новых слов, а старые (что раньше никто не регал) зарегали на себя под видом что это к компу не относится … и никому в голову не придет зарегать фирму делающие лопаты дать название лопате - компьютер и зарегать это.

Ну что-ж хитро.

ну microsoft corp & apple corp. то, что они не делают пластиковые окна для торговой марки не имеет значение. они могут начать, если захотят

Для России будет лучше Corruption.

Поэтому нужно написать херню без спеки которая несовместима сама с собой

Именно! Она будет лучше соответствовать сегодняшним и завтрашним потребностям, чем та, которая лучше соответствовала позавчерашним но вынуждена тянуть груз совместимсти.

которую никогда не постигнут те же проблемы

Ты сказал.

Конечно настигнут! Он точно так же станет распухшим старьём лет через 30. Но дюжину-другую лет им будет пользоваться приятно – относительно того, чем перестало быть приятно пользоваться столько же лет тому. А там большая часть нас сегодняшних уже вымрет или станет манагерами.

В какой это вселенной они превосходят?

Плюсы - это очень плохой язык с точки зрения скорости. Об этом говорили ещё тогда, когда о расте, возможно, никто и не задумывался. Лет 15 назад выходили статьи с простейшим кодом, типа операций над парой массивов, и в нём показывалось, что сраный фортран, несмотря на всю свою архаичность, будет в таких программах быстрее крестов просто потому, что его компилятор знает об отсутствии алиасинга и потому может спокойно всё развекторизовать.

Плюсы - это очень плохой язык с точки зрения функционала. Варианты, мув семантика - всё сделано через задницу.

И, самое главное, скорость и функционал вторичны. Вон, компиляторы плюсов, ценой неочевидного UB могут генерировать быстрый код, да даже из джаваскрипта как-то производительность вытягивают. Главное в ЯП - выразительность, способность сообщить важную информацию. В этом плане плюсы даже уступают обычному С, в нём по крайней мере type* описывает чуток поменьше разных, не связанных между собой, концепций.

GTK

можно на расте

Qt

не нравится мне их ООП подход, ну в принципе узабельно

свифты

покажи гуй на свифте в линуксе. Хоть один.

котлины

JVM для гуя очень редко используется, поскольку то что там было изначально (до свинга включительно) не очень, а то, что придумали потом (JavaFX) опоздало и поезд популярности уже ушел. Короче котлин теперь на 90% для мобилок, остальное - индивидуальная инициатива кодера. Ну и опять же, для раста в первую очередь актуален софт, в котором не желательно ждать GC. Простые десктопные проги можно хоть на питоне, хоть на электроне писать, потребитель стерпит. Да и незачем там заморачиватся лайфтаймами, если GC всё и сам отлично разрулит

вообще выше написана херня. правило «не-общеупотребимого слова» это для СНГешных торговых марок. на западе ты можешь любое словосочетание (не занятое) зарегистририровать. например MAN, хотя это ж просто слово, самое общеупотребимое. Mercedes - это просто женское имя, и тд

Даже цвет может быть торговой маркой.

подают в суд на других за использование похожих цветов и… проигрывают.

Хоть это, пока, радует :) Но мозг-то людям выносят…

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

Экраны сообщений о ошибке компиляции из-за невероятно навороченной архитектуры

Ты то ли не пробовал, то ли взял какую-нибудь наркоманию типа MPL/Phoenix. Практичные библиотеки типа Asio/Interprocess трудно использовать настолько неправильно.

Да и ad-hoc концепты там много где стоят. Будет C++20 - будет больше, о чем сейчас говорить.

Общеупотребимое слово для одной категории товаров может быть торговой маркой для другой категории. Скажем, «Конфета» не может быть тм для сладостей, но может быть для презервативов.
Тут то же самое.

Открою фирму по изготовлению пластиковых окон то могу без проблем назвать : Microsoft ?

Если старый МС уже не владеет такой фирмой, то да. Был лет 15-20 назад похожий случай с нижним бельём из мягких микроскопических волокон. В Британии,вроде. После судебного процесса признали право называть бельё Microsoft.

Нет, всё что я понаписал относится именно к цпп, и оно же определяет его недостатки.

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

Если кто-то перепишет все заголовочные файлы всех либ для cpp то да, будет как в расте, но только зачем страдать, если можно использовать нормальный язык?

Лайфтаймы служат определенной цели, прописывание руками это недостаточная умность компилятора rust'a, а во Wlifetimes все что можно автоматизированно. Ты смотрел вообще на них? Просто интересно.

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

Кстати, ты серьезно про то, что царь должен быть в голове, а не оставаться на ЛОРе?

Не смотрел. Однако если это действительно так, то место этим лайфтаймам на помойке. Лайфтаймы - это контракт между программистами, ни одна шайтан-машина никогда не сможет понять, что я обещаю пользователям свой библиотеки. Сегодня я устанавливаю это поле в указатель на объект в статической памяти, а дальше я буду выделять память или брать из параметров. Если я не напишу, компилятор не узнает.

В расте тоже часто можно лайфтаймы не писать, когда они тривиальны, см lifetime elision. Нормальные лайфтаймы для цпп тоже есть, через внешний тул от майкрософта и библиотеку gsl, там они, когда необходимо, прописываются руками через довольно уродливый синтаксис, ещё страшнее чем в расте.

Как я напишу свою реализацию мува, если cpp мув не поддерживает и именно поэтому в библиотеках его и реализуют через жопу (рвалуе ссылки и обмен содержимым)?

Если я не напишу, компилятор не узнает.

Компилятор если что имеет доступ к коду, так что узнает.

Как должен выглядеть нормальный мув?

К тому коду, который ещё не написан?

Ещё раз: лайфтаймы являются частью контракта. Автор библиотеки может менять реализацию, не меняя контракта и это типа стабильно. Если сегодня компилятор что-то догадался, на основании этой догадки кто-то другой написал кучу кода, а потом либа обновилась и догадка оказалась неверной, то кто виноват? Правильно, идиот, который решил не включать лайфтаймы в язык

Как я напишу свою реализацию мува, если cpp мув не поддерживает и именно поэтому в библиотеках его и реализуют через жопу (рвалуе ссылки и обмен содержимым)?

это сильное заявление многое говорит об его авторе

Ну, хотя бы понимать, что того что мувнули уже нет.

В ЦПП с мувами всё вообще плохо, например, если я в своей функции получил рвалуе ссылку в качестве параметра и передал её другой функции, то я ничего не мувнул, имя у переменной есть - следовательно само не мувается, нужно или std::move или std::forward писать. Если я явно мувнул что-то в функцию, потом забыл и ниже снова использовал… То это нормальная ситуация, будет у меня или нулевой указатель или пустой контейнер.

К тому коду, который ещё не написан?

А как ты собрался компилировать код который еще не написан?

Автор библиотеки может менять реализацию, не меняя контракта и это типа стабильно.

Там не тупая система, от изменения реализации ничего снаружи не поменяется.

И что компилятор должен делать при втором и последующих мувах объекта? Сразу же рассмотри случай, когда мув под условием

Там не тупая система, от изменения реализации ничего снаружи не поменяется.

Ну вот пишу я функцию, которая принимает стрингвью и возвращает стрингвью. Предположим, пока возвращает всегда «not implemented», но в перспективе будет брать кусок из параметра. И как твоя «умная» система обработает эту ситуацию, чтоб не позволять тебе менять строку пока ты держишь возвращенный из функции стрингвью? Ответ: точно так же тупо как и в расте: лайфтайм возвращаемого значения принимается тем же что у принимаемого, если явно не указано обратное. Разница только в том, что авторы раста рекламируют явные лайфтаймы, чтоб показать что Раст умеет, а авторы приблуды для цпп прячут явные лайфтаймы где-то ближе к концу, чтоб не видно было как убого они выглядят.

Предупредить, нет? Ещё раз, мув он на то и мув, что он перемещает объект. Не превращает его в тыкву, а перемещает. Компилятор должен убедиться, что объект перемещён 1 раз или менее и если не перемещён, то вызвать деструктор. То, что в плюсах сделано вместо перемещения что-то другое - это не повод считать это другое эталоном.