Есть ли причина использовать C ++ вместо C, Perl, Python и т. Д.? [закрыто]

Как разработчик Linux (на стороне сервера), я не знаю, где и зачем использовать C ++.

Когда я иду на производительность, первым и последним выбором является C.

Когда «производительность» не является основной проблемой, такие языки программирования, как Perl и Python, будут хорошим выбором.

Почти все приложения с открытым исходным кодом, которые я знаю в этой области, были написаны на сценариях C, Perl, Python, Bash, AWK или даже PHP, но никто не использует C ++.

Я не обсуждаю другие области, такие как графический интерфейс или веб-приложения, я просто говорю о Linux, CLI и демонах.

Есть ли удовлетворительная причина использования C ++?

158 голосов | спросил 6 revs, 4 users 46%
Ehsan
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

19 ответов


297
  

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

И это, где вы должны делать резервную копию. Теперь я не могу, вообще , говорить для разработки сервера. Возможно, нет никаких веских оснований предпочитать C ++ над альтернативами.

Но, вообще говоря, причина использования C ++, а не других языков - это действительно производительность. Причиной этого является то, что C ++ предлагает средство абстракции, которое, в отличие от all , я знаю, no накладные расходы производительности во время выполнения.

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

Рассмотрим обычные абстракции: виртуальные функции, указатели функций и идиом PIMPL. Все они полагаются на косвенность, которая во время выполнения разрешена с помощью арифметики указателя. Другими словами, это приводит к затратам на производительность (как бы они ни были малы).

C ++, с другой стороны, предлагает механизм косвенности, который несет стоимость no (производительность): шаблоны. (Это преимущество выплачивается с (иногда большим) временем компиляции.)

Рассмотрим пример общей функции сортировки.

В C функция qsort принимает указатель на функцию, которая реализует логику, по которой элементы упорядочены относительно друг друга. Функция Java Arrays.sort поставляется в нескольких вариантах; один из них сортирует произвольные объекты и требует, чтобы объект Comparator передавался ему, который работает так же, как указатель функции в C qsort . Но есть еще несколько перегрузок для «естественных» типов Java. И каждый из них имеет собственную копию метода sort - ужасное дублирование кода.

Java иллюстрирует общую дихотомию здесь: либо у вас есть дублирование кода, либо на выполнение служебных программ.

В C ++ функция sort работает так же, как qsort в C, с одним небольшим, но фундаментальным различием: компаратор, который передается в функцию, является шаблон . Это означает, что его вызов может быть inlined . Для сравнения двух объектов нет косвенности. В плотной петле (как это имеет место здесь) это может существенно повлиять.

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

Теперь я not говорит, что C ++ априори более эффективен, чем C (или другие языки), и что он априори предлагает более высокую абстракцию. То, что он предлагает, - это абстракция, которая очень высока и невероятно дешева в то же время, так что вам часто не нужно выбирать между эффективным и многоразовым кодом.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
157

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

Меньше кода, не хватает времени на выполнение, больше безопасности.

Чем меньше кода мы пишем, тем лучше. Это быстро становится понятным для всех инженеров, которые стремятся к совершенству. Вы исправляете ошибку в одном месте, не так много - вы выражаете алгоритм один раз и повторно используете его во многих местах и ​​т. Д. У греков есть даже высказывание, прослеженное до древних спартанцев: «говорить что-то менее словами, значит что вы разумны в этом ». И факт в том, что при правильном использовании , C ++ позволяет вам выражать себя в гораздо меньшем количестве кода, чем C, без затрат времени на выполнение, будучи более безопасным (т.е. ловить больше ошибок при компиляции, время), чем C.

Вот упрощенный пример из моего средства визуализации : при интерполяции значений пикселей по линии сканирования треугольника. Я должен начать с координаты X x1 и достигнуть координаты X x2 (слева направо от треугольника). И через каждый шаг, через каждый пиксель, который я передаю, я должен интерполировать значения.

Когда я интерполирую окружающий свет, который достигает пикселя:

  typedef struct tagPixelDataAmbient {
      int x;
      float ambientLight;
  } PixelDataAmbient;

  ...
  //внутренний цикл
  currentPixel.ambientLight + = dv;
 

Когда я интерполирую цвет (называемый затенением «Gouraud», где «красный», «зеленый» и «синий» поля интерполируются значением шага на каждом пикселе):

  typedef struct tagPixelDataGouraud {
      int x;
      плавающий красный;
      плавающий зеленый;
      плавающий синий; //Цвет RGB, интерполированный на пиксель
  } PixelDataGouraud;

  ...
  //внутренний цикл
  currentPixel.red + = dred;
  currentPixel.green + = dgreen;
  currentPixel.blue + = dblue;
 

Когда я рисую в затенении «Фонг», я больше не интерполирую интенсивность (ambientLight) или цвет (красный /зеленый /синий) - я интерполирую нормальный вектор (nx, ny, nz) и на каждом шаге I необходимо пересчитать уравнение освещения, основанное на интерполированном нормальном векторе:

  typedef struct tagPixelDataPhong {
      int x;
      float nX;
      float nY;
      float nZ; //Нормальный вектор, интерполированный на пиксель
  } PixelDataPhong;

  ...
  //внутренний цикл
  currentPixel.nX + = dx;
  currentPixel.nY + = dy;
  currentPixel.nZ + = dz;
 

Теперь первый инстинкт программистов на C будет «чертовски, напишите три функции, которые будут интерполировать значения, и вызовите их в зависимости от установленного режима». Прежде всего, это означает, что у меня проблема типа: с чем я работаю? Мои пиксели PixelDataAmbient? PixelDataGouraud? PixelDataPhong? О, подождите, говорит эффективный программист С, используйте союз!

  typedef union tagSuperPixel {
      PixelDataAmbient a;
      PixelDataGouraud g;
      PixelDataPhong p;
  } SuperPixel;
 

.. и затем у вас есть функция ...

  RasterizeTriangleScanline (
      enum mode, //{ambient, gouraud, phong}
      SuperPixel ушел,
      SuperPixel справа)
  {
      int i, j;
      if (mode == ambient) {
          //обрабатываем пиксели как окружающие ...
          int steps = right.a.x - left.a.x;
          float dv = (right.a.ambientLight - left.a.ambientLight) /шаги;
          float currentIntensity = left.a.ambientLight;
          для (i = left.a.x; i <right.a.x; i ++) {
              WorkOnPixelAmbient (i, dv);
              currentIntensity + = DV;
          }
      } else if (mode == gouraud) {
          //обрабатывать пиксели как gouraud ...
          int steps = right.g.x - left.g.x;
          float dred = (right.g.red - left.g.red) /steps;
          float dgreen = (right.g.green - left.a.green) /шаги;
          float dblue = (right.g.blue - left.g.blue) /шаги;
          float currentRed = left.g.red;
          float currentGreen = left.g.green;
          float currentBlue = left.g.blue;
          для (j = left.g.x; i <right.g.x; j ++) {
              WorkOnPixelGouraud (j, currentRed, currentBlue, currentGreen);
              currentRed + = Дреда;
              currentGreen + = dgreen;
              currentBlue + = dblue;
          }
...
 

Считаете ли вы, что хаос скользит?

Прежде всего, одна опечатка - это все, что необходимо для разбивки моего кода, поскольку компилятор никогда не остановит меня в разделе «Gouraud» функции, чтобы фактически получить доступ к «.a». (окружающего) значения. Ошибка, не попавшая в систему типа C (то есть во время компиляции), означает ошибку, которая проявляется во время выполнения и требует отладки. Вы заметили, что я обращаюсь к left.a.green при расчете «dgreen»? Компилятор, конечно же, не сказал вам об этом.

Затем во всех случаях повторяется повторение цикла для , так как есть режимы рендеринга, мы продолжаем делать «right минус слева, разделенные шагами». Уродливый и подверженный ошибкам. Вы заметили, что я сравниваюиспользуя «i» в цикле Гуро, когда я должен был использовать «j»? Компилятор снова молчал.

Как насчет if /else /ladder для режимов? Что делать, если я добавлю новый режим рендеринга через три недели? Не буду ли я обрабатывать новый режим во всех «if mode ==» во всем моем коде?

Теперь сравните вышеупомянутое уродство с этим набором структур C ++ и функцией шаблона:

  struct CommonPixelData {
      int x;
  };
  struct AmbientPixelData: CommonPixelData {
      float ambientLight;
  };
  struct GouraudPixelData: CommonPixelData {
      плавающий красный;
      плавающий зеленый;
      плавающий синий; //Цвет RGB, интерполированный на пиксель
  };
  struct PhongPixelData: CommonPixelData {
      float nX;
      float nY;
      float nZ; //Нормальный вектор, интерполированный на пиксель
  };

  template <class PixelData>
  RasterizeTriangleScanline (
      PixelData ушел,
      PixelData)
  {
      PixelData интерполировано = слева;
      PixelData step = right;
      step - = left;
      step /= int (right.x - left.x); //разделить на пиксель
      for (int i = left.x; i <right.x; i ++) {
          WorkOnPixel & л; PixelData & GT; (интерполированное);
          интерполированный + = шаг;
      }
  }
 

Теперь посмотри на это. Мы больше не делаем суп типа union: у нас есть определенные типы для каждого режима. Они повторно используют свой общий материал (поле «x»), наследуя от базового класса ( CommonPixelData ). И шаблон делает компилятор CREATE (т. Е. Генерирует код) тремя различными функциями, которые мы написали бы на C, но в то же время очень строгими в отношении типов!

Наш цикл в шаблоне не может идти и обращаться к недопустимым полям - компилятор будет лаять, если мы это сделаем.

Шаблон выполняет общую работу (цикл, каждый раз увеличиваясь на «шаг»), и может сделать это таким образом, который просто НЕ МОЖЕТ вызывать ошибки времени выполнения. Интерполяция для каждого типа ( AmbientPixelData , GouraudPixelData , PhongPixelData ) выполняется с помощью оператора + = () , который мы будем добавьте в структуры, которые в основном диктуют , как каждый тип интерполируется.

И вы видите, что мы сделали с WorkOnPixel <T & gt ;? Мы хотим выполнять разные работы по типу? Мы просто называем специализацию шаблона:

  void WorkOnPixel <AmbientPixelData> (AmbientPixelData & amp; p)
{
    //используйте поле p.ambientLight
}


void WorkOnPixel <GouraudPixelData> (GouraudPixelData & amp; p)
{
    //используйте поля p.red/green/blue
}
 

То есть - функция вызова, определяется на основе типа. Во время компиляции!

Чтобы снова перефразировать его:

  1. мы минимизируем код (через шаблон), повторно используем общие части,
  2. мы не используем уродливые хаки, мы сохраняем строгую систему типов, чтобы компилятор мог всегда проверять нас.
  3. и лучше всего: ничто из того, что мы сделали, не имеет никакого воздействия во время работы. Этот код будет работать JUST так же быстро, как и эквивалентный код C - на самом деле, если код C использовал указатели функций для вызова различных версий WorkOnPixel , код C ++ будет FASTER, чем C, потому что компилятор встраивает специфический для типа WorkOnPixel вызов специализации шаблона!

Меньше кода, не хватает времени на выполнение, больше безопасности.

Означает ли это, что C ++ - это все-все и все языки? Конечно нет. Вы все еще должны измерять компромиссы. Невежественные люди будут использовать C ++, когда они должны были написать скрипт Bash /Perl /Python. Триггер-счастливые новички C ++ создадут глубокие вложенные классы с виртуальным множественным наследованием, прежде чем вы сможете их остановить и отправить на упаковку. Они будут использовать комплексный Boost мета-программирование, прежде чем осознать, что это необязательно. Они будут STILL использовать char * , strcmp и макросы, а не std :: string и шаблоны.

Но это говорит не что иное, как ... смотреть, с кем вы работаете. Нет языка для защиты от некомпетентных пользователей (нет, даже Java).

Продолжайте изучать и использовать C ++ - просто не перепроектируйте.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
74

RAII для победы над ребенком.

Серьезно, детерминированное уничтожение в C ++ делает код намного понятнее и безопаснее без каких-либо накладных расходов.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
67
  

Есть ли обоснованная причина использовать C ++?

  1. Шаблоны и STL. Вы продаете небольшое время сборки (и некоторые потенциально непонятные сообщения об ошибках) для лота полезных инструментов для абстракции и трудосбережения, без заметного повышения производительности во время выполнения (хотя двоичный след может быть немного больше).

    Это займет некоторое время, чтобы обернуть голову (взял меня на пару лет, прежде чем щелкнуть), но как только вы это сделаете, вы можете сделать жизнь lot проще.

  2. Текстовая обработка на C ++ порядков менее болезненна, чем в C.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
40

<сильный> Да.

Если вы ищете эффективную эффективность, вы попадаете на C или C ++, поэтому я сосредоточусь на этом.

Даже до того, как шаблоны были распространены, я предпочел использовать C ++ над C для типов исполняемых файлов, которые вы обсуждаете уже в середине 1990-х годов по двум очень простым причинам: полиморфизм объектов и RAII .

Я использовал полиморфные объекты C ++ для всех видов интересных вещей. Например, я работал над встроенной системой Linux с оверлейными буферами на процессорах OMAP и XScale ARM. Две аппаратные архитектуры имеют разные функции наложения с очень разными API-интерфейсами. Я использовал общий виртуальный базовый класс Overlay, чтобы разоблачить идеализированный вид наложений, а затем написал классы «OmapOverlay» и «XScaleOverlay», которые были созданы соответствующим образом во время выполнения, в зависимости от того, в какой архитектуре обнаружен код, на котором он работал.

Чтобы упростить, RAII представляет собой идею о том, что вы выделяете ресурсы, связанные с объектом во время конструктора объекта или, возможно, позже в течение жизни объекта, и ресурсы получают освобождение или освобождение в деструкторе объекта. Это действительно хорошо в C ++, потому что объекты, которые являются автоматическими переменными, разрушаются, когда они выходят за рамки. Для тех, кто в равной степени компетентен на C и C ++, намного проще избежать утечки ресурсов и памяти на C ++. Вы также не видите много кода на C ++ с очень распространенным C meme метки в конце функции, предшествующей связке вызовов free () , и различных goto в функциональном блоке, прыгающем туда.

Я полностью понимаю, что вы можете делать все это с помощью C - это намного больше работы, больше строк кода, и то, что вы заканчиваете, намного уродливее и часто сложнее понять. Есть код полиморфизма через X-сервер , и человек, это неуклюже и странно и часто трудно проследить.

Я также много работаю с технологиями GNOME, такими как GTK + и Clutter, все из которых написаны на C с использованием системы GObject. GObject похож на объектную систему C ++ с удаленной крышкой и все уродливые внутренние объекты, и обычно требуется полдюжины строк кода, чтобы сделать то, что сделает однострочный вызов метода C ++. В настоящее время я пишу несколько ClutterActors , и хотя математика действительно интересна, я постоянно думаю: «Все это было бы намного более кратким и понятным в C ++».

Я также часто думаю: «Вы знаете, если бы я писал это на C ++ вместо C, я бы отсутствовал в гостиной, наблюдая за MythBusters с моей женой вместо того, чтобы сидеть в моем офисе в 9 вечера."

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
29

C ++ примерно так же быстро, как C (некоторые вещи быстрее, медленнее), и он предлагает лучшие абстракции и организацию. Классы работают аналогично примитивным типам, позволяя использовать большое количество кода, не имея в виду. Перегрузка оператора и шаблоны позволяют писать код, который функционирует лучше, если данные будут меняться. Исключения могут упростить обработку ошибок. Компилятор может использоваться для проверки большего количества файлов во время компиляции.

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

Итак, я не могу сказать, стоит ли вам узнать, что вы делаете сейчас. Вы можете обойтись с помощью комбинаций Python или Perl и C, но C ++ предлагает как абстракцию, так и производительность в одном жестком для использования пакете.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
28

Я рассматриваю C ++ как язык 1990-х годов, язык ушедшей эпохи.

В то время он был большим, потому что он предлагал более строгие языковые конструкции и механизмы с более низкой стоимостью с точки зрения производительности. Это был универсальный инструмент для разработки всего, от приложений адресной книги до программного обеспечения для авионики, и это вдохновило на увлечение OO. ООП решила голод и СПИД, и да, я обвиняю C ++ в попытке промыть мозги мне в конце 1990-х, когда я впервые начал программировать, что любой язык, отличный от OO, не стоит изучать.

Теперь, когда аппаратное обеспечение продвинулось настолько много и новее, появились современные языки, я не вижу, чтобы C ++ оставался подходящим выбором для большинства приложений, за исключением вычислительно интенсивного программного обеспечения, где вам по-прежнему нужна абстракция (игры, физическое моделирование, системы САПР , и т.д.). Даже последнее можно избежать, если вы напишете компактный модульный движок в C и получите логику приложения более высокого уровня, делегированную на аккуратный язык сценариев.

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

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
21

Согласно Линусу , нет:

  
    

Когда я впервые посмотрел на исходный код Git, две вещи показались мне странными:     1. Чистый C, в отличие от C ++. Не знаю, почему. Пожалуйста, не говорите о переносимости,     это BS.

  
     

YOU полны ерунды.

     

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

     

Другими словами: выбор C является единственным разумным выбором. Я знаю Майлз   Бадер в шутку сказал: «Вы мочиться», но на самом деле это правда. Я   пришли к выводу, что любой программист, который предпочел бы   проект, который будет в C ++ над C, вероятно, является программистом, который я действительно    хотел бы отстраниться, чтобы он не пришел и не испортил какой-либо проект, с которым я связан.

     

C ++ приводит к действительно очень плохому выбору дизайна. Вы неизменно начинаете   используя «приятные» библиотечные функции языка, такие как STL и Boost   и другое общее и полное дерьмо, которое может «помочь» вам программировать, но   причины:

     
  • бесконечное количество боли, когда они не работают (и любой, кто говорит мне, что STL и особенно Boost являются стабильными и переносимыми,   просто так полон BS, что это даже не смешно)

  •   
  • неэффективные абстрактные модели программирования, где через два года вы заметили, что некоторая абстракция была не очень эффективной, но   теперь весь ваш код зависит от всех хороших объектных моделей вокруг него,   и вы не можете исправить это, не переписывая приложение.

  •   

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

     

Так что извините, но для чего-то вроде git, где эффективность была   Основная цель, «преимущества» C ++ - это просто огромная ошибка.   Тот факт, что мы также выкидываем людей, которые не видят, что это просто   большое дополнительное преимущество.

     

Если вы хотите, чтобы VCS, написанный на C ++, поиграйте с Monotone.   В самом деле. Они используют «настоящую базу данных». Они используют «хороший объектно-ориентированный   библиотеки ". Они используют" хорошие абстракции C ++ ". И, откровенно говоря,   результат всех этих проектных решений, которые звучат настолько привлекательно для некоторых   CS, конечный результат - ужасный и непосильный беспорядок.

     

Но я уверен, что вам понравится больше, чем git.

  Линус
 
ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
18

Я не думаю, что есть какая-то веская причина использовать C ++. Если вы хотите выполнить OO-программирование, вы можете использовать Python вместо этого и написать части, которые требуют быстрой производительности в C.

EDIT: существуют другие языки, хорошо взаимодействующие с C, поэтому, если вам не нравится Python, есть альтернативы.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
12

Есть ли причина использовать C ++? Безусловно.

Некоторые люди могут просто предпочесть , используя C ++ поверх других опций. Спросите, есть ли причина использовать C ++, это похоже на вопрос, почему нам нужно иметь сотни ароматов мороженого. Не всем нравится просто придерживаться Vanilla.

Если разработчики уже очень компетентны с C ++, вопрос для них может быть не «зачем использовать его?», а скорее «почему бы и нет?». Кажется, что эта модная анти-C ++ вещь происходит в SO прямо сейчас, но верьте или нет, не все согласны с этим. Некоторые люди могут просто как C ++ лучше, чем другие языки.

Требуется ли C ++ для приложений? Конечно нет. Но этот же точный вопрос можно также задать для любого другого языка. Очень очень мало случаев, когда определенные языки должны использоваться для приложения.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
12

Я просто переключаюсь с C на C ++, и я думаю, что выигрыш значителен, даже если вам не нужны шаблоны и OOP.

  • Улучшение управления памятью
  • Система более сильного типа
  • Лучшая стандартная библиотека
  • Пространство имен
  • и др.
ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
8

Я удивлен, что никто не упомянул об этом, но C ++ представил нам ссылки , которые почти решают все проблемы и ловушки указателей:

  void ModifyVar (int & amp; var)
{
    var = 5;
}

int test = 4;
ModifyVar (тест);
 

Вместо:

  void ModifyVar (int * var)
{
    * var = 5;
}

int test = 4;
ModifyVar (& амп; тест);
 

Гораздо безопаснее и проще ... и без накладных расходов при передаче.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
5

Где и почему обычно будет:

  • фамильярность
  • желаемые функции языка
  • конкретные библиотеки, которые вы хотите использовать
  • требования к производительности

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

На стороне примечания я не очень понимаю, что решил использовать C /C ++ на основе производительности (только), поскольку многие языки сценариев расширяемы с помощью C /C ++. Вы получаете преимущество быстрого языка разработки в сочетании с возможностью переноса медленных частей в расширения C /C ++. Конечно, если вы выполняете системное программирование, где каждый op считается понятным, но в большинстве приложений я его не понимаю.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
3

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

Основная идея между языками, такими как python и perl, состоит в том, чтобы делать больше с меньшим человеческим временем, но с большим временем процессора. На самом деле вы потратите больше времени на кодирование сценария python или perl, чем оно будет выполнено, но вы получите мою точку зрения.

Преимущество C /C ++ заключается в том, что они бывают быстрыми, но за счет синтаксиса и сильной типизации: вы должны сами многое сделать, чтобы компьютер не выбирал его во время компиляции.

Когда вы создаете код, некоторые строки будут работать намного больше, чем другие, и эти строки являются проблемой, которая создает проблему. С другой стороны, весь остальной код, который вы потратили много времени, выполняется гораздо реже. Возможно, вы слышали это, но это печально известное правило 80/20, и вы не сможете обойти это правило.

Решение этой проблемы состоит в том, чтобы использовать более простой язык (проще говоря, я имею в виду более дружественный к разработчику: меньше набирать текст, ленивую интерпретацию, много ранее существовавших подпрограмм и т. д.) для выполнения всего вашего кода.

Вы сделаете это так быстро по сравнению с тем, что если бы вы сделали это с помощью C или C ++, это заняло бы гораздо больший мозг.

Ваша программа будет медленной, но с профилировщиком вы выделите часть, которая выполняется 80% времени, и вы делаете их с помощью C или C ++.

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

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

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
3

Linux? Что относительно «объектно-ориентированного Паскаля» или «D»?

Предложения:

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
3

C ++ vs Python vs Perl не может быть легко оценен. Это зависит от проекта и требований.

C ++ имеет арсенал утилит давным-давно, работающий на многих платформах. Но очень больно начинать движение по потокам, просто передавая String Integer и наоборот.

C ++, с другой стороны, имеет ужасную сделку с зависимостями от библиотек. Как только вы скомпилируете что-то в GCC X или VC ++ Y, вы не можете полагаться на то, что код будет запускаться следующей версией этих инструментов. Тот же ад на Windows, тот же ад на Unix тоже.

Perl, берет свою энергию из мира Unix, но особенно как инструмент регулярного выражения. Это то, что используется большую часть времени. Наряду с некоторыми довольно серьезными инструментами, которые даже Java не может сделать это обычным способом (посмотрите, как загрузить файл на веб-сервер), Perl «просто сделайте это».

Python - это простой, гибкий и динамичный язык. Так легко, что вы можете отправить целое число в функцию, сценарий ожидает строку, но вы можете получить результат! Однако неожиданный результат, но результат. Поэтому программист должен быть очень осторожным. IDLE предлагает некоторую отладку, но когда у вас есть TELNET'ed для системы или SSH'ed на трех уровнях вниз, и вы хотите найти свою проблему, отладчик не будет стоять рядом с вами. Но он может быстро выполнить некоторую большую математическую работу.

Java - это экосистема buzzwords, чужих технологий и больших слов, и когда вы хотите просто загрузить файл на веб-сервер, вы обнаружите, что можете сделать это, только если на сервере есть JSP . Если вы хотите вызвать системные библиотеки или системные функции, такие как мониторинг, вы обнаружите, что вам нужно много выкапывать. И, возможно, для достижения JNI и ОК ... вы думаете тогда ... «Почему, Господи? «

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

Быстро сделать программу и показать свое резюме «О, я знаю эту технологию тоже» и ваш желающий быть боссом, поразитесь! Хотя технология может и не понадобиться ... (ОК, ребята, я ненавижу Spring Framework ....)

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
2

Используемый мной C ++ называется C с классами!

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
0

На самом деле есть один ответ на все возникающие вопросы. Лучшая причина использовать tech X вместо tech Y (где X и Y находятся примерно на одном уровне [как и все современные языки программирования]), потому что вы уже знаете X и не знаете Y.

(но после того, как появился Haskell, не было причин использовать что-либо еще)

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41
0

Нет, совсем нет. Если вам не нужна производительность, и есть библиотека, вы можете использовать другой язык, тогда не беспокойтесь о C /C ++. Я делаю это только сейчас, когда я нацелен на встроенные системы, которые не могут (легко?) Запускать языки. Иногда я использую C, потому что я пишу плагин, но на самом деле нет.

Однако я бы не использовал Python, Perl и т. д., чтобы избежать использования C. Мое предпочтение - это фактически C #, потому что мне нравится хорошая библиотека (которая является сильной стороной .NET), и мне нравятся статически типизированные языки. Boo - хорошая альтернатива. Но действительно Haskell , OCaml , D , ML и все это нормально.

ответил Newtopian 7 ThuEurope/Moscow2017-12-07T18:14:41+03:00Europe/Moscow12bEurope/MoscowThu, 07 Dec 2017 18:14:41 +0300 2017, 18:14:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132