All streams
Search
Write a publication
Pull to refresh
71
0
Dzmitry Malyshau @kvark

User

Send message
Ваше возмущение понятно. Строки и оператор индексирования — это одни из тех вещей, над которыми идёт работа сейчас, так что этот пример может измениться ближе к выпуску версии 1.0.

> Зачем там .to_string()?
Потому что голая строковая константа имеет тип &str, а ассоциативному массиву нужен String. Фактически to_string() выделяет память в куче и копирует туда строку. Не всегда нужно иметь строку в куче, поэтому по умолчанию Rust не делает ничего лишнего.

> Почему insert(), а не []?
Работа над этим ведётся.

> И вообще, квадратные скобки скорее соответствуют replace. Что будет, если там уже есть ключ add?
insert() замещает существующий элемент. Интерфейс MutableMap.

> я правильно понимаю, что вот на этой строчке x = HashMap::new() память первого массива полностью освобождается? А в конце main освобождается и второй?
Правильно.

> А теперь хитрее:…
В Rust никто за Вашей спиной не будет подсчитывать ссылки. Если Ваша программа копирует большие объекты, то можете использовать подсчёт ссылок для них, обернув в Rc:
use std::rc::Rc;

fn foo(_x: Rc<String>) {}
fn main() {
    let x = Rc::new("my long string".to_string());
    foo(x.clone());
}
С этим как-раз таки проблем быть не должно. Пример без использования сборщика мусора:
use std::collections::hashmap::HashMap;
type MyMap = HashMap<String,int>;

fn a(mut map: MyMap) -> MyMap {
    map.insert("add".to_string(), 1);
    map
}

fn main() {
    let mut x: MyMap = HashMap::new();
    x.insert("o".to_string(), 2);
    println!("{}", a(x));
    x = HashMap::new();
    x.insert("c".to_string(), 4);
    println!("{}", a(x));
}
Вот что сказал один из спецов по поводу использования float как ключей в D:
10:02 SiegeLord: So I checked, D associative arrays in the current release treat NaN's as equal, and in the master they treat them as unequal (i.e. they do the bad thing)
10:02 SiegeLord: The bad thing being, I think you can insert key NaNs, but not get them back
10:03 SiegeLord: So… essentially… that code example is nothing to be proud of
10:04 kvark: SiegeLord: so it works in 99.9% of cases, where we don't have a NaN key, and the rest of the cases are simply unable to get the key back? That sounds like a win to me
10:04 SiegeLord: It's a DoS vector
10:04 pczarn: why?
10:05 SiegeLord: You make insertion operation be O(n)
10:05 SiegeLord: Keep inserting NaN, and it keeps making the bucket longer and longer
10:05 SiegeLord: And it has to check them all by equality before determining that its a 'new' key

По его словам, решение в D не самое удачное, хотя я согласен, что это может быть удобно. Он утверждает, что бесконечно пихая некорректные числа в этот ассоциативный массив, каждая следующая операция будет линейно медленнее, что может стать орудием для атаки. Есть и такое мнение:
10:09 pyon Why would anyone want to compare floats for equality? This is a data type invented for scientific computations with inexact numbers. :-|

С этим трудно не согласиться. Может быть, поддержка float в таком контексте — излишество, которое может стать и проблемой безопасности (упомянутый DoS vector)?
Я было попробовал то же самое сдалать на Rust, но тут же упёрся в тот факт, что числа с плавающей точкой не могут быть ключами деревьев (как TreeMap, так и HashMap). Длинная дискуссия тут, но основной смысл — что NaN не вписывается. В Rust пока консенсус таков, чтобы сделать обёркти для f32 и f64, которые реализуют способности Ord и Hash, так что могут быть и ключами.

Интересно, а как с этим (NaN) обходится D? В целом, судя по примеру, он сейчас намного более дружелюбен PHP разработчикам…
Забавно, что Вы спрашиваете об этом здесь, под постом о D :)
Есть неплохой материал на это тему в Rust For Rubyists, однако я не вижу там ассоцииативных массивов… Про них неплохо написано в официальной документации HashMap. Что же касается полноценной статьи «Rust для программиста на PHP», то тут я, извините, пасс.
Реализации этих программ лежат в репозитории Rust и постоянно обновляются и тестируются (вот, к примеру, n-body). Я помню видел их своими глазами на BenchmarksGame, но сейчас там какие-то проблемы с лицензией выясняются, и их временно убрали с сайта. Языка D на этом сайте вообще почему-то нет. Если не боитесь установить (а лучше собрать) Rust, то всё в Ваших руках ;)
Однако C++/CLI — это уже совсем другая история. На нём каши не сваришь ОС не напишешь…

А по поводу STL + unit tests, как уже говорилось, некоторые серьёзные проекты не используют их (игры!), так что дело не в квалификации. Да и самострелы не уходят «теоретически» — смотрите пример с итератором.
Спасибо, это было великолепно!
Пора объявлять неделю языков программирования на Хабре. Небойсь, и Swift объявится ;)
Спасибо, это ценное дополнение. Однако всё, что связано с аргументами шаблона, проверяется только на второй фазе (при инстацировании), так что смысл сравнения остаётся прежним.
Примеры действительно банальны, и я это не скрываю. Зато их можно целиком взять и отдать Вашему компилятору, в том числе и online. Если Вы хотите погрузиться глубже в матрицу, посмотрите или почитайте выступление Niko Matsakis.

> Конечно же от случайностей никто не застрахован, но cppcheck и valgrind всегда в помощь.
Valgrind не доступен на Windows, а cppcheck не ловит все ошибки. В целом и то и другое я, несомненно, считаю необходимым для любого С++ проекта.

Clang действительно даёт более красивые сообщения об ошибках, лучше предупреждает об угрозах, и достоен внимания. В конце концов, Clang, как и Rust (как и Swift), работает на LLVM.
Кажется, мои статьи дёргают за живое, заставляют некоторых людей выйти из своей пещеры. Пещеры иллюзии того, что нужно выбирать между надёжностью и производительностью, и что С++ занимает локальный оптимум в плане второго. Rust нарушает эти неписаные правила, и чтобы осознать это, нужно согласиться принять красную таблетку, а не синюю.
Я бы не отказался почитать на Хабре полноценный обзор D. Где язык находится сейчас, есть ли список живых проектов, как на D сказывается влияние Андрея Александреску, и насколько эффективно его применяют в Facebook (и зачем)?
Правда в том, что «проблемы как с программистами так и с менеджментом» есть везде. Проекты на С++, над которыми я работал (и работаю) профессионально, просто кишат велосипедами(свои умные указатели и контейнеры), голыми указателями, они не покрыты тестами и не проверяются статическими анализаторами. STL стараются избегать за милю, хотя это уже отдельная история… Эти проекты огромны (~35Mb собранный в release исполняемый файл), над ними работает туча людей, и ошибки появляются и исправляются постоянно.

Я знаю, что можно писать грамотно, использовать стандартные умные указатели и контейнеры (и в том же духе), но реальность такова, что свобода выбора этих инструментов и лёгкий доступ к самострелам играют злую шутку над разработчиками. Даже в Вашей неподтверждённой статистике 10% оставшихся ошибок могут занять больше времени и денег на исправление, чем написание и первичная отладка самого кода, содержащего их.

>Плохому программисту не язык мешает.
При правильном выборе инструмента (языка), плохих программистов становится заметно меньше.
Простите, заявляют забавляют
This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember, all I'm offering is the truth – nothing more.

Реальный мир для Rust наступает с каждым днём. Пока не видно и намёка на то, что реализованная модель безопасности работает плохо. Выясняются детали, полируются интерфесы, добавляются возможности, а в целом — по Ленину:
Верной дорогой идете, товарищи!
Если я не ошибаюсь, модули Бъярн тоже хочет вылечить новым стандартом. Он об этом говорил на Lang-NEXT.
Я честно говоря ожидал другую статью, например о возможностях Rust'a которые сильно бы облегчали разработку по сравнению с С++

Главная возможность — защита от самопрострела ноги, и о ней я более-менее рассказал тут на примерах. Поверьте, оно сильно облегчает разработку ;)
их допускают либо новички которые только только перешли на С++, либо криворукие которым не дано.

Меня всегда заявляют такие высказывания. Как будто бы эти люди, которые криворукие, они где-то там, в другом мире, а мы работаем только с высшим сословием. Константин, приходилось ли Вам работать с большим С++ проектом? Мне — да, и я с горечью спешу Вас огорчить, что ошибки такого рода (простые, аналогично примерам из статьи) повсеместны. Они приносят уйму головной боли, проедают наше время и деньги на исправление.
Вот от такого «обычного» race condition и спасает нас компилятор Rust. Повторюсь, смысл не в том, что на С++/asm нельзя написать хорошо, а в том, что на Rust вы обязаны написать хорошо, а иначе оно не соберётся. Многопоточность — лишь частный случай, но без неё картина была бы неполной.
Не хочу возобновлять священные войны, но Go не подходит для системного программирования, так что это не конкурент C++ и Rust. Этой темы мы уже касались в комментариях моей прошлой статьи.
Вас смутили области видимости. Если есть едеи, как описать их более человечно — делитесь ;)

Information

Rating
Does not participate
Location
Toronto, Ontario, Канада
Date of birth
Registered
Activity