LINUX.ORG.RU

atmel / microchip

Я ещё сейчас на STC начал смотреть. Для них есть нормальный инструментарий?

CYB3R ★★★★★ ()

Интересует поддержка atmel / microchip дешевых, не ARM.

Наслушался сказок про то что Rust - замена Си ?

anonymous ()
Ответ на: комментарий от loyd

Сам пробовал? Какие минимальные требования по памяти?

Vit ★★★★★ ()
Ответ на: комментарий от CYB3R

Оно на 8051-м ядре? Ну вот зачем насиловать труп, скажите? Есть уже вполне адекватные как по цене, так и по периферии/энергопотреблению ARM-ы, под которые существует нормальный инструментарий.

one_more_hokum ★★★ ()
Ответ на: комментарий от loyd

И всё-таки замена крестов, а не си.

Где там тогда нормальный ООП или хотя бы наследование структур?

foror ★★ ()
Ответ на: комментарий от one_more_hokum

потому что он мамкин олдфаг, ему не для дела а для поиграться, такой персонаж

anonymous ()
Ответ на: комментарий от anonymous

Дешёвые чипы и кресты, ога (:

А что дона смущает? Если знать, что делаешь, то разницы с С практически никакой.

anonymous ()
Ответ на: комментарий от Vit

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

А откуда потребность в ржавчине аж на avr?

loyd ()
Ответ на: комментарий от foror

Там не нужен классовое ООП (то, что Вы называете «нормальный»), ибо там тайпклассы — инструмент в разы, если не на порядок мощнее классики.

хотя бы наследование структур

Нет и вводить не собираются. Это нужно разве что при написании обёрток к классике, ибо при АлгТД+тайпклассах код пишется иначе. Если Вы не знакомы с парадигмой, то объяснить с лёту я не смогу — просто начните писать что-то на rust'е (или haskell'е) и Вы удивитесь никчёмности классового (да и прототипного) ООП.

loyd ()
Ответ на: комментарий от loyd

А откуда потребность в ржавчине аж на avr?

Да потому что всех (кроме отъявленных мазохистов) запарило писать код на C, в котором нормального тайпчекера нет и приходится использовать void* на каждый чих. С другой стороны, непонятно почему нельзя писать под AVR на том же хацкелле.

hateyoufeel ★★★★ ()
Ответ на: комментарий от hateyoufeel

запарило писать код на C

Что это за масштабные проекты такие на avr?

С другой стороны, непонятно почему нельзя писать под AVR на том же хацкелле.

GC жеж.

loyd ()
Ответ на: комментарий от loyd

Что это за масштабные проекты такие на avr?

Дело не в масштабности, а в корректности. К хацкеллу приделать и использовать с ним SMT solver несколько проще (e.g. Liquid Haskell) чем в случае с C (Frama-C).

GC жеж.

eDSL жеж.

hateyoufeel ★★★★ ()
Ответ на: комментарий от hateyoufeel

Дело не в масштабности, а в корректности.

Одно дело программка на 1к строк и совсем другое на 10к, согласись. Вряд ли ты будешь прикручивать в первом случае Frama-C. И да, есть полумёртвые Cyclone и D, если совсем припекает.

eDSL жеж

Не понял, как это к GC относится?

loyd ()
Ответ на: комментарий от loyd

Не понял, как это к GC относится?

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

Oxdeadbeef ★★★ ()
Ответ на: комментарий от loyd

Одно дело программка на 1к строк и совсем другое на 10к, согласись. Вряд ли ты будешь прикручивать в первом случае Frama-C.

Если это программка, управляющая впрыском топлива с реактивном двигателе, то буду. Иначе меня повесят.

hateyoufeel ★★★★ ()
Ответ на: комментарий от loyd

... наследование структур ... Нет и вводить не собираются. ...

Вроде ж думают об анонимных полях или подобном, без полиморфизма, на манер Go.

А то лично я не знаю, как красиво избавиться в некоторых ситуациях от подобного:

pub fn is_tile_visible(&self, pos: &MapPos) -> bool {
    self.fow.is_tile_visible(pos)
}

pub fn is_tile_occupied(&self, pos: &MapPos) -> bool {
    self.state.is_tile_occupied(pos)
}
ozkriff ()
Ответ на: комментарий от ozkriff

Как говнокодер на Goвне заявляю, что эмбеддинг структур мало какие проблемы решает.

postman_ ★☆ ()
Ответ на: комментарий от loyd

Да просто хочется знаний освежить на прикладной задаче.

Vit ★★★★★ ()

хипстоты тред

anonymous ()

rust для atmel / microchip

нет пути
Для этих МК писать на чем-то кроме ассемблера - моветон.

Old_Hamster ★★★ ()
Последнее исправление: Old_Hamster (всего исправлений: 1)
Ответ на: комментарий от ozkriff

Можно имитировать наследование GameState от State через реализацию Deref. А вот от fow.is_tile_visible(pos) даже в ООП языках с множественным наследованием не избавился бы, ибо закон Деметры

loyd ()
Ответ на: комментарий от loyd

Это нужно разве что при написании обёрток к классике

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу. Тогда он идет в задницу и я продолжая работать на универсальном С++. Так рассуждает любой вменяемый программер.

Если это замена С, то вопросов не имею.

Вы удивитесь никчёмности классового (да и прототипного) ООП

Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах. Может какие-то либы есть готовые?

foror ★★ ()
Ответ на: комментарий от foror

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу

А «поддерживать» ты только на Си++ и можешь. Иначе это уже переписывание.

tailgunner ★★★★★ ()
Ответ на: комментарий от loyd

Когда у тебя зайдет речь о большой системе, ты поймёшь преимущество «классики». В твоих трейтах и АлгТД ты запутаешься со временем. trait'ы и отдельная реализация вынуждают разбивать систему на большее число компонент, чем требует логика предметной области. Открытые АлгТД удобны в одних ситуациях и неудобны(от слова совсем) в других.

Все это проверено на относительно большом проекте java + scala. Так же есть опыт работы с F#.

Так вот. По мере развития проекта ты или тонешь в сложности или приходишь к тому, что на «высоком» уровне у тебя таки «классика», а вот под капотом вся эта, условно, «функциональна»

anonymous ()
Ответ на: комментарий от Old_Hamster

Чем тебе Си не угодил? Асм лучше оставить на крайний случай.

anonymous ()
Ответ на: комментарий от anonymous

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

На «высоком» уровне, чем «классика» отличается от «функциональщины»? Интерфейсы или трейты - большой разнцы нет. Или у вас на «высоком» уровне было именно наследование классов?

tailgunner ★★★★★ ()
Ответ на: комментарий от foror

Так замена С++ или хипстерское поделие? Да, мне нужно поддерживать классику, на ржавом я это делать не могу.

Что-то логику не уловил. Ржавчина это замена крестам, о какой «поддерживать» идёт речь? Если Вам надо поддерживать кучу дерьма на крестах, то нефиг сюда ржавого тянуть, вот и всё.

Если это замена С, то вопросов не имею.

Это не замена си, ибо он отлично с ним уживается.

Окей, покажи на примере как развернуть HTML страницу из файла в память на АлгТД+тайпклассах.

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

loyd ()
Ответ на: комментарий от tailgunner

Трейты(скаловские) использовались, да. Часто как раз для миксирования. Я бы не назвал это функциональным подходом.

Классика была в том смысле, что были классические иерархии, с наследованием классов(использовалось все это, конечно, через интерфейсы, но это тоже классика).

case class'ы(АлгТД) на «высоком уровне» использовались только там, где были удобны для выражения понятий предметной области, там, где вероятность появления нового варианта стремилась к нулю. И тут я бы не стал называть это уходом от классики, поскольку в проекте на чистой яве было бы что-то похожее, просто с менее удобным синтаксисом. На том же котлине(правда на практике я его не трогал) это выражалось бы вполне сносно, а в нём ФП и АлгТД нет.

В общем, я таки люблю scala больше java, но само по себе ФП ООП не заменяет, они используются на разных уровнях. Т.е. ФП может убрать ООП там, где оно не нужно и приводит к увеличению, а не уменьшению сложности. Но не везде. Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют. А множественное наследование можно убрать, да, заменив примесями.

anonymous ()
Ответ на: комментарий от anonymous

Потому мне не очень понятно, какой смысл отказываться от ООП в Rust, тем более, что чего-то большего, чем C++, от них и не требуют.

Да никто и не отказывался. АлгТД+тайпклассы на высоком уровне — тот же классовый ООП, только в профиль, как уже заметил tailgunner. А на низком уровне не совсем понятно, почему нужно отказываться от преимуществ таймпклассов? Реализовал нужный трейт для своего типа и он уже отлично вписывается в существующую систему. В итоге меньше адаптеров и т.д., т.е. упрощение, а не усложнение.

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

loyd ()
Ответ на: комментарий от loyd

Немного тему раскрою. Открываю рандомную страницу документации stdlib ржавчины:

impl<T> Ord for Rc<T> where T: Ord + ?Sized
    fn cmp(&self, other: &Rc<T>) -> Ordering

Как это выразить в крестах? Плодить новый класс RcForMyT, наследующий Rc и Ord и реализовывать cmp? Заранее иметь RcOrd<T>?

loyd ()
Ответ на: комментарий от loyd

А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает? В случае шаблонов вполне сработает operator < или свой компаратор(см. стандартные алгоритмы и контейнеры в STL). В случае иерархии, вполне можно сделать метод cmp или ему подобный, если он так уж нужен.

forCe ()
Ответ на: комментарий от loyd

Как это выразить в крестах? Плодить новый класс RcForMyT, наследующий Rc и Ord и реализовывать cmp? Заранее иметь RcOrd<T>?

А в сиплюсе такое и не нужно выражать, там идиоматический код:

template<class T>
bool operator<( Rc<T> a, Rc<T> b );

А еще там есть перегрузка функций.

anonymous ()
Ответ на: комментарий от anonymous

Ага, т.е. если там будет не <, а какой-то конкретный метод, то

там идиоматический код

сведётся к шаблонизированной функции? Отличное ООП получается.

loyd ()
Ответ на: комментарий от loyd

А при чем тут ООП? В ОО-иерархии это будет просто метод(если нужен).

forCe ()
Ответ на: комментарий от loyd

Ага, т.е. если там будет не <, а какой-то конкретный метод, то
сведётся к шаблонизированной функции? Отличное ООП получается.

Шаблон там исключительно из-за того, что Rc сам параметризован по типу. А то, что ты показал на rust - костыль, т.к. rust не умеет в перегруженные функции. Вот попробуй минимальными усилиями изобразить аналог:

void A( T1& t );
void A( int v = 0 );

И поймешь что как и где.

anonymous ()
Ответ на: комментарий от loyd

просто начните писать что-то на rust'е (или haskell'е) и Вы удивитесь никчёмности классового (да и прототипного) ООП.

это интересное заявление, смелое.

trait Animal {
    // Static method signature; `Self` refers to the implementor type
    fn new(name: &'static str) -> Self;
 
    // Instance methods, only signatures
    fn name(&self) -> &'static str;
    fn noise(&self) -> &'static str;
 
    // A trait can provide default method definitions
    fn talk(&self) {
        // These definitions can access other methods declared in the same
        // trait
        println!("{} says {}", self.name(), self.noise());
    }
}
 
struct Dog { name: &'static str }
 
impl Dog {
    fn wag_tail(&self) {
        println!("{} wags tail", self.name);
    }
}
 
// Implement the `Animal` trait for `Dog`
impl Animal for Dog {
    // Replace `Self` with the implementor type: `Dog`
    fn new(name: &'static str) -> Dog {
        Dog { name: name }
    }
 
    fn name(&self) -> &'static str {
        self.name
    }
 
    fn noise(&self) -> &'static str {
        "woof!"
    }
 
    // Default trait methods can be overridden
    fn talk(&self) {
        // Traits methods can access the implementor methods
        self.wag_tail();
 
        println!("{} says {}", self.name, self.noise());
    }
}
 
struct Sheep { naked: bool, name: &'static str }
 
impl Sheep {
    fn is_naked(&self) -> bool {
        self.naked
    }
 
    fn shear(&mut self) {
        if self.is_naked() {
            // Implementor methods can use the implementor's trait methods
            println!("{} is already naked!", self.name());
        } else {
            println!("{} gets a haircut", self.name);
 
            self.talk();
            self.naked = true;
        }
    }
}
 
impl Animal for Sheep {
    fn new(name: &'static str) -> Sheep {
        Sheep { name: name, naked: false }
    }
 
    fn name(&self) -> &'static str {
        self.name
    }
 
    fn noise(&self) -> &'static str {
        if self.is_naked() {
            "baaah"
        } else {
            "baaaaaaaaaaaah"
        }
    }
}
 
fn main() {
    // Type annotation is necessary in this case
    let mut dolly: Sheep = Animal::new("Dolly");
    let spike: Dog = Animal::new("Spike");
    // TODO ^ Try removing the type annotations
 
    dolly.shear();
 
    spike.talk();
    dolly.talk();
}
на прототипном как-то так
Animal := Object clone do(
 name ::= ""
 talk := method((name .. " says " .. noise) println)
)
 
Dog := Animal clone do(noise := "woof")
Sheep := Animal clone do(
 naked ::= false
 shear := method(
  if(naked, (name .. " is already naked") println, (name .. " gets a haircut") println)
 )
 noise := method(
  if(naked, "baaah", "baaaaaaaaaaah")
 )
)
 
spike := Dog clone setName("Spike")
dolly := Sheep clone setName("Dolly")
 
spike talk
dolly talk
dolly shear

Но это примитивный случай. А настоящий смех начнется, когда дело коснется рантайма.

javaQest ()
Ответ на: комментарий от forCe

А можно вопрос? А так ли необходимо это выражать? Какую проблему это решает?

Я тыкнул в рандомное место, так что пример действительно не лучший. Однако перед bool operator<(Rc<T> a, Rc<T> b); есть солидное преимущество: оно ложится в строгую систему типов, которая пока (до введения и широкого применения концептов) в крестах отсутствует. Т.е. это именно Ord, а не просто абстрактный ad hoc полиморфизм (перегрузка). Поэтому я и говорю:

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

А то так можно и с js сравнивать начать.

loyd ()
Ответ на: комментарий от forCe

Не понял. Как ты this параметризируешь? Принимаемый аргумент — да, но речь-то об ограничениях на this.

loyd ()
Ответ на: комментарий от loyd

есть солидное преимущество: оно ложится в строгую систему типов,

Все правильно - давайте ограничение называть преимуществом, ну нет у нас перегрузки, даже по одному жалкому параметру. Нет у нас наследования. Зато без всего этого у нас есть «солидное преимущество» (с).

anonymous ()
Ответ на: комментарий от javaQest

А настоящий смех начнется, когда дело коснется рантайма.

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

loyd ()
Ответ на: комментарий от anonymous

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

loyd ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.