Вот какие слова в Rust зарезервированы для будущих версий, но пока не используются:
abstract
become
box
do final
macro override
priv
try
typeof
unsized virtual
yield
Т.е. такие есть в планах добавление полноценного ООП. Пока что основная слабость Rust — нет ООП полноценного, как в том же C++ или хотя бы как в Java.
А ведь, как ни крути, ООП — достаточно востребованный инструмент, о чем создатели Rust знают и заранее под это дело оставили слова.
Получается в некоторых веща, как то контроль заимствований — он опережает C++ — и более того, в C++ будет проблематично это добавить. А вот в ООП — не полноценен и это достаточно критично для многих проектов, особенно там где GUI.
Здравствуйте, Shmj, Вы писали:
S>Вот какие слова в Rust зарезервированы для будущих версий, но пока не используются:
обычное дело. Ты ещё Swift не видел наверное. Вышла новая iOS и новый Xcode, версия Swift сменилась, пытаешься скомпилировать проект, который компилировался на предыдущей версии — 940 ошибок. Нормально апгрейдили
(это из старых воспоминаний, когда менялась версия с 3 на 4-ю, кажется, точно уже не вспомню)
Здравствуйте, Shmj, Вы писали:
S>Т.е. такие есть в планах добавление полноценного ООП. Пока что основная слабость Rust — нет ООП полноценного, как в том же C++ или хотя бы как в Java. S>опережает C++
Здравствуйте, CreatorCray, Вы писали:
CC>Взаимоисключающие параграфы detected
Так вы внимательно прочитайте.
В ООП — С++ более развит, значительно более развит.
В управлении памятью — unique_ptr|shared_ptr|weak_ptr — добавили только в 2011, причем контроль компилятор то не осуществляет в полной мере — максимум вам варнинг выдадут, если используете указатель на перемещенное значение. А добавят ли в С++ полноценный контроль компилятором как в Rust — скорее всего уже нет.
Здравствуйте, Shmj, Вы писали:
S>В управлении памятью — unique_ptr|shared_ptr|weak_ptr — добавили только в 2011
В C++98 существовал auto_ptr, предтеча unique_ptr.
shared_ptr/weak_ptr в Boost-овой реализации были доступны с начала 2000х.
Но вообще умные указатели на базе подсчета ссылок (пусть даже не такие продвинутые, как shared_ptr/weak_ptr, без счетчика "слабых" ссылок) были известны и применялись в самодельных реализациях с 1990-х (во второй половине 1990-х так точно).
Просто для информации и понимания: в C++ уже много лет есть то, чего нет в стандартной библиотеки языка C++ (и чего в этой самой библиотеке может вообщени никогда не оказаться).
S>А добавят ли в С++ полноценный контроль компилятором как в Rust — скорее всего уже нет.
Здравствуйте, Shmj, Вы писали:
S>>shared_ptr/weak_ptr в Boost-овой реализации были доступны с начала 2000х.
S>Так не было же r-value -ссылок && и семантики перемещения на уровне языка. Как же оно перемещало?
Оно и не перемещало. Что было критично только для auto_ptr, из-за чего auto_ptr и выбросили, предоставив вместо него unique_ptr.
Для shared_ptr/weak_ptr наличие семантики перемещения -- это всего лишь оптимизация. Полезная, но не критичная.
Здравствуйте, Shmj, Вы писали:
S>Т.е. такие есть в планах добавление полноценного ООП. Пока что основная слабость Rust — нет ООП полноценного, как в том же C++ или хотя бы как в Java.
Не факт В Go нет полноценного ООП, что не мешает быть языку востребованным и высокооплачиваемым.
S>А ведь, как ни крути, ООП — достаточно востребованный инструмент, о чем создатели Rust знают и заранее под это дело оставили слова.
Раст не то чтобы новый язык, он уже почии 10 лет существует, а в современном виде 5. Вполне возможно слова были зарезервированы на старте, а сейчас никто не помышляет об ООП в нем.
S>Получается в некоторых веща, как то контроль заимствований — он опережает C++ — и более того, в C++ будет проблематично это добавить.
Ну какбы это единственное чем раст "опережает", хотя я бы сказал "отличается в положительную сторону" от остальных языков.
S>А вот в ООП — не полноценен и это достаточно критично для многих проектов, особенно там где GUI.
Да не то что не полноценен, его в расте просто нет.
Тут вот в чем дело — человек мыслит объектами — хотите вы или нет. Более того — мыслит иерархическими объектами. Так что язык без ООП просто будет во многих случаях не удобен. Вот В C объектов нет, а ведь все-равно их добавили в реальных проектах, особенно там где GUI.
.
S>Тут вот в чем дело — человек мыслит объектами — хотите вы или нет. Более того — мыслит иерархическими объектами.
Я даже знаю кто эту чушь придумал. Меня интересует есть и реальные исследования о том что "человек мыслит объектами", тем более "иерархическими"?
S>Так что язык без ООП просто будет во многих случаях не удобен. Вот В C объектов нет, а ведь все-равно их добавили в реальных проектах, особенно там где GUI.
Я за 15 лет не встречал ни одной задачи кроме лейатуа GUI, где ООП был бы необходим.
Здравствуйте, gandjustas, Вы писали:
S>>Тут вот в чем дело — человек мыслит объектами — хотите вы или нет. Более того — мыслит иерархическими объектами. G>Я даже знаю кто эту чушь придумал. Меня интересует есть и реальные исследования о том что "человек мыслит объектами", тем более "иерархическими"?
Какие исследования? И так все понятно — вот человек, вот машина, вот ребенок. Вот вся биология с ее иерархией — начиная с 4 царств.
S>>Так что язык без ООП просто будет во многих случаях не удобен. Вот В C объектов нет, а ведь все-равно их добавили в реальных проектах, особенно там где GUI. G>Я за 15 лет не встречал ни одной задачи кроме лейатуа GUI, где ООП был бы необходим.
GUI — очень важная часть ПО, без него не возможно ничего сделать.
Ну и без него — паттерны проектирования на основе ООП то не дураки подметили. Мы к ним приходим в процессе работы, это просто удобно.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Тут вот в чем дело — человек мыслит объектами — хотите вы или нет. Более того — мыслит иерархическими объектами. G>>Я даже знаю кто эту чушь придумал. Меня интересует есть и реальные исследования о том что "человек мыслит объектами", тем более "иерархическими"?
S>Какие исследования?
Научные
S>И так все понятно — вот человек, вот машина, вот ребенок.
Где тут иерархия?
S>Вот вся биология с ее иерархией — начиная с 4 царств.
Классификация и иерархические объекты — две большие разницы. Я даже хотел написать примеры, но думаю всем читателям это очевидно.
S>>>Так что язык без ООП просто будет во многих случаях не удобен. Вот В C объектов нет, а ведь все-равно их добавили в реальных проектах, особенно там где GUI. G>>Я за 15 лет не встречал ни одной задачи кроме лейатуа GUI, где ООП был бы необходим. S>GUI — очень важная часть ПО, без него не возможно ничего сделать.
А кто-то спорит? Я говорю о том, что кроме GUI других полезных применений ООП я не знаю. Есть отдельные задачи, которые ООП может упростить, но в целом и без них можно прожить.
В наше время тотального превосходства веба над всеми другими технологиями языки без GUI тоже вполне жизнеспособны.
S>Ну и без него — паттерны проектирования на основе ООП то не дураки подметили. Мы к ним приходим в процессе работы, это просто удобно.
И что? Без ООП другие паттерны. Да и не все паттерны ООП прям настолько привязаны к ООП.
Здравствуйте, Shmj, Вы писали:
S>В управлении памятью — unique_ptr|shared_ptr|weak_ptr — добавили только в 2011
Что значит добавили? Я в 90х уже аналогом пользовался вовсю.
Как же меня утомили люди, которые не понимают что язык это исключительно то, что требует поддержки компилятором. Всё что можно написать на языке — доступно сразу, оно не требует никакого добавления.
S> причем контроль компилятор то не осуществляет в полной мере
И не должен
S>А добавят ли в С++ полноценный контроль компилятором как в Rust — скорее всего уже нет.
И слава Анубису что не добавят. Оно тут нафиг не нужно, будет только мешать.
Здравствуйте, so5team, Вы писали:
S>Просто для информации и понимания: в C++ уже много лет есть то, чего нет в стандартной библиотеки языка C++ (и чего в этой самой библиотеке может вообщени никогда не оказаться).
This!
Здравствуйте, CreatorCray, Вы писали:
S>>А добавят ли в С++ полноценный контроль компилятором как в Rust — скорее всего уже нет. CC>И слава Анубису что не добавят. Оно тут нафиг не нужно, будет только мешать.
