Здравствуйте, eao197, Вы писали:


E>Давай так: перечисли те прикладные области, которые ты знаешь. Так будет проще оценивать перспективность языка.

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

Я назову две — web-программиование (все) и внутренняя автоматизация (вся). Осмелюсь утверждать, что в России другими видами программирования можно (почти) пренебречь.

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

Однако — места для с++ ни в моей работе, ни в работе моих коллег почти нет. А знакомых коллег у меня пара сотен наберется... это вроде как немало?
И в каждой из контор, с которыми я имел дело за последний год (с десяток), как в маленьких так и в очень крупных, идет процесс перевода разработок на .net.
Кроме тех, которые давно сидят на Java.

Это просто объективный процесс.

Здравствуйте, Kluev, Вы писали:

K>И что теперь? Меня мало беспокоит число пользователей языка, а больше интерсуют возможности и удобство.

Именно! А меня вот больше интересует финансовое благополучие моей фирмы. Которое, к слову, в немалой степени зависит от дальновидности принятых мною решений.

K>Так же нелепо смотрятся и деятели которые говорят что java/net смогут заменить С++
K>Есть целое море задач для которых лучше чем С++ (пока) не найти.

Море? Да ну? А может все-таки болото?
Шучу-шучу.

Просто лично я говорю не о тотальном уничтожении с++, а о постепенном, но неминуемом выдавливании его из массового использования.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это ваш опыт. Не пытайтесь его обобщать в категоричной форме на всех.

Нет, не мой. Это опыт трех компаний, в которых я работал (одна — очень крупная) и нескольких, делами которых я интересовался.
Это позволяет мне делать некоторые обобщающие выводы. А про "на всех" пусть остается на Вашей совести.

>> И за долгие и многочисленные часы нашего общения на эту тему мне так и не удалось довести до его сознания простую мысль — он в меньшинстве и распространять свой опыт на окружающих автоматически — совершенно некорректно.

ПК>Зря вы не применяете этого же подхода к себе.

И опять не угадано ни одной буквы! То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.

Здравствуйте, Cyberax, Вы писали:

Колега, не нужно меня убеждать в том, что на с++ можно писать работоспособный код. Я этим занимался на протяжении немалого количества лет и даже учил этому других.
Просто делать то же самое с помощью .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>

Тоже самое легко можно на шарпе сделать

Здравствуйте, 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++", имхо, весьма умесны. Просто нужно указывать, к чему именно они должны прикладываться.

Здравствуйте, Kluev, Вы писали:

K>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется. В NET нельзя сделать массив частью аггрегата, как в С++:

struct CSharpTriangle
{
  public fixed Node nodes[3];
}

Здравствуйте, mrozov, Вы писали:

M>По-моему — это факт.

Спорить о вкусе устриц, как это не печально, можно только с теми, кто их ел.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Kluev, Вы писали:

K>>Дотнетовский массив — это ссылочный тип который в GC-хипе аллоцируется.
GZ>Ну и что?

K>>В NET нельзя сделать массив частью аггрегата, как в С++:
K>>

K>>struct Triangle
K>>{
K>>   Node  *nodes[3];
K>>};
K>>

GZ>А зачем указатели? Это оверхед.

Один узел разделяется м-ду несколькими треугольниками. А из треугольников делается сетка. Поэтому и указатели.
Массив из трех указателей, на 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>

Это откуда дровишки? В VS2003 не работает

Здравствуйте, eao197,

В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы.

Здравствуйте, 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>И не кажется ли тебе такое программирование гемором?
Зачем, лучше так

Node next_node()
{
  yeald return A;
    yeald return B;
    yeald return C;
}

В сях такого нет.
С уважением, Gleb.

Здравствуйте, mrozov, Вы писали:

M>В общем-то, ни с чем из сказанного Вами я спорить не собираюсь. В смысле, я не совсем согласен, но придираться к словам не буду — в целом Вы абсолютно правы.
M>



PS. В следующий раз предлагаю общаться на "ты" -- так проще.

E>PS. В следующий раз предлагаю общаться на "ты" -- так проще.

Без проблем. в следующий-то раз мы будем уже старыми знакомыми

Здравствуйте, Kluev, Вы писали:

K>Это откуда дровишки?

Это 2 фреймворк.

Здравствуйте, GlebZ, Вы писали:

GZ>Честно говоря если бы данная задача стояла бы у меня под dotnet, я бы делал совсем по другому. Инстанцировалось бы только на момент операции, трианглы были immutable, и легко собирались бы в нулевом поколении. Конечно со стороны все кажется легко и решение за пять секунд — очень субьективно.
В CAD-ах трианглы используются как правило в двух случаях.
1) для отрисовки поверхностей. инстанцировать во время отрисовки, проще сразу застрелится
2) для расчета. Т.е. создается расчетная сетка и модифицируется п омере надобности. Т.е. из песни слова не выкинешь.


GZ>Зачем, лучше так
GZ>

GZ>Node next_node()
GZ>{
GZ>  yeald return A;
GZ>    yeald return B;
GZ>    yeald return C;
GZ>}
GZ>

GZ>
GZ> В сях такого нет.
GZ>С уважением, Gleb.

Видишь ли, просто перебрать узлы типа 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 лет. Приводил исключительно интерестные аргументы, надо заметить.

Здравствуйте, Kluev, Вы писали:

Честно говоря при нехватке памяти Dotnet ведет себя "мягко говоря" — не очень. Ему очень нравится когда есть излишек памяти. Поэтому задачи данного типа не для него.

С уважением, Gleb.

mrozov,

> То, что я в меньшинстве со своим пониманием опасности вызова CreateThread, я-то как раз прекрасно понимаю. А вот Вы в своей башне из слоновой кости бум web-программирования, похоже, благополучно проспали. Мир изменился.

Вы совершенно зря юродствуете. "Бум web-программирования" нас затронул по полной программе: почти половина команды у нас пишет на C# именно под web. Но web-программирование, покрывающее в нашем случае часть use cases, совершенно не отменяет необходимости в клиентских программах, устанавливаемых на компьютеры пользователей, равно как и в серверных программах. И эти разновидности программ мы пишем на C++. Да и в "большом" web-программировании далеко не все так однозначно: примерами тому могут служить Google и Amazon, значительная часть кода которых -- C++.