E>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.
Давайте все-таки на вы, если это не противоречит Вашим религиозным убеждениям.
Я назову две — web-программиование (все) и внутренняя автоматизация (вся). Осмелюсь утверждать, что в России другими видами программирования можно (почти) пренебречь.
Это не значит, что их нет, что они не имеют права на существование, что они в чем-то хуже. Просто их меньше.
Забавно, но сам я в данный момент занимаюсь другой областью, классифицировать которую затрудняюсь.
Однако — места для с++ ни в моей работе, ни в работе моих коллег почти нет. А знакомых коллег у меня пара сотен наберется... это вроде как немало?
И в каждой из контор, с которыми я имел дело за последний год (с десяток), как в маленьких так и в очень крупных, идет процесс перевода разработок на .net.
Кроме тех, которые давно сидят на Java.
Здравствуйте, Kluev, Вы писали:
K>И что теперь? Меня мало беспокоит число пользователей языка, а больше интерсуют возможности и удобство.
Именно! А меня вот больше интересует финансовое благополучие моей фирмы. Которое, к слову, в немалой степени зависит от дальновидности принятых мною решений.
K>Так же нелепо смотрятся и деятели которые говорят что java/net смогут заменить С++ K>Есть целое море задач для которых лучше чем С++ (пока) не найти.
Море? Да ну? А может все-таки болото?
Шучу-шучу.
Просто лично я говорю не о тотальном уничтожении с++, а о постепенном, но неминуемом выдавливании его из массового использования.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Это ваш опыт. Не пытайтесь его обобщать в категоричной форме на всех.
Нет, не мой. Это опыт трех компаний, в которых я работал (одна — очень крупная) и нескольких, делами которых я интересовался.
Это позволяет мне делать некоторые обобщающие выводы. А про "на всех" пусть остается на Вашей совести.
>> И за долгие и многочисленные часы нашего общения на эту тему мне так и не удалось довести до его сознания простую мысль — он в меньшинстве и распространять свой опыт на окружающих автоматически — совершенно некорректно.
ПК>Зря вы не применяете этого же подхода к себе.
И опять не угадано ни одной буквы! То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.
Колега, не нужно меня убеждать в том, что на с++ можно писать работоспособный код. Я этим занимался на протяжении немалого количества лет и даже учил этому других.
Просто делать то же самое с помощью .net заметно проще, да и порог вхождения "в клуб" заметно ниже.
Здравствуйте, Kluev, Вы писали:
K>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется.
Ну и что? K>В NET нельзя сделать массив частью аггрегата, как в С++: K>
K>struct Triangle
K>{
K> Node *nodes[3];
K>};
K>
А зачем указатели? Это оверхед. K>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни. K>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15. K>В С++ общее число обьектов: 200 тысяч. K>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
Не понял расчеты, ну да ладно.
Поскольку node — структура(а я надеюсь от него наследоваться не надо), то в дотнет хранение массива по чтению не сильно отличается от сишного. Так что массив будет аналогичной конструкцией. K>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье: K>
K>class Triangle
K>{
K> public Node A, B, C; // вместо массива переменные
K>}
K>
K>Но это уже буллшит какой-то.
Ничего криминального не вижу. Это номальный учет особенностей среды. K>В треугольнике, например, нужен именно массив, который для удобства еще и закольцовывается: K>
K>Node* node_at( int idx )
K>{
K> static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K> return nodes[imap[idx+2]]; // транслируем колецевой индекс в обычный
K>}
K>// юзается очень удобно, пример вычисление всех углов:
K>void angles(Triangle &t)
K>{
K> double angs[3];
K> for ( int i = 0; i < 3; i++ )
K> angs[i] = angle( t.node_at(i-1), t.node_at(i), t.node_at(i+1) );
K>}
K>
Легко делается аналогично. K>И это элементарные вещи широко используемыые в повседневной жизни. В NET на таких простых вещах имеешь либо оверхед либо гемморой, а чаще и то и другое вместе взятое.
Нет, не в моей повседневной жизни. Просто в С++ значительно большее поле для игры с памятью. Но приведенный пример показательным не назовешь.
С уважением, Gleb.
ЗЫ. А все таки зафигом там указатели.
Здравствуйте, Kluev, Вы писали:
K>>>Для примера достаточно одной таблетки — простой класс треугольник: K>>>
K>>>class CSharpTriangle
K>>>{
K>>> public Node[] nodes = new Node[3]; // все приехали, можете закрывать свою лавочку
K>>>}
K>>>
А что в этом такого ??? Я так понимаю что вы подумали при строчке "Node[] nodes = new Node[3];" создаются 3 объекта Node в памяти ? Ну так вот, это совсем не так.
Этот класс почти аналогичен вашему: K>
K>struct Triangle
K>{
K> Node *nodes[3];
K>};
K>
K>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни. K>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15. K>В С++ общее число обьектов: 200 тысяч. K>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
ничего не понятно...
K>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье: K>
K>class Triangle
K>{
K> public Node A, B, C; // вместо массива переменные
K>}
K>
K>Но это уже буллшит какой-то. K>В треугольнике, например, нужен именно массив, который для удобства еще и закольцовывается: K>
K>Node* node_at( int idx )
K>{
K> static const int imap[] = { 1, 2, 0, 1, 2, 0, 1 };
K> return nodes[imap[idx+2]]; // транслируем колецевой индекс в обычный
K>}
K>// юзается очень удобно, пример вычисление всех углов:
K>void angles(Triangle &t)
K>{
K> double angs[3];
K> for ( int i = 0; i < 3; i++ )
K> angs[i] = angle( t.node_at(i-1), t.node_at(i), t.node_at(i+1) );
K>}
K>
Тоже самое легко можно на шарпе сделать
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, mrozov, Вы писали:
E>>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.
M>Давайте все-таки на вы, если это не противоречит Вашим религиозным убеждениям.
Ok.
M>Я назову две — web-программиование (все) и внутренняя автоматизация (вся). Осмелюсь утверждать, что в России другими видами программирования можно (почти) пренебречь.
M>Это не значит, что их нет, что они не имеют права на существование, что они в чем-то хуже. Просто их меньше.
И?
Тем, кто работает в этих областях какой смысл обращать внимание на web-программирование и внутреннюю автоматизацию?
Я, например, занимался АСУТП и системами реального времени. Притягивать туда за уши .Net и Java? Есть и в этих областях место для таких языков, для предоставления того же web-интерфейса. Но это не mission-critial код.
Сейчас я связан с телекоммуникационными задачами. С++ здесь себя нормально чувствует. А требования к софту очень серьезные, поэтому дешевле набирать или готовить хороших специалистов, которые в состоянии будут программировать на C++, чем переходить на Java/.Net в надежде на более простой подбор персонала.
M>Это просто объективный процесс.
Хорошая фраза есть в начале этой темы:
просто новые технологии с рынка не уходят — они его расширяют
Веб-программирование -- это интересно, конечно, актуально на данный момент и здесь нет тотального доминирования Java/.Net -- масса сайтов крутится на PHP, Python, Perl и даже Ruby. Но ведь Веб-программирование совершенно не убило задачи АСУТП, CAD или встраиваемых систем. Просто появился новый рынок, который сейчас всасывает кучу ресурсов. Какое-то время так и будет продолжаться. И если кто-то будет кричать: "Создавайте веб-приложения на C++", то это действительно будет смахивать на авантюру (хотя никто не исключает возможности появления супер-пупер фрейморка на C++ для разработки веб-приложений -- учитывая низкие требования к ресурсам C++ программ это может стать неприятным сюрпризом для JSP и ASP решений ). Однако, лозунг "Создавайте распределенные приложения на C++" совсем не такой дикий, каким может показаться. И есть масса предметных областей, где этот лозунг будет очень актуальным.
Так что, в областях, где C++ был, выдавить его будет очень не просто. Возьмите, к примеру Smalltalk или Prolog -- ну очень экзотические языки, тем не менее применяются и продукты на их основе никто не бросается переделывать на других языках. Новые области активно используют .Net и Java. Однако:
— во-первых, сейчас виден возрастающий интерес к динамическим языкам, т.к. Python, тот же Smalltalk, Ruby и др. Возможно, в скором времени это будет новый мейнстрим, который создаст новые рыночные ниши и будет доминировать в них над C++/C#/Java вместе взятыми;
— во-вторых, для меня совсем не факт, что C++ утратит актуальность и не сможет найти себе новое применение. Рост гигагерцев замедляется, развиваются разные умные устроства, у которых производительность, все же, не самая большая. Поэтому и быстрые, экономичные приложения могут в ближайшее время вернуть себе заслуженное внимание. Qtopia, написанная на C++, например, совсем не плохо себя чувствует.
Так что реплики "Делайте прикладные проекты на C++", имхо, весьма умесны. Просто нужно указывать, к чему именно они должны прикладываться.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kluev, Вы писали:
K>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:
struct CSharpTriangle
{
public fixed Node nodes[3];
}
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Kluev, Вы писали:
K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. GZ>Ну и что?
K>>В NET нельзя сделать массив частью аггрегата, как в С++: K>>
Один узел разделяется м-ду несколькими треугольниками. А из треугольников делается сетка. Поэтому и указатели.
Массив из трех указателей, на Node. Оверхед равен нулю.
K>>В итоге имеем оверхед на ровном месте. В качестве примера цифры из реальной жизни. K>>В программе ~150000 обьектов в которых 8 фикс.массивов на борту, ~50000 в которых 15. K>>В С++ общее число обьектов: 200 тысяч. K>>В .NETе 150к + 150к*8 + 50к + 50к*15 = 2,150,000
GZ>Не понял расчеты, ну да ладно.
Суть в том что сишные-фиксированные массивы не аллоцируются сами по себе в хипе, а входят в состав обьекта, и все распределяется одним махом. Дотнетовские массивы должны распределится отдельно, т.е. один аллок на обьект и + несколько на массивы. В итоге в С++ будет распределено 200к обьектов, а в NET-e почти в 11 раз больше. Чувствуешь разницу? Или память это не ресурс? Фактически GC прийдется регулярно обрабатывать больше 2 млн обьектов. И это только часть от big picture.
K>>Если смысл обсуждать дальше? Конечно можно возразить (на примере того же треугольника) делай вот так и будет щастье: K>>
K>>class Triangle
K>>{
K>> public Node A, B, C; // вместо массива переменные
K>>}
K>>
K>>Но это уже буллшит какой-то.
GZ>Ничего криминального не вижу. Это номальный учет особенностей среды.
Ага, а обращение по индексам будем делать так?
Node node_at( int idx )
{
switch ( idx )
{
case 0: return A;
case 1: return B;
// понеслась
}
}
И не кажется ли тебе такое программирование гемором?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Kluev, Вы писали:
K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:
AVK>
AVK>struct CSharpTriangle
AVK>{
AVK> public fixed Node nodes[3];
AVK>}
AVK>
В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы.
Здравствуйте, Kluev, Вы писали:
K>Один узел разделяется м-ду несколькими треугольниками. А из треугольников делается сетка. Поэтому и указатели. K>Массив из трех указателей, на Node. Оверхед равен нулю.
Понятно.
K>Суть в том что сишные-фиксированные массивы не аллоцируются сами по себе в хипе, а входят в состав обьекта, и все распределяется одним махом. Дотнетовские массивы должны распределится отдельно, т.е. один аллок на обьект и + несколько на массивы. В итоге в С++ будет распределено 200к обьектов, а в NET-e почти в 11 раз больше. Чувствуешь разницу? Или память это не ресурс? Фактически GC прийдется регулярно обрабатывать больше 2 млн обьектов. И это только часть от big picture.
Честно говоря если бы данная задача стояла бы у меня под dotnet, я бы делал совсем по другому. Инстанцировалось бы только на момент операции, трианглы были immutable, и легко собирались бы в нулевом поколении. Конечно со стороны все кажется легко и решение за пять секунд — очень субьективно.
K>Ага, а обращение по индексам будем делать так? K>
K>Node node_at( int idx )
K>{
K> switch ( idx )
K> {
K> case 0: return A;
K> case 1: return B;
K> // понеслась
K> }
K>}
K>
K>И не кажется ли тебе такое программирование гемором?
Зачем, лучше так
Здравствуйте, mrozov, Вы писали:
M>В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы. M>
PS. В следующий раз предлагаю общаться на "ты" -- так проще.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Честно говоря если бы данная задача стояла бы у меня под dotnet, я бы делал совсем по другому. Инстанцировалось бы только на момент операции, трианглы были immutable, и легко собирались бы в нулевом поколении. Конечно со стороны все кажется легко и решение за пять секунд — очень субьективно.
В CAD-ах трианглы используются как правило в двух случаях.
1) для отрисовки поверхностей. инстанцировать во время отрисовки, проще сразу застрелится
2) для расчета. Т.е. создается расчетная сетка и модифицируется п омере надобности. Т.е. из песни слова не выкинешь.
Видишь ли, просто перебрать узлы типа foreach, таких задач нет вообще.
Зато очень часто надо получать сторону: node(i); node(i+1);
Или угол: node(i-1); node(i); node(i+1);
Или просто получить соседей. Тогда по указателю находим индекс и дальше node(idx-1); node(idx+1)
Плюс еще в С++ очень удобно интрузивные списки реализуются (фактически я мой основной контейнер. юзаю чаще чем vector). Это в шарпе не сделаешь (без гемора), т.к. средств таких в языке нет.
Про шаблоны для всякой геометрии типа Point<3,double> и т.п. я уже вообще молчу. тут альтернатив плюсам нет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Спорить о вкусе устриц, как это не печально, можно только с теми, кто их ел.
Ну почему же? Спорить вообще можно с кем угодно и о чем угодно. Доказано интернетом
К примеру, недавно один комрад, лично со мной не знакомый, пытался меня убедить в том, что мне не больше 20 лет. Приводил исключительно интерестные аргументы, надо заметить.
Честно говоря при нехватке памяти Dotnet ведет себя "мягко говоря" — не очень. Ему очень нравится когда есть излишек памяти. Поэтому задачи данного типа не для него.
mrozov,
> То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.
Вы совершенно зря юродствуете. "Бум web-программирования" нас затронул по полной программе: почти половина команды у нас пишет на C# именно под web. Но web-программирование, покрывающее в нашем случае часть use cases, совершенно не отменяет необходимости в клиентских программах, устанавливаемых на компьютеры пользователей, равно как и в серверных программах. И эти разновидности программ мы пишем на C++. Да и в "большом" web-программировании далеко не все так однозначно: примерами тому могут служить Google и Amazon, значительная часть кода которых -- C++.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен