Спасибо, очень интересно!
Я делаю похожий проект на WinPhone(и DirectX, соответственно).
У меня есть пара вопросов, буду очень рад, если ответите:
1) Если я правильно понял, то вы данные, полученные из OSM, триангулируете и генерируете тайлы через OpenGL. А как вы делаете обводку полигонов? Это специальный шейдер, дополнительные полигоны, или 2d рисование поверх полигонов?
2) А как рисуете одномерные объекты(на картинке линия — . — . -)?
3) Триангуляция делается(если делается) на самом телефоне, или заранее?
4) Вы используете свой код для триангуляции, или какую-то библиотеку(я использую clipper для пред-обработки и poly2tri для триангуляции)
5) В рамках одной карты, храните-ли данные сгруппированными по местоположению(то же квадродерево, например)?
6) Если да, то как организован offline поиск по карте? Используете ли вы какой-то отдельный строковый индекс, порядок обхода(если данные сгруппированы) или просто проходите по всем строкам?
На сколько я понимаю, в данный момент авторы преподносят Rust более безопасной альтернативой C и C++, в том числе для встраиваемых решений.
Они совсем в разных нишах с Go. На Rust сложнее писать(в основном из-за лайфтаймов и отсутствия сборки мусора), но он ближе к железу.
Rust не более высокоуровневый, чем С++ или С. И более низкоуровневый, чем Go.
Метит он скорее на безопасную многопоточность и асинхронность, чем на лёгкую. Arc<RWLock<i32>>(вот, кстати, и дженерики) просто для того, чтобы безопасно сделать целое число, которое можно читать/редактировать из разных потоков — не сказать, чтобы легко…
У Rust нет GC, нет «лёгких потоков»(вроде goroutine), нет динамической типизации.
Ожидаемая дата релиза версии 1.0: 15 мая
Не нашел никаких упоминаний макроса ifError в Rust. Вероятно его убрали.
Отличия обработки ошибок в Go и Rust состоят в основном в том, что в Rust есть Pattern matching + стандартная функция unwarp.
Для примера возьмем функцию, которая может вернуть ошибку(в виде кортежа в случае с Go, в виде типа Option в случае Rust): конвертация строки в число.
Go:
Игнорируем ошибку:
n, _ := strconv.Atoi("123")
Падение при некорректной строке
n, err := strconv.Atoi("123")
if err != nil {
panic(err)
}
Обработка ошибки:
n, err := strconv.Atoi("123")
if err != nil {
...
}
Rust:
Падение при некорректной строке:
let n = from_str::<u64>("123".as_slice()).unwrap();
Как в Rust совсем проигнорировать ошибку и иметь при этом возможность обратиться к переменной 'n' я не придумал.
Rust заставляет либо проверять ошибку, либо ронять поток выполнения в случае ошибки(Option.unwrap(error) делает panic!(error) в случае, если значение — None)
Go позволяет случайно(или из-за плохого стиля кодирования) пропустить обработку реальной ошибки(первый вариант) и продолжить исполнение программы на некорректных данных.
В новой(2013) Visual Studio MS утверждали, что сильно улучшили диагностику графики. И те возможности RenderDoc, которые вы описали в этой статье, там появились. Сам не пробовал, но судя по презентации — в том числе отладка сторонних приложений. Впрочем, на счет дочерних процессов и корректной обработки ланчеров ничего не знаю, как и на счет реального удобства отладки сторонних приложений.
Забавно. Я не слежу за ситуацией с публичным релизом 8.1, но у меня на 8S стоит(и нормально работает) dev-версия 8.1. Видимо что-то специфичное именно для HTC не влезло.
Я очень мало знаю о этой теме, но не раз слышал, что в подобных ситуациях использовать select в windows — не самая лучшая идея. Вот, напрмер, тут написано почему.
Я не предлагаю так сделать в Java. Я попытался пояснить, что, вероятно, имелось в виду под «честными дженериками» в данном случае.
Но тем не менее? я хочу заметить, что и в Java и C# дженерики появились уже после релиза языка. Так что проблемы совметимости были не только у авторов Java.
Про честные дженерики(если я правильно понял автора и не забыл джаву), имеется в виду, что в джаве нельзя написать:
ArrayList<int>
Можно только:
ArrayList<Integer>
Что может привести к лишнему боксингу/анбоксингу:
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(42); // Тут произойдет автоматический боксинг
int number = list.get(0); // а тут анбоксинг
В С# можно написать:
List<int> list = new List<int>();
list.Add(42); // никакого боксинга
int number = list[0]; // никакого анбоксинга
Я делаю похожий проект на WinPhone(и DirectX, соответственно).
У меня есть пара вопросов, буду очень рад, если ответите:
1) Если я правильно понял, то вы данные, полученные из OSM, триангулируете и генерируете тайлы через OpenGL. А как вы делаете обводку полигонов? Это специальный шейдер, дополнительные полигоны, или 2d рисование поверх полигонов?
2) А как рисуете одномерные объекты(на картинке линия — . — . -)?
3) Триангуляция делается(если делается) на самом телефоне, или заранее?
4) Вы используете свой код для триангуляции, или какую-то библиотеку(я использую clipper для пред-обработки и poly2tri для триангуляции)
5) В рамках одной карты, храните-ли данные сгруппированными по местоположению(то же квадродерево, например)?
6) Если да, то как организован offline поиск по карте? Используете ли вы какой-то отдельный строковый индекс, порядок обхода(если данные сгруппированы) или просто проходите по всем строкам?
Они совсем в разных нишах с Go. На Rust сложнее писать(в основном из-за лайфтаймов и отсутствия сборки мусора), но он ближе к железу.
Эта библиотека не работает, и без поддержки компилятора работать, по утверждениям разработчиков Кust, не будет, а таковая поддержка не планируется.
Метит он скорее на безопасную многопоточность и асинхронность, чем на лёгкую.
Arc<RWLock<i32>>
(вот, кстати, и дженерики) просто для того, чтобы безопасно сделать целое число, которое можно читать/редактировать из разных потоков — не сказать, чтобы легко…У Rust нет GC, нет «лёгких потоков»(вроде goroutine), нет динамической типизации.
Ожидаемая дата релиза версии 1.0: 15 мая
В финляндии, вероятно, отказываются от изучения курсива/скорописи.
Отличия обработки ошибок в Go и Rust состоят в основном в том, что в Rust есть Pattern matching + стандартная функция unwarp.
Для примера возьмем функцию, которая может вернуть ошибку(в виде кортежа в случае с Go, в виде типа Option в случае Rust): конвертация строки в число.
Go:
Игнорируем ошибку:
Падение при некорректной строке
Обработка ошибки:
Rust:
Падение при некорректной строке:
Обработка:
Как в Rust совсем проигнорировать ошибку и иметь при этом возможность обратиться к переменной 'n' я не придумал.
Rust заставляет либо проверять ошибку, либо ронять поток выполнения в случае ошибки(Option.unwrap(error) делает panic!(error) в случае, если значение — None)
Go позволяет случайно(или из-за плохого стиля кодирования) пропустить обработку реальной ошибки(первый вариант) и продолжить исполнение программы на некорректных данных.
Но тем не менее? я хочу заметить, что и в Java и C# дженерики появились уже после релиза языка. Так что проблемы совметимости были не только у авторов Java.
Можно только:
Что может привести к лишнему боксингу/анбоксингу:
В С# можно написать: