LINUX.ORG.RU

Найти «максимальный» элемент в контейнере по имени поля

 , ,


1

2

Рабочий пример на расте:

struct Data {
    number: usize,
    letter: char,
}

impl Data {
    fn new(number: usize, letter: char) -> Self {
        Data { number, letter }
    }
}

fn main() {
    let numbers = vec![
        Data::new(1, 'a'),
        Data::new(2, 'b'),
        Data::new(3, 'c'),
    ];
    println!("{:?}", numbers.iter().max_by_key(|v| v.number).map(|v| v.letter)); // Some('c')
}

Как это повторить в C++14?

PS: с tuple пример был бы проще, но для C++ это слишком сложно.

Ответ на: комментарий от RazrFalcon

Если нужно избавится от копирований, то можно либо смотреть в сторону такого рода getter-ов:

[](auto && d) -> decltype(auto) { return d.number; }
либо использовать указатели на члены, как показал аноним здесь

PS. Впрочем, если вы точно знаете типы полей, то можно и без особых наворотов:

[](auto && d) -> const size_t& { return d.number; }

eao197 ★★★★★ ()
Последнее исправление: eao197 (всего исправлений: 1)
#include <boost/bind.hpp>

#include <vector>
#include <algorithm>
#include <iostream>

struct Data {
    size_t number;
    char letter;
};

int main() {
    std::vector<Data> d = { { 1, 'a' }, { 2, 'b' }, { 3, 'c' } };
    auto max = std::max_element(d.cbegin(), d.cend(), boost::bind(&Data::number, _1) < boost::bind(&Data::number, _2));
    std::cout << max->letter << std::endl;
}

https://ideone.com/xshAnx
voivoid ()
Ответ на: комментарий от voivoid

boost::bind

уже 100 лет как в std завезли

anonymous ()

PS: с tuple пример был бы проще, но для C++ это слишком сложно.

лолшта?

template <int Id, typename Itr>
Itr max_by_key(Itr b, Itr e)
{
	return std::max_element(b, e, [](const auto &lft, const auto &rgt) { 
		return std::get<Id>(lft) < std::get<Id>(rgt); 
	});
}

int main()
{

	std::vector<std::tuple<int, char, double> > vec = {
		{ 1, 'C', 0.1 },
		{ 2, 'B', 1.1 },
		{ 3, 'A', 1.0 },
	};

	std::cout << std::get<0>(*max_by_key<0>(vec.begin(), vec.end())) << std::endl;
	std::cout << std::get<0>(*max_by_key<1>(vec.begin(), vec.end())) << std::endl;
	std::cout << std::get<0>(*max_by_key<2>(vec.begin(), vec.end())) << std::endl;

	return 0;
}

https://wandbox.org/permlink/RzFK4YQWRZLyWVRZ

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

Завезли, вот только не совсем такой, какой в boost. В частности в std'шном bind'е не перегружены операторы сравнения, как следствие ранее приведенный код работать не будет.

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

vs

fn main() {
    let numbers = &[(1, 'a'), (2, 'b'), (3, 'c')];
    println!("{:?}", numbers.iter().max_by_key(|v| v.0).map(|v| v.1)); // Some('c')
}
RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Казалось бы, пиши на Rust и радуйся жизни. Но ведь нет, нужно обязательно Rust сравнить с C++. С чего бы это? За Rust денег не платят?

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

Казалось бы, пиши на Rust и радуйся жизни.

Вы же прекрасно знаете почему не пишу. Зачем язвить.

За Rust денег не платят?

Да вроде платят.

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

Не нужно путать. Он не сравнивает раст и С++ - он манипулирует. Это балаболка.

Несколько фактов. Его итераторы - это параша из жабаскрипта, т.е. умеет только ++. Никаких оптимизаций, РА и прочих крестовых фишек нет.

Далее, он сравнивает голые базовые примитивы и говнолибную обёртку. Это как сравнивать сокеты и какой-нибудь express(либо что там) из жабаскрипта. Сравнение полностью шизофреническое.

Когда тебе раст-балаболка кидает свои форичи по тамплу - множишь на ноль его каким-нибудь fusion::for_each() и жуёт.

Тоже самое относительно этих цепочек, которые ламерки напастили из жабки. Цепочки нихрена не зерокост. В частности ламерок-мап, вместо взятие филда - т.е. копия филда, а не ссылка. И когда он напишет что-то сложнее хелворда - он точно так же побежит жевать.

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

Царь, за то, что ты поправил меня с decltype(auto) — спасибо. Писал поздно вечером, был невнимателен.

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

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

numbers.iter()

А теперь с 1 по 3?

max_by_key

Что это за параша? Причём тут key? Ламерки не осилили обобщить потуги вменяемо?

.map(|v| v.1)

Если ты пхп-говноваятель, каким образом ты сравниваешь своё тормазное дерьмо с крестами? Ты ошибся реальность.

Ну и да, чтоб сразу разрушить маня-мирок адепта:

template<size_t id, typename Tcontainer> auto & max_by_key(Tcontainer && container) {
  return *std::max_element(std::begin(container), std::end(container), [](const auto & a, const auto & b) {
    return std::get<id>(a) < std::get<id>(b); 
  });
}

int main() {
  std::vector numbers{std::tuple{1, 'a'}, {2, 'b'}, {3, 'c'}};
  std::cerr << std::get<1>(max_by_key<0>(numbers)) << std::endl;
}
LjubaSherif ()
Ответ на: комментарий от LjubaSherif

А теперь с 1 по 3?

«Ты просто слаб» чтобы погуглить?

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

Именно оно. Спасибо.

Если ты скопипастил этот код без изменений, то не забудь добавить & в аргументы лямбды, а то на gcc будут копирования.

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

А теперь с 1 по 3?

Слайсы же есть.

Причём тут key?

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

Ламерки не осилили обобщить потуги вменяемо?

Осилили как вариант с компаратором, так и с ключом, потому что второй всё же довольно популярен.

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

Слайсы же есть.

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

Да и не поможет это, всё равно колхоз-итераторы уровня жабаскрипта, который не могут даже в RA - это полная херня. Какая производительность с такими итераторами?

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

И? Причём тут key? Какое отношение получаемый результат имеет к ключу? Никакого. Какое отношение лямбда имеем к ключу? Предположим, что просто название придумывал не особо вменяемый адепт, но причём тут лямбда? Колхозая поделка не смогла в нормальный селектор поля?

Я понимаю, что изначально это было numbers.map().max_element(), но слишком по оверхедному и решили накастылить эту херню. Просто убожество.

По поводу ТС"а - он ничего не хочет. Он пишет херню и ставит какие-то мусорные условия. Т.е. он пытается весь мир натягивать на свои реалии. Это глупости, которые не имеют никакого отношения к объективности.

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

Осилили как вариант с компаратором, так и с ключом, потому что второй всё же довольно популярен.

Не осилили - селектора поля нету, а это просто колхоз уровня детсада. Название просто дерьмо.

Две костыльные херни - это не обобщение. Обобщение в крестах, настолько обобщение, что блевать тянет, но обобщение. Это же не обобщение.

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

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

Вот и получается такое убожество как &[(),()], vec![] и прочая несуразная херня. Я много видал дерьма, но такого - ниразу. Просто рандомный набор символов, в одной ситуации один костыль, а в другой другой.

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

Этот мусор! - вообще смешон.

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

Я много видал дерьма, но такого - ниразу. Просто рандомный набор символов, в одной ситуации один костыль, а в другой другой.

Ты просто медленный. Пройдет еще несколько лет - может, поймешь. Когда-то ты и плюсы считал убожеством.

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

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

А понять - я никогда и ничего не пойму, как и ты. Это просто набор рандомных костылей. Этому нет объяснений, это нельзя понять. Это не имеет общего начала, общих идей - это просто напащенные из разных мест куски, символы, большинство из них просто убогие.

Простой пример - !. Зачем? Твои язык настолько дерьмо, что он умеет в контекст и не отличит вызов функции от вызова макроса? Синтаксис самих макросов просто упорот в хлам, тоже откуда-то спащен. Зачем тебе язык, если для описания макросов тебе нужен новый язык? Твоя язык дерьмо? Да.

Чего стоит #[] для атрибутов, даже мусорное крестовое [[]] лучше. Да и твой «язык» синтаксический детсадовец - можно и [] использовать.

И таких мест море - все. Никто и никогда мне не объединит эти конструкции в рамках одной логики, одного стиля. В ситуации с крестами всё это возможно.

Это и отличает язык и набор рандомных слов, которые притворяются языком.

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

Никто и никогда мне не объединит эти конструкции в рамках одной логики, одного стиля

Вот здесь согласен. Никто не объяснит этого тебе, никто даже пробовать не станет. Это никому не нужно.

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

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

Ну да, это в общем случае даже несколько хуже итераторов, потому что не может справиться с non-contigous контейнерами. Но в данном случае оно сработает, и я не вижу причин, по которым это хуже итераторов.

который не могут даже в RA

Насколько я понимаю, как раз могут.

Какая производительность с такими итераторами?

А что тут не так с производительностью?

Какое отношение лямбда имеем к ключу?

В данном случае «ключ» — это и есть функция, которая переводит объект в другой, по которому ведётся сравнение. Выделять отдельно функцию взятия значения поля кажется не очень нужным, потому что компилятор почти наверняка заинлайнит (по крайней мере, ему вряд ли что-то мешает это сделать).

numbers.map().max_element()

Не понял, что за пустой map()? Можешь написать полностью?

Не осилили - селектора поля нету

А зачем селектор поля, если есть max_by и max_by_key?

f1u77y ★★★ ()

Объясните несправедливость: тылганер удалил ответ царя, на сообщение со словами «жопа» и прочие. Как это понимать? Почему еао197 может писать тут «жопа» и его сообщения не трут, а нормальный ответ(без оскорблений и матерков) затерли?

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

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

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

Не совсем в тему, но что думаешь про opencl, spir-v и т.п.?

Там тоже не осилили обобщение?

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

Ну да, это в общем случае даже несколько хуже итераторов, потому что не может справиться с non-contigous контейнерами. Но в данном случае оно сработает, и я не вижу причин, по которым это хуже итераторов.

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

Насколько я понимаю, как раз могут.
usize

Действительно, RA такое RA. Скорее всего это просто дристня с next в цикле.

А что тут не так с производительностью?

В крестах есть типы итераторов, с которых можно по лучить информацию об существующих/оптимальных методах обхода. В твоей дристне - это хелворд с next(), который не может в prev() и в RA, да и ни во что он не может. Это непонятно какая хреня спащенная из жабаскрипта.

В данном случае «ключ» — это и есть функция, которая переводит объект в другой, по которому ведётся сравнение.

Ну с таким успехом что угодно можно называть ключом.

Выделять отдельно функцию взятия значения поля кажется не очень нужным

Просто не осилили.

потому что компилятор почти наверняка заинлайнит (по крайней мере, ему вряд ли что-то мешает это сделать).

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

Это просто мусорный костыль, где из-за убогости языка каждую операцию надо костылить лямбдой.

Не понял, что за пустой map()? Можешь написать полностью?

Очевидно, я не хочу использовать твой мусорный синтаксис, но так уж и быть. numbers.map(|v| v.key).max_element(); либо просто max().

Да и можно ещё проще, numbers.max(v::key)

А зачем селектор поля, если есть max_by и max_by_key?

Нету их у тебя, они не могут без селектора поля накастыленном на лямбде. Вот если бы было max_by_key(v::key) - то да, селектор поля тебе не нужен. Но у тебя этого нет. Да что там далеко ходить, можно даже max_by_key(::key).

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

> usize

Окей, forward-only — это неудобно, согласен.

Скорее всего это просто дристня с next в цикле.

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

В твоей дристне

Когда она моей стала? Она общая, всенародная.

Ну с таким успехом что угодно можно называть ключом.

Ну тут ты загнул, потому что это здесь, например, можно провести аналогию с отсортированным key-value контейнером вроде std::multimap. Если контейнер сортируется по некоторым штукам, связанным с value в массиве, то вполне нормально называть их key, а способ однозначно получить key по value — key function.

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

Полагаться только на стандарт языка — это, конечно, хорошо. Но мне кажется, что всё же следует знать, например, что можно не писать a & 1 вместо a % 2, потому что это скомпилируется в один и тот же код (только для unsigned, на всякий). Или что можно не париться по поводу оверхеда на вызов функций в случае простейших, вида «взять значение поля».

numbers.map(|v| v.key).max_element()

В качестве замены этому коду не подойдёт, потому что в качестве результата возвращается другое поле.

костылить лямбдой

Почему ты считаешь это костылём?

Нету их у тебя

4.2. Да, нет отдельной операции для max_elementпо полю структуры. Но лично я не вижу в этом необходимости, потому что .max_by_key() справляется с этой функциональностью, причём почти наверняка без потерь по производительности. Если не веришь, измерю.

numbers.max(v::key)

Я такого в Rust не нашёл, не гуглится. Можешь показать minimal working expample компилящегося кода с подобным?

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

Я в курсе. Только мне не нужна функция, мне нужно по полю. Без лишнего мусора.

Мне кажется, ты наркоман. У тебя в max_by_key и map написаны лямбды. В крестах ты точно так же можешь передать лямбду в алгоритм.

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

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

Понимаешь, не нужно путать жопу и палец. Есть архитектурные решения, а если костыляние. В крестах всё существует на уровне архитектуры, а в расте нет. А рандомные колхоз оптимизации, которые там чисто для вида и родились через 10лет после релиза - это мусор.

Ну тут ты загнул, потому что это здесь, например, можно провести аналогию с отсортированным key-value контейнером вроде std::multimap. Если контейнер сортируется по некоторым штукам, связанным с value в массиве, то вполне нормально называть их key, а способ однозначно получить key по value — key function.

Только вот там левая лямбда, которая может делать что угодно. К тому же это не key. Ладно, пусть будет key - мне без разницы. Я не вижу разницы между max_by() и max_by_key(). А наоборот, для меня, key выглядит как дерьмо.

Полагаться только на стандарт языка — это, конечно, хорошо.

Дело не в стандарте, а в архитектуре. В крестах есть хоть какая-то, но архитектура. В расте - набор дерьма, который работает хрен пойми как и функционально нищий.

В качестве замены этому коду не подойдёт, потому что в качестве результата возвращается другое поле.

Хорошо, я ниже дал то, что подойдёт.

Почему ты считаешь это костылём?

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

Это примерно как сделать все типа аргументов у функций шаблонами, а чё - работать будет. Любой шаблон, любая лямбда(в этом и подобном контексте) - это дыра в дизайне.

4.2. Да, нет отдельной операции для max_elementпо полю структуры.

А какие ещё бывают? У тебя есть структура, тампл( который у тебя именован ака жабаскрипт). Что ещё может быть? Любые базовые типы не нуждаются в селекторе - там будет базовая перегрузка без аргумента.

Но лично я не вижу в этом необходимости, потому что .max_by_key() справляется с этой функциональностью, причём почти наверняка без потерь по производительности. Если не веришь, измерю.

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

Я лямбда в этом контексте - это просто || global++, да много чего ещё. Она выделяется из предполагаемого api, её функционал шире необходимого.

Я такого в Rust не нашёл, не гуглится.

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

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

рандомные колхоз оптимизации

Почему это «рандомные» и тем более «оптимизации». Для каждого impl Iterator нужно определить в том числе метод .nth(), ровно так же, как и в плюсах нужно определять для итератора operator+=. В чём принципиальная разница, мне непонятно.

Только вот там левая лямбда, которая может делать что угодно.

А в чём проблема? Зачем две разных функции для сортировке по полю и, например, по |x| x % 228?

А какие ещё бывают?

Но я же как раз говорил.

Она выделяется из предполагаемого api, её функционал шире необходимого.

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

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

Ты бы лучше не за синтаксис спорил, а выяснил почему std::max_element так тормозит на gcc. Зарепортил им баг может. А то негоже чтоб плюсы медленнее раста были.

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

Ты бы лучше не за синтаксис спорил, а выяснил почему std::max_element так тормозит на gcc.

Где и как она тормозит? Чему там тормозить? Да и вообще, зачем кому-то(кому нужна производительность) нужен этот max_element()?

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

А стандартная лажает,

ну а код ее посмотреть не? Онаж в хедерах. В оффтопике, например, дебажный и недебажный вариант отличаются. А недебажный реализован практически как в possible implementation

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

так те же самые хедеры под шлангом нормально работают

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

Я лямбда в этом контексте - это просто || global++, да много чего ещё. Она выделяется из предполагаемого api, её функционал шире необходимого.

Если бы ты хоть немного знал про раст, ты бы знал про BorrowCk и отсутствие общего изменяемого состояния, и не нес бы несуразный бред про лямбды-дыры в безопасности.

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

Гцц не смог оптимизировать код.

while(++__first != __last)

Каким-то образом из-за ++__first он не смог в cmov и оставляет днище-ифы. Причём ++__first; do while(++__first != __last); и прочее - работает нормально.

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

Давайте поговорим еще про перформанс итераторов и неосиляторство авторов компилятора.

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

Колхозник, что же ты такой одарённый. Я понимаю, что твоей извилины хватает на мусорную ретрансляцию 1-2 шаблонных базворда, которые ты где-то услышал. Во-первых борроу-чекер? Ты высрал первый известный тебе базворд связанный с растом?

Во-вторых, причём тут какое-то общее изменяемое состояние. Если твой мусор не умеет изменять состояние из чего-то во внешнем контексте - это дерьмо, которое никому не нужно. К тому же, логика нарушается и без его изменения. Может туда написал || global, |v| v.n + 1; Да что угодно можешь написать.

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

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

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

Что и зачем ты тут делаешь, если ты даже портянку базового кода осознать не можешь? Очередной ламерок из пхп вылез? Ну дак залезь обратно. Всё равно обтекать придётся.

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

Во-первых борроу-чекер?

Я не виноват что ты не в курсе, почитай доку, может поможет, если ты все еще в состоянии осознавать концепции за пределами своего манямирка

Может туда написал |v| v.n + 1; Да что угодно можешь написать.

Нет, не могу, иди читай доку языка и сигнатуру метода.

Эти балаболы такие наивные.

Балабол тут только ты. Так самозабвенно пороть херню и считать себя правым — это талант.

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

Это не компилятор, тебя обманули. Это мусорный фронтенд для ллвм.

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

Ты тут вроде за обобщение топил.

На кой хер писать свой оптимизатор и кодген под кучу платформ, когда есть уже готовый?

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

Я не виноват что ты не в курсе, почитай доку, может поможет, если ты все еще в состоянии осознавать концепции за пределами своего манямирка

Тебе задали конкретный вопрос, ламерок - причём тут он. Если не можешь ответить - так и запишем - балабол. Детсадовские потуги «почитай доку» будешь вещать в детсаде, а в реальном мире подобные заявления равносильны «мне нечего ответить».

Нет, не могу, иди читай доку языка и сигнатуру метода.

Обоснования этих потуг в студию.

Балабол тут только ты. Так самозабвенно пороть херню и считать себя правым — это талант.

Эти потуги, эти потуги. Прибежал, выкрикнул базворд и какую-то херню, как только начали задавать вопросы - обделался и начал ссылаться «да ты просто не знаешь». Фу, убогое трепло.

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

Не мажся балаболка, ты сел в лужу, ведь у твоего мусора нету компилятора и я был прав.

На кой хер писать свой оптимизатор и кодген под кучу платформ, когда есть уже готовый?

Сообщаю новость, компилятор из этого и состоит. И дело не в этом, ты кукарекал про какие-то «не осилят», «перформанс», а оказывается, что это никакого отношения к твоему недоязычку не имеет и они просто взяли готовое. Дак сиди и не кукарекай.

К тому же, я тебе сообщаю новость. Взяли они его не для того, чтобы «не переделывать готовое», а потому, что это ламерки, которые и десятую часть ллвм"а не запилят.

К тому же, если кресты - зачем придумывать мусорный недоязычок, если есть уже готовый?

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

я был прав

Если тебе так комфортнее — пожалуйста

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