с таким запредельным количеством библиотек на все случаи жизни С++ не умрёт уже никогда. уж я как сильно привык на шарпе писать, и то иногда выбираю плюсы. здравый смысл велит выбирать именно плюсы когда нужна реальная скорость выполнения программы. хотя с точки зрения удобства шарп конечно лучше . и конечно неприятно, когда подонки из M$ задают тренды, на чём писать , какие платформы и фреймворки использовать. вчера были винформы, сегодня wpf, потом сильверлайт какой-то даром никому не нужный... с позиции здорового минимализма и консервативности java рвёт шарп в лохмотья.
Это C++11x уже. На нём код чуть по чище. И да, пример совсем не то делает на данный момент. Ленивости нету же. Сделай аналог yield из python\C#, тогда будет близко.
filtered_list.push_back(e); - вот это убивает всю соль моего примера.
Для простоты, сделай аналог:
[code]
static IEnumerable<T> myFilter(int count, IEnumerable<T> input_seq) {
foreach(var e in input_seq)
if (e.count > count)
yield return e;
}
[/code]
Это будет аналог того LINQ запроса. Пояснения, что из себя будет представлять IEnumerable<T> нужны?
WinForms закапывают. В WPF layouts есть, причём там есть аналог QML, только его синтаксис выполнен в XAML (эдакий XML). Причём, на мой вкус, XAML получился получше QML, но тут сказывается моя нелюбовь к CSS.
Она там используется за счет ненадобности экономить на мощности компьютеров
никто никогда ничего не делает за счёт ненадобности. особенно банки
если мощности ограничены, то при прочих равных java будет проигрывать
проигрывать чему именно? вот, например, ZeroC ICE. он существенно обходит TAO по производительности, но имеет биндинги к Java и C#. в случае огрниченных ресурсов чисто плюсовое приложение с TAO проиграет чисто Java- (или C#-) приложению с ICE
а в случае, если с ICE будет работать и то, и то приложение, разница будет несущественна. потому как в данной области язык будет боттлнеком в последнюю очередь
Я с вами полностью согласен. Ну кроме того, что C++ не умрёт никогда, т.к. всё умирает, это лишь вопрос времени и появления ЯП с сопоставимой скоростью исполнения, и вменяемым синтаксисом и семантикой, ведь когда-нибудь людям надоест кушать кактус, верно? По поводу либ: основные либы либо перепишут, либо покроют биндингами. А со временем старые либы просто перепишут, либо выловят подавляющее большинство багов. Но хвост плюсовых либ будет тянуться очень долго, это бесспорно.
А монополия МС продлиться ровно до того момента, пока ПК жив в традиционном понимании этого слова. Ну а мы все видим, что ПК сдают позиции, так что через годик или два будет понятно, выживет ли МС или же нет. Но это уже оффтоп.
По поводу Java я ничего сказать не могу, не знаю её толком.
Знаю один проект UBS, пишущийся на .Net, в рамках которого UBS (в роли мышей) ест .Net (в роли кактуса) плача и колясь. Потому рискну предположить, что там политика играет роль большую чем техническая сторона вопроса.
Например потому, что выполнение арифметических операций, переходов и копирования данных в памяти в интерпретируемых и байт-кодовых языках происходит медленнее, чем в компилируемых.
Конечно C++11, ведь C++98 немного отстал от жизни :)
Сделай аналог yield из python\C#, тогда будет близко.
В C++ yield нету. Однако, не знаю реальных задач, которые нельзя сделать без yield (тем более, что в C#, насколько я понял, он используется только для реализации итераторов - это уже совершенно не тот универсальный yield, что в других языках).
static IEnumerable<T> myFilter(int count, IEnumerable<T> input_seq) { foreach(var e in input_seq) if (e.count > count) yield return e; }
Ну это да - подлиннее на C++ получится (но yield тут реализовывать не нужно - в C++ итераторы принято по-другому делать).
имутабелность строк, UCS-2 как внутренняя кодировка - в следствии чего излишнее до неприличия потребление памяти при обработке текстовых данных
политика играет роль
и каким образом политика определила выбор технологий?
когда менеджер (не технарь), отвечающий за проект навязывает команде технологию без права выбора по причине бухал с/получил откат от представителя вендора - это политика, а не выбор более подходящей технологии, хотя по каким причинам выбор был такой в данном случае я не знаю
выполнение арифметических операций, переходов и копирования данных в памяти в интерпретируемых и байт-кодовых языках происходит медленнее, чем в компилируемых
с какой радости? ну вот можешь конкретно расписать, какие лишние действия в случае выполнения (любой) арифметической операции должны присутствовать в случае байткодового языка?
имутабелность строк, UCS-2 как внутренняя кодировка
печально, но надо было предусмотреть
менеджер (не технарь), отвечающий за проект навязывает команде технологию без права выбора по причине бухал с/получил откат
не принимаются в крупных проектах подобные решения одним человеком и в один день. в принципе, никогда. сколько бы оный менеджер ни бухал, и сколько бы ему ни откатили
тем более, что в C#, насколько я понял, он используется только для реализации итераторов - это уже совершенно не тот универсальный yield, что в других языках
Хм, с этого места по подробней. Возможно я чего-то не знаю. Какие задачи можно решать с помощью yield окромя итерирования?
но yield тут реализовывать не нужно - в C++ итераторы принято по-другому делать
Из плюсового кода я видел как это делается в STL. Как по мне - выглядит ужасно.
Вот я к этому и подвожу. Есть круг задач, которые в современных языках решают с помощью ввода сахара упрощающего написание и восприятие код (те же C#, F#, Scala, которые читай вводят паттерны в виде сахара), C++ тоже идёт по этому пути (C++11), но медленно как-то (хотя каюсь, C++11 не смотрел ещё толком).
Проблема ещё и в том, что C++ тянет за собой хвост совместимости со старыми стандартами и из-за этого людям приходится мириться с невозможностью кардинально поменять синтаксис и возложить на компилятор кучу рутинной работы (тут можно посмотреть на python и веселье со 2 и 3 ветками) не сломав совместимость.
Они там в комитете слов боятся. Т.е. вместо того, чтобы кейворд сделать и дать уже программерам воспользоваться своими тулзами для замены названий переменных, они штампуют «= 0» и прочие группы знаков клинописи :}
+1, пробовал Ди, писал на Джаве, на Питоне, пробовал Си-шарп, писал коммерч код на обджектив-си, в итоге рассматриваю для хобби-проектов ФриПаскаль либо Джаву =) хоть на работе пишу на плюсах
Он не осилил кроссплатформу и прямолинейный, но переносимый код в рамках стандарта - требуется некоторая дисциплина, чтоб воздерживаться от срезания углов, трюков, новомодных фич языка с неустоявшейся реализацией и расширений конкретного компилятора - в общем, некоторые свои привычки к «роскоши удобств» выдают за объективные трудности ;)
Написал я тут простенький интерпретатор байт кода, который содержит операции сложения, умножения, сравнения и перехода
И написал для него программу расчета 6!.
программа запускалась 1000000 раз
Суммарное время 2.234 секунды
Точно такая же программа расчета 6! 1000000 раз, но скомпилированная, работает за 0.053 секунды.
вот интерпретатор
#include <stdio.h>
typedef enum { stop = 0, add = 1, mul = 2, cmp = 3, jmp = 4, mov = 5, print = 6, assign = 7, ej = 8, lj=9, gj=10} Cmd;
#define N 100
#define NR 10
Cmd code[N]={assign, assign, assign, assign, cmp, ej, mul, add, jmp, stop};
int ic = 0;
int data[N]={3,0, 2,-1, 0,10, 1,1, 0,3, 9,20, 0,1,1, 0,2,0, 4,8 };
int id = 0;
int regs[NR];
int sr[10];
#define numgo 1000000
int main(void)
{
int ng;
int go;
for (ng = 0; ng < numgo; ng++)
{
go = 1;
ic = id = 0;
while (go == 1)
{
int i, j, k;
Cmd c = code[ic];
ic++;
switch (c)
{
case stop:
go = 0;
break;
case add:
i = data[id];
j = data[id+1];
k = data[id+2];
id += 3;
regs[k] = regs[i] + regs[j];
break;
case mul:
i = data[id];
j = data[id+1];
k = data[id+2];
id += 3;
regs[k] = regs[i] * regs[j];
break;
case cmp:
i = data[id];
j = data[id+1];
if (regs[i] < regs[j])
sr[0] = -1;
else if (regs[i] == regs[j])
sr[0] = 0;
else
sr[0] = 1;
id += 2;
break;
case jmp:
i = data[id];
j = data[id+1];
ic = i;
id = j;
break;
case mov:
i = data[id];
j = data[id+1];
regs [i] = regs[j];
id += 2;
break;
case print:
for (i = 0; i < NR; i++)
printf("%i = %i\n", i, regs[i]);
break;
case assign:
i = data[id];
j = data[id+1];
regs[i] = j;
id += 2;
break;
case ej:
i = data[id];
j = data[id+1];
if (sr[0] == 0)
{
ic = i;
id = j;
}
else
id += 2;
break;
case lj:
i = data[id];
j = data[id+1];
if (sr[0] == -1)
{
ic = i;
id = j;
}
else
id += 2;
break;
case gj:
i = data[id];
j = data[id+1];
if (sr[0] == 1)
{
ic = i;
id = j;
}
else
id += 2;
break;
}
}
}
return 0;
}
и вот компилируемая программа:
#include <stdio.h>
#define numgo 1000000
int main(void)
{
int ng;
int a, b, s;
for (ng = 0; ng < numgo; ng++)
{
a = 6;
b = -1;
s = 1;
loop:
if (a == 0)
goto endp;
s = s*a;
a = a+b;
goto loop;
endp: ;
}
return 0;
}
Хм, с этого места по подробней. Возможно я чего-то не знаю. Какие задачи можно решать с помощью yield окромя итерирования?
Универсальный yield в других языках предлагает возможность вернуть результат из функции, а когда функция будет вызвана еще раз, она будет продолжена с того самого места, с которого был сделан yield. Применять это можно не только в итераторах :)
Видел когда-то в инете велосипед на JS (браузерозависимый, yield в JS умеет только Mozilla), где yield использовался для создания фейковой многопоточности :-D
Из плюсового кода я видел как это делается в STL. Как по мне - выглядит ужасно.
Многословно в плане написания своих контейнеров, но идея-то правильна :) Для уменьшения этой самой многословности язык модифицировать не нужно - только немножечко подпилить стандартную библиотеку.
Есть круг задач, которые в современных языках решают с помощью ввода сахара упрощающего написание и восприятие код
В C++11 в этом плане сделано более, чем достаточно (запилили всё, чего мне раньше в C++ не хватало, кроме блока finally). Чего именно там не хватает, что относится к языку, а не библиотеке?
Проблема ещё и в том, что C++ тянет за собой хвост совместимости со старыми стандартами и из-за этого людям приходится мириться с невозможностью кардинально поменять синтаксис
Ну это да, порвать с прошлым нельзя. Но оттуда вытекают только один реальный недостаток: потенциальная возможность отстрелить себе ногу, смешав сишное наследие с нормальным плюсовым кодом.
и из-за этого людям приходится мириться с невозможностью кардинально поменять синтаксис
Что ты называешь промышленным кодом? Система автоматической классификации фоток с микроскопа рак/не рак? Самое серьезное применение шарпа, а именно сингулярити профейлилось.
джавой от MS C# был во времена .Net 1.0. ты малость отстал от жизни
Кстати, что там со стандартами на C#? Признаюсь, что гуглить даже не пытался. Как микромягкие скажут, так и будет? Не получится ли, что реализации станут самостоятельными ЯП?