Здравствуйте, Олег К., Вы писали:
M>>>А подробнее? Что именно, "нормальный софтверный инженер", исключил бы из нововведений с++11?
MTD>>Коллега, нашли кого спрашивать
ОК>Вот смотрите, коллега. Есть D. Mon, есть bazis1 со своими проектами и компаниями которые приносят им деньги. Еще есть ИТ со своим проектом (не знаю как там с монетизацией). Я понимаю как они мыслят (и с чем-то согласен, с чем-то нет) и для меня эти люди — профессионалы. А Вы чем можете похвастаться? Знанием стандарта С++ и никому ненужных фич? Ну что — поздравляю!
Как я тебе уже ответил в другой ветке, ты смешиваешь умение запустить свой бизнес и вопрос квалификации разработчика. Ну давай сравним нефтянника и геолога, судя по твоей логике нефтянник — профессионал, а геолог, который нашел месторождение — школота.
ОК>>В С++ 98-го более чем достаточно фич чтобы писать нормальный код. Лично я еще С++11 даже и не открывал но скоро открою и лишь только по одной причине; на интервью может попасться какой-нибудь очередной идиот который знает все новомодные фишки и считает что раз он пихает их все куда ни попадя, так и все остальные должны их также пихать. Вообще перечитай еще раз мой ответ выше, может дойдет.
M>Ну вот ты бы почитал сначала хотя бы обзор нового стандарта, а потом брызгал слюной
Где я брызгаю? Мой экспириенс говорит в С++ 98 было бы лучше заменить std::auto_ptr<> и регулярных выражений еще не хватало. Больше ничего на ум не приходит, по крайней мере сейчас.
M>В языке появились новые концепции и сущности, которые радикально меняют подход к программированию, стандартная библиотека серьезно подросла — теперь не надо чуть что лезть в буст, куча "синтаксического сахара", который делает код читабельней и компактней.
Какие новшества! Если раньше надо было написать пять строчек кода, то сейчас три!
M>Ну, а на счет "идиотов на собеседовании", тебе не приходила мысль, что в проекте может активно использоваться возможности с++11 и команде не нужен "идиот", которому лень учиться, зато нравиться всех поучать?
А тебе не приходит в голову что все эти фичи могут быть и ненужны? То о чем я уже который раз и говорю. В общем подрастешь — поймешь.
M>З.Ы. на msdn chanel9 есть немало видео обзоров: GoingNative2012 и блог STL посмотри что ли, это интересно.
Благодарю покорно. Я лучше схожу на стартаперские тусовки а вас, любителей всех паттернов, новшеств и Александреску, надо заставлять поддерживать код написанный другими такими же любителями. Чтоб неповадно было! А то кругом одни профессионалы но все почему-то кричат "говнокод-говнокод!"
M>Как я тебе уже ответил в другой ветке, ты смешиваешь умение запустить свой бизнес и вопрос квалификации разработчика. Ну давай сравним нефтянника и геолога, судя по твоей логике нефтянник — профессионал, а геолог, который нашел месторождение — школота.
Не смешиваю. Я рассуждаю как сеньйор и начальник. А ты, вот, знаешь географическую загадку русской души?
Так сколько тебе лет? Хотя бы тридцать есть?
M>Ты смешиваешь интересы бизнеса, о которых мы вобщем-то сейчас не спорим, с вопросом, что должен знать и уметь квалифицированый разработчик. Я смотрю на проблему с точки зрения программиста — рабочей лошадки, в обязанности которого входит проектирование пусть и небольших, но независимых кусков проекта. Я убежден, что грамотное решение проблемы требует от человека хороших знаний инчтрумента, в нашем случае языка и стандартной библиотеки. Те нововведения, которые предлагает новый стандарт, исключают создание многих ненужных велосипедов, а значит экономит время и дает более надежное решение. Если человек не в курсе, он начнет "изобретать колесо". Нужно это? Конечно, нет.
Чувак, ты можешь сколько угодно читать книг и рассуждать о разработке, но для меня профессионал тот — который может начать и закончить проект.
Почитать книжку и написать кусочек кода в компиляторе чтобы посмотреть как работает та или иная фишка — ничего сложного в этом нет. Видел я таких читателей... Фишки знают, программировать не умеют.
ОК>>Сколько им лет? Может быть люди просто выросли и пришло понимание что не все нужно для разработки? А кому-то это понимание может никогда и не прийти, что плохо конечно же. Я, вот, честно сказал что буду знакомиться с новым стандартом только по одной причине: потому что никак непозврослевшие "сеньйоры" будут спрашивать последние фишки на интервью.
M>Как я написал, выше, эти знания важны если человек позиционирует себя как квалифицированного разработчика, иначе как он может принимать правильные решения.
Бла-бла-бла. Заучиватель стандарта не есть квалифицированный разработчик и я смотрю у тебя не та квалификация чтобы это понять. Советую зайти в форум по шароваре. Там люди создают проекты которые же сами и продают. Спрашивается, кто является большим профессионалом? Они или ты, любитель стандарта?
Здравствуйте, Олег К., Вы писали:
IT>>Отсюда вытекает, например, повышение выразительности языка и устранение кучи мусора вроде:
IT>>
IT>>MyObject obj = new MyObject();
IT>>
ОК>По мне, так это не мусор а получше чем писать вар. Возможное исключение: всякие "вложенные" дженерики. Ну и для линка, конечно же.
Когда-то я тоже был ярым сторонником полного описания типов. Я долго не принимал var (использовал его только в линковых выражениях). Время шло, я развивался (во всяком случае мне так кажется), и я осознал удобство краткости кода.
ОК>Объясняю это на протяжении нескольких постов. Плохого в них ничего нет но их не создавали чтобы девелоперы использовали их налево и направо. Теперь ты объясни мне что в них хорошего (кроме анонимных типов и вложенных дженериков). Я пока что не услышал ответа.
Мне попадались такие высказывания на эту тему.
Начинающие программисты много внимания уделяют типу переменной; разбирая чужой код, они в первую очередь смотрят на тип, и таким образом пытаются понять, что можно сделать с этой переменной (этим объектом). И эти джуниоры мало уделяют внимания наименованию переменных.
Более опытные разработчики типу уделяют гораздо меньше внимания. Для них важнее сама семантика кода. Гораздо важнее название переменной, а не её тип. Дав описательное название переменной, можно по сути пренебречь её типом: и так всё ясно.
Здравствуйте, Олег К., Вы писали:
ОК>Чувак, ты можешь сколько угодно читать книг и рассуждать о разработке, но для меня профессионал тот — который может начать и закончить проект.
ОК>Бла-бла-бла. Заучиватель стандарта не есть квалифицированный разработчик и я смотрю у тебя не та квалификация чтобы это понять. Советую зайти в форум по шароваре. Там люди создают проекты которые же сами и продают. Спрашивается, кто является большим профессионалом? Они или ты, любитель стандарта?
Приведу такое сравнение. В школьные годы я занимался в авиамодельном кружке. Я сам делал бойцовые модели, с начала и до конца. Выпиливал лобзиком из бальсы, резал раскалённой проволокой пенопласт, клеил плёнку, вырезал винты, перебирал двигатели, и многое-многое другое. Моделист — тот же шароварщик: делаёт самолёт с начала до конца.
Между тем настоящие самолёты не делаются одним человеком. Есть куча конструкторов, каждый из которых отвечает за проектирование "кусочка" самолёта: планер, двигатель, шасси, электроника и т. д.
А теперь задайся вопросом: кто настоящий профессионал? Тот кто делает целый самолёт (моделист) или тот кто делает часть самолёта (инженер-конструктор)?
Имхо, ответ: и те, и другие. Просто у каждого своя специализация.
Моделист умеет работать руками, не зная сопромата. Шароварщик может настругать тонны кода, от вида которого девелопер из большой конторы придёт в ужас (при этом готовая шаровара будет приятна на вид, быстра, удобно и хорошо продаваться). Думаю, понятно.
ОК>>По мне, так это не мусор а получше чем писать вар. Возможное исключение: всякие "вложенные" дженерики. Ну и для линка, конечно же.
K>Когда-то я тоже был ярым сторонником полного описания типов. Я долго не принимал var (использовал его только в линковых выражениях). Время шло, я развивался (во всяком случае мне так кажется), и я осознал удобство краткости кода.
Интересная точка зрения и самое главное — спокойный ответ! Я наоборот пришел к тому что лучше использовать чуть большую словесность и всячески избегать экзотические и "крутые с точки зрения реальных пацанов" конструкции.
ОК>>Объясняю это на протяжении нескольких постов. Плохого в них ничего нет но их не создавали чтобы девелоперы использовали их налево и направо. Теперь ты объясни мне что в них хорошего (кроме анонимных типов и вложенных дженериков). Я пока что не услышал ответа.
K>Мне попадались такие высказывания на эту тему.
Да сама МСДН так и говорит и многие авторы также. Плюс я сам согласен.
K>Начинающие программисты много внимания уделяют типу переменной; разбирая чужой код, они в первую очередь смотрят на тип, и таким образом пытаются понять, что можно сделать с этой переменной (этим объектом). И эти джуниоры мало уделяют внимания наименованию переменных.
В каком году начал профессиональную карьеру?
K>Более опытные разработчики типу уделяют гораздо меньше внимания. Для них важнее сама семантика кода. Гораздо важнее название переменной, а не её тип. Дав описательное название переменной, можно по сути пренебречь её типом: и так всё ясно.
Я согласен но неужели ты никогда не наводишь мышку на переменную чтобы увидеть ее тип? Особенно если код чужой. По-моему ты лукавишь немного.
K>И я с таким мнением согласен.
ОК>>Чувак, ты можешь сколько угодно читать книг и рассуждать о разработке, но для меня профессионал тот — который может начать и закончить проект.
ОК>>Бла-бла-бла. Заучиватель стандарта не есть квалифицированный разработчик и я смотрю у тебя не та квалификация чтобы это понять. Советую зайти в форум по шароваре. Там люди создают проекты которые же сами и продают. Спрашивается, кто является большим профессионалом? Они или ты, любитель стандарта?
K>Приведу такое сравнение. В школьные годы я занимался в авиамодельном кружке. Я сам делал бойцовые модели, с начала и до конца. Выпиливал лобзиком из бальсы, резал раскалённой проволокой пенопласт, клеил плёнку, вырезал винты, перебирал двигатели, и многое-многое другое. Моделист — тот же шароварщик: делаёт самолёт с начала до конца.
Продолжая твое сравнение... А кто-то читал как делать эти модели но никогда не "марал" руки.
K>Между тем настоящие самолёты не делаются одним человеком. Есть куча конструкторов, каждый из которых отвечает за проектирование "кусочка" самолёта: планер, двигатель, шасси, электроника и т. д.
K>А теперь задайся вопросом: кто настоящий профессионал? Тот кто делает целый самолёт (моделист) или тот кто делает часть самолёта (инженер-конструктор)? K>Имхо, ответ: и те, и другие. Просто у каждого своя специализация.
У тебя неверная аналогия. Разумеется настоящий самолет сам не построишь но если взять нас, обычных программистов, работающих на дядю, то кто-то приходит домой и читает стандарт а кто садиться программировать, пишет код, меняет код. В общем делает практическую работу а не только теоретизирует.
K>Моделист умеет работать руками, не зная сопромата. Шароварщик может настругать тонны кода, от вида которого девелопер из большой конторы придёт в ужас (при этом готовая шаровара будет приятна на вид, быстра, удобно и хорошо продаваться). Думаю, понятно.
Не исключенна и обратная ситуация. Шароварщик прийдет в ужас от того что "девелоперы в большой конторе" могу набангалорить дяде. Так что будем считать что здесь счет 1:1 но, повторюсь, шароварщики программируют ради чего-то нужного, полезного в то время как любители стандарта попробуют несколько строчек в компиляторе чтобы увидеть как работает та или иная фича и считают себя профи. И, согласись, что работать с большим количеством кода, большим количеством файлов сложнее чем пробовать разные фичи языка.
Здравствуйте, D. Mon, Вы писали:
I>>Компиляторы — это мимо кассы, компилятор С# доказывает
DM>Что именно доказывает? csc был на плюсах написан, насколько я знаю.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>ля-ля-ля, это не задача, это _решение_ задачи. Поскольку ты сам задачу поставить не можешь, сделаю это за тебя. Смотри, как все просто — реализовать оконное FFT. Чуть более чем весь код для этого в сишном стиле. А вот то что ты показываешь это отстой.
EP>Если сложение векторов это _решение_ задачи, то FFT — это точно такое же _решение_ задачи, а не задача
Ты говорил про массивы, индексы и структуру. Оконное FFT — здесь ничего нет ни про массивы, ни про индексы, ни про конкретную структуру.
EP>>>Как ты из этого сделал вывод об "кастрированых замыканиях" — я не пойму I>>Очень просто — возможность ручного тюнинга "скомпенсирована" обязательностью такого тюнига, то есть, лямбды просто нельзя применять так, как они применяются в других языках. Это ж очевидно — GC отсутствует, стало быть передавать лямбды наверх нельзя,
EP>Кто тебе такую чушь сказал?
Ты сам же и сказал.
I>>нужно обязательно обкладывать костылями, например счетчиком ссылок, а стало быть надо писать специальный код для управления этим счетчиком.
EP>Так код-то уже есть в библиотеках. Помимо счётчика ссылок есть другие варианты — copy, move, move-on-copy, generalized capture.
Вот-вот.
EP>Почему ты называешь наличие выбора, а не его отсутствие — "кастрацией"?
Представь себе ситуацию — идешь по улице, появляется коробейник и предлагает тебе на выбор чего то купить. Ты отказываешься и идешь дальше.
Другой вариант — идешь по улице, появляется коробейник, выбор сумасшедший, от сигарет до феррари, но отказаться у тебя нет возможности.
Странно, но второй случай почему то описан в Уголовном Кодексе.
Отсюда ясно, что __обязательность__ какого то выбора это совсем не то же самое, что и свобода выбора. Вот если бы можно было передавать лямбды как попало, а вот тюнить надо было только для перформанса-расхода памяти, тогда другое дело. Скажем в дотнете худо бедно, но такая возможность есть, можно сделать так, что все лямбды-делегаты внезапно станут очень медленными, раз в 100, относительно вызова пустой лямбды, но при этом станут занимать памяти примерно вчетверо меньше.
I>>Если твой пример не является типичным, то его незачем и рассматривать. Типичный код это такой, с которым имеет дело большинство. Не усредненный, по количеству строчек, а некоторая мода(статистика, а не одежда).
EP>Так, давай заново: EP>
I>>Что характерно, быстрый код на С++ это точно так же работа против языка. Почему то самые критичные куски кода пишутся практически на С или подобным образом.
EP>Я правильно понимаю, что ты имел ввиду что человек знающий и C и C++ предпочтёт писать быстрый код практически на C, ограничивая себя в выразительных средствах C++?
Именно так. В обработке звука, видео код весь до дыр сишный, плюсов там обычно совсем немного, только верхний интерфейс и некритичные функции. Как то так. И это именно типичный случай.
I>>>>Уже все сказано. На одном проекте 40 индусов майнтейнят либу для линейного программирования, а на другом один человек майнтейнит такую же либу да же пачку из других областей. Вопрос — какой код считать типичным для этого примера EP>>>Вопроса не понял. Какого примера? I>>Выделил.
EP>Есть две одинаковых либы ("такую же либу") — одну поддерживает 1 человек, а другую 40, так? EP>Что ты подразумеваешь под "типичным кодом"? Две либы делают одно и тоже — почему? Эти команды никак не общаются?
Я хочу выяснить, как ты понимаешь это слово. Две либы делают одно и то же — очень просто, в аутсорсной конторе два разных проекта, с разной историей и разным руководством и разными заказчиками. Прийти и сказать "а у нас есть другая либа, получше, подешевле написаная для вашего конкурента" — вот так сказать в аутсорсе никто не может и не имеет права.
_>Вообще не вижу в этом коде никаких завязок на язык. Такое можно сделать наверное в любом, с буквально таким же синтаксисом. Если говорить про C++, то для многопоточного варианта подобное вставили уже вообще в сам стандарт языка (async/future), если же хотим в одном потоке, то берём одну из множества библиотек реализующих сопроцедуры. Хотя слово "библиотека" тут даже слишком громкое — сопроцедуры можно реализовать в несколько сотен строк на большинстве языков программирования.
Ты не рассуждай, а покажи код. Ну что за беда с сиплюсниками, чуть что, сразу в кусты. Ни кода, ни денег.
Здравствуйте, Ikemefula, Вы писали:
EP>>Если сложение векторов это _решение_ задачи, то FFT — это точно такое же _решение_ задачи, а не задача I>Ты говорил про массивы, индексы и структуру. Оконное FFT — здесь ничего нет ни про массивы, ни про индексы, ни про конкретную структуру.
Это задача — извне приходит массив элементов и индексы. Если бы извне приходили уже готовые координаты векторов, без индексов, то это была бы другая задача.
Точно также как если бы для FFT входная функция задавалась таблично, либо как callback — код не был бы идентичным.
Хватит разводить демагогию — talk is cheap show me the code.
I>Отсюда ясно, что __обязательность__ какого то выбора это совсем не то же самое, что и свобода выбора. Вот если бы можно было передавать лямбды как попало, а вот тюнить надо было только для перформанса-расхода памяти, тогда другое дело.
ага, как попало:
using System;
using System.IO;
public class Test
{
public delegate void fireworks();
public static fireworks make_closure(FileStream fs)
{
return () => fs.Read(new byte[10], 0, 10); // "передавать лямбды как попало, куда попало!!"
}
public static fireworks fire()
{
using (var fs = File.Open("file", FileMode.Open))
{
return make_closure(fs);
}
}
public static void Main()
{
fire()();
}
}
А что это такое белое и пушистое прилетело в виде System.ObjectDisposedException?
EP>>
I>>>Что характерно, быстрый код на С++ это точно так же работа против языка. Почему то самые критичные куски кода пишутся практически на С или подобным образом.
EP>>Я правильно понимаю, что ты имел ввиду что человек знающий и C и C++ предпочтёт писать быстрый код практически на C, ограничивая себя в выразительных средствах C++? I>Именно так. В обработке звука, видео код весь до дыр сишный, плюсов там обычно совсем немного, только верхний интерфейс и некритичные функции. Как то так. И это именно типичный случай.
И как то что где-то когда-то использовалось C, подтверждает твой тезис "быстрый код на С++ это точно так же работа против языка"?
I>Я хочу выяснить, как ты понимаешь это слово. Две либы делают одно и то же — очень просто, в аутсорсной конторе два разных проекта, с разной историей и разным руководством и разными заказчиками. Прийти и сказать "а у нас есть другая либа, получше, подешевле написаная для вашего конкурента" — вот так сказать в аутсорсе никто не может и не имеет права.
Есть аутсорсная контора, в ней два независимых проекта один на foo другой на bar — какой код считать типичным? foobar? Нет, так ведь foo в 2 раза больше — значит foofoobar?
G>>Хочу поиграться с чем-нибудь, чтобы компилилось сразу в native код. Аналог C++'са, но не слишком экзотическое, малоизвестное или вымирающее. На ум приходит только D и Rust. Что порекомендуете?
vsb>Objective C
Согласен. Поддержка от Apple еще надолго останется.
private async void handler(object sender, TaskArgs args)
{
var client = new HttpClient();
var response = await client.GetAsync(args.Url, args.Cancellation);
response.EnsureSuccessStatusCode();
textBox.Text += await response.Content.ReadAsStringAsync();
}
Чтобы ты лучше понимал что происходит, распишу по-русски как оно работает. Предположим что это десктопное приложение.
1) вызывается handler
2) делается запрос на сервер, метод сразу же завершается и уходит а ожидание сообщений или делает полезную работу
3) Когда приходит заголовок ответа вызов хендлера маршалится в UI поток через цикл обработки сообщений
4) Когда в UI потоке находится время обработать, он проверяет успешность вызова и запускает асинхронное чтение данных ответа и завершает вызов.
5) когда весь ответ прочитан вызов хендлера снова маршалится в UI поток
6) Кода в UI потоке находится время, он добавляет текст ответа в TextBox
Такая архитектура позволяет делать очень много подобной "работы", вообще без создания потоков, при этом ни на долю секунды не потеряв отзывчивость интерфейса.
Давай, детка, сделай это на C++.
Более того, на сервере еще интереснее ситуация. Сделав правильно обработку входящих запросов можно обработанные данные писать на диск\в базу во время того как клиент данные еще отправляет. Причем для этого не надо плодить потоки.
Это позволяет таких показателей латентности добиться, что ни одному серверу на C++ не снилось.
Здравствуйте, gandjustas, Вы писали:
G>Чтобы ты лучше понимал что происходит, распишу по-русски как оно работает. Предположим что это десктопное приложение. G>1) вызывается handler G>2) делается запрос на сервер, метод сразу же завершается и уходит а ожидание сообщений или делает полезную работу G>3) Когда приходит заголовок ответа вызов хендлера маршалится в UI поток через цикл обработки сообщений G>4) Когда в UI потоке находится время обработать, он проверяет успешность вызова и запускает асинхронное чтение данных ответа и завершает вызов. G>5) когда весь ответ прочитан вызов хендлера снова маршалится в UI поток G>6) Кода в UI потоке находится время, он добавляет текст ответа в TextBox G>Такая архитектура позволяет делать очень много подобной "работы", вообще без создания потоков, при этом ни на долю секунды не потеряв отзывчивость интерфейса. G>Давай, детка, сделай это на C++.
Я смотрю в этом топике у радикальных C#-стов мода на годовалый await и хамство — это профессиональное?
"Чтобы ты лучше понял", C++ код приведённый выше именно это и делает, ну разве кроме EnsureSuccessStatusCode и второго await'а которых не было в исходном запросе
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
G>>>>А если требует то важна не сама скорость работы, а perceived performance. EP>>>Если вычисление идёт 30 минут, вместо возможных десяти секунд, то ты хоть как украшай progress bar рюшечками — это не поможет. G>>30 минут надо считать на сервере, клиент может столько и не прожить.
EP>Что за плоское представление о мире? Кто говорил что в этом случае вообще есть сервера?
Здравый смысл. Десктопное приложение, считающее что-то 30 минут, без возможности остановить и продолжить "потом", в реальном мире (у не программистов) существовать не будет.
Ускорить его в 600 раз переписыванием даже на ассемблере в реальном мире тоже не выйдет.
А вот если мы начинаем что-то писать на диск, то это начинает сильно бить по производительности прямых вычислений и уже становится важно как ты работаешь с диском, а не насколько процентов быстрее у тебя работает цикл.
Но самый реальный вариант, это наличие сервера для вычислений на 30 минут. Причем такого, который можно масштабировать. Чтобы считалось 10 минут вместо 30 и могло такие расчеты делать 100 человек, а не один.
Но в этом случае надежность и масштабируемость гораздо важнее скорости.
G>>>>Например ты делаешь приложение, которое делает graph layout — довольно сложные алгоритмы. Как ты думаешь что больше приглянется пользователям: молчаливый расчет всего за 10 сек потом отображение результата, или рисование узлов графа по мере вычисления позиций в течение 15 секунд? G>>>>100% пользователей предпочтут второе, хотя реально оно в 1,5 раз медленнее. EP>>>Пользователи предпочтут рисование по мере вычисления за пол-секунды G>>Увы, 10 сек это максимум что можно выжать, даже при экстремальной оптимизации. EP>Это разговор о конях в вакууме. Я так полагаю ты что-то там пытался оптимизировать, и где-то получилось 10 сек — и из этого ты делаешь вывод что это максимум?
Я уже приводил пример про VC и C++Builder. Быстрее было там где циферки бежали, а не там где быстрее по секундомеру.
Быстродействие с точки зрения пользователя совсем не то, о чем думают программисты C++.
EP>>>Ты вроде как толком не ответил, что не так с продолжениями в C++ G>>то что их просто нет, а если сделать, то бестолку. Ибо комбинировать продолжения с передачей данных будет сложно, придется париться с освобождением памяти. Да и тупо может продолжение не прийти. EP>Почему сложно? Почему парится с освобождением памяти? Куда продолжение может не прийти?
Давай так: http://rsdn.ru/forum/philosophy/5208679?tree=tree
тут пример кода, повтори его на C++, даже считая что есть годная библиотека для асинхронных HTTP вызовов и кто-нибудь смаршалит вызов в UI.
G>>Еще раз: продолжения+детерминированная финализация. Вместе, а не по-отдельности. В общем случае нельзя придумать способ гарантированной очистки памяти. Продолжение может просто не вызваться и будет держать ссылку на замыкание. EP>Давай конкретный пример.
class A
{
int x;
}
Func<int> GetFunc()
{
var closure = new A { x = 0 };
return () => closure.x++;
}
Перепиши его на C++, не изменяя семантики.
1) Чтобы closure не был виден вне GetFunc
2) Чтобы closure был освобожден когда станет недостижимым.
G>>>>Самое важное тут: как ты будешь получать этот массив и как обрабатывать. Если у тебя обработка ограниченного количества элементов за раз, то может вообще нет смысла держать в памяти все 32М, а читать с диска, на лету обрабатывать и выводить. EP>>>Нет, каждый элемент нужно обрабатывать много раз. Причём такие элементы будут хранится не только в массиве — это общий пример на простой абстракции в виде группировки элементов G>>Ниче не понял, приведи пример. EP>Есть группа логически связанных данных Element. Приложению нужны массивы/деки/мэпы Element'ов.
Пользователю не нужны они все. Что пользователю нужно?
G>>>>А зачем? Цель не оптимизация сама по себе, цель — чтобы программа работала достаточно быстро. EP>>>А я и не говорил что оптимизация это самоцель — действительно, если тебе нужно обрабатывать 90 байтиков в секунду, то можешь хоть visual basic взять G>>Среднее десктопное приложение обрабатывает и того меньше. G>>Ты сам доказываешь что C++ не нужен и это совсем не мейнстрим. EP>Где я это доказывал?
Да почти везде
EP>Там где нужна производительность — у C++ пока практически нет конкурентов, там где не нужна — можно использовать либо C++, либо что-то другое — зависит от конкретной задачи
Неуловимого джо тоже поймать никто не может, потому что нафиг никому не нужно.
А там где C++ сидит плотно, то скорее всего по историческим причинам.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
G>>Чтобы ты лучше понимал что происходит, распишу по-русски как оно работает. Предположим что это десктопное приложение. G>>1) вызывается handler G>>2) делается запрос на сервер, метод сразу же завершается и уходит а ожидание сообщений или делает полезную работу G>>3) Когда приходит заголовок ответа вызов хендлера маршалится в UI поток через цикл обработки сообщений G>>4) Когда в UI потоке находится время обработать, он проверяет успешность вызова и запускает асинхронное чтение данных ответа и завершает вызов. G>>5) когда весь ответ прочитан вызов хендлера снова маршалится в UI поток G>>6) Кода в UI потоке находится время, он добавляет текст ответа в TextBox G>>Такая архитектура позволяет делать очень много подобной "работы", вообще без создания потоков, при этом ни на долю секунды не потеряв отзывчивость интерфейса. G>>Давай, детка, сделай это на C++.
EP>Я смотрю в этом топике у радикальных C#-стов мода на годовалый await и хамство — это профессиональное?
Где ты хамство увидел? Тебе еще никто не хамил.
Мода на await как раз потому что он маленький и очень мощный. Можно написать пример в 3 строки, который другие языки не осилят в 100 строк.
EP>"Чтобы ты лучше понял", C++ код приведённый выше именно это и делает, ну разве кроме EnsureSuccessStatusCode и второго await'а которых не было в исходном запросе
"Именно это" это что? Как он маршалит в UI? Как он делает аснихронные вызовы?
Ну и код background в студию. В нем скрыто самое интересное.
.
Я наоборот пришел к тому что лучше использовать чуть большую словесность и всячески избегать экзотические и "крутые с точки зрения реальных пацанов" конструкции.
