Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 179
Сейчас С++ самый мощный и гибкий язык программирования, но его дни будут рано или поздно сочтены, сейчас этого не происходит только по тому что еще нету ни одного языка во всех аспеках превосходящего С++
это можно сказать про любой язык :)
Robert Martin примерно так и говорил на RailsConf: www.youtube.com/watch?v=mslMLp5bQD0
Но не про любой язык это утверждение будет истинным :)
Злые языки говорят о том, что самый гибкий — это LISP.
То, что большинство понимает под «мощностью» языка — это умение работать на самом низком уровне. На самом деле мощность — это обратное понятие, это возможность выстраивать абстракции любого порядка.
А гибкость — это возможность изменения синтаксиса под конкретную задачу, здесь С++ откровенно сливает.
То, что большинство понимает под «мощностью» языка — это умение работать на самом низком уровне. На самом деле мощность — это обратное понятие, это возможность выстраивать абстракции любого порядка.
А гибкость — это возможность изменения синтаксиса под конкретную задачу, здесь С++ откровенно сливает.
«Существует много хороших книг о С++ — одна из них Programming: Principles and Practice using C++.»
ссылка не пашет, 404.
а статья весьма и весьма интересна.
а касается «ловушек на с++» или «глупые ошибки, которые так легко совершить, но трудно найти в С++», дорогие коллеги! практика и еще раз практика. с годами работы на с++ это нарабатывается.
ссылка не пашет, 404.
а статья весьма и весьма интересна.
а касается «ловушек на с++» или «глупые ошибки, которые так легко совершить, но трудно найти в С++», дорогие коллеги! практика и еще раз практика. с годами работы на с++ это нарабатывается.
«такие новомодные языки как Erlang» — да ну ладна?
ага, только С++ это пичалька
был С — «отлично, теперь нам не надо мучаться с грусными местами АСМа, встроенные оптимизации тоже хороши»
С++ появился — «смотрите, ООП, какие то другие фички, пространства имён, это всё так современно но при этом мы можем писать как на Си»
С++ продолжился — «особое С++ ООП, шаблоны, большой новый мир, да ещё и с поддержкой Си»
С++0X — «новые фичи из других языков, метапрограммирование, шаблонное программирование, многопоточность… стоп, мы всё ещё можем писать на Си ????»
я к чему это всё
язык вылезает из низкоуровненного в «высокие абстракции», но при этом по сути он как был низкого уровня, так и остался
конечно можно говорить что настоящий ПРО во всём этом не потеряется, но НАСТОЯЩИЙ про забьёт на такое дело, абстракции и так тонкая материя, подмешивать сюдя ещё и почти што асм это точно приведёт к необходимости переписывать код (и не обязательно именно рефакторить, замечу)
а бизнес в 99.9% не ждёт того что вы будете переписывать свой месячный труд
P.S.
а язык который действительно написан сразу и на века — это перл, С++ рядом не лежал
был С — «отлично, теперь нам не надо мучаться с грусными местами АСМа, встроенные оптимизации тоже хороши»
С++ появился — «смотрите, ООП, какие то другие фички, пространства имён, это всё так современно но при этом мы можем писать как на Си»
С++ продолжился — «особое С++ ООП, шаблоны, большой новый мир, да ещё и с поддержкой Си»
С++0X — «новые фичи из других языков, метапрограммирование, шаблонное программирование, многопоточность… стоп, мы всё ещё можем писать на Си ????»
я к чему это всё
язык вылезает из низкоуровненного в «высокие абстракции», но при этом по сути он как был низкого уровня, так и остался
конечно можно говорить что настоящий ПРО во всём этом не потеряется, но НАСТОЯЩИЙ про забьёт на такое дело, абстракции и так тонкая материя, подмешивать сюдя ещё и почти што асм это точно приведёт к необходимости переписывать код (и не обязательно именно рефакторить, замечу)
а бизнес в 99.9% не ждёт того что вы будете переписывать свой месячный труд
P.S.
а язык который действительно написан сразу и на века — это перл, С++ рядом не лежал
ну юзерпик нам как бы все говорит, да.
>конечно можно говорить что настоящий ПРО во всём этом не потеряется, но НАСТОЯЩИЙ про забьёт на такое дело, абстракции и так тонкая материя, подмешивать сюдя ещё и почти што асм это точно приведёт к необходимости переписывать код (и не обязательно именно рефакторить, замечу)
а бизнес в 99.9% не ждёт того что вы будете переписывать свой месячный труд
P.S.
а язык который действительно написан сразу и на века — это перл, С++ рядом не лежал
это как речь гадалки вроде бы гладко и четко говорит, да вот бред и выдумки.
а бизнес в 99.9% не ждёт того что вы будете переписывать свой месячный труд
P.S.
а язык который действительно написан сразу и на века — это перл, С++ рядом не лежал
это как речь гадалки вроде бы гладко и четко говорит, да вот бред и выдумки.
«С++ or not C++, C++ или Java/Python/Ruby?» — нужно учесть еще, что огромное количество кода написано, миллионы и миллиарды строк = куча библиотек. Кто будет все это переписывать на другие языки? С++, Fortran, Java… Выбор к тому или другому языку несомненно зависит от стоящей перед программистом задачи и навыков, но порой просто нет выбора…
Прекрасная карта языка С++. Спасибо Вам за ссылку и Елене Сагалаевой за разработку.
Прочитав название сразу же хочется сказать «не нравится — не ешь». Вариантов масса: заставляет начальство, всегда можно изучить другой язык и найти другую работу. Нет любимого тебе языка, пиши свой, но ты при этом должен осознавать всю работу, которую придется сделать. Нет нужной билиотеки классов, сборщика мусора? Милости просим к перуклавиатуре, потомки будут благодарны. Для каждого языка, есть своя область применения и С++ как и ООП ИМХО не панацея от всех бед…
Страуструп в своей книге «The Design and Evolution of C++» сказал, что сравнение языков программирования субъективно. Да и не нужно забывать, что программирование, в первую очередь, это математика, а не конкретная платформа/язык/идиома. Подобные выкрики о скорой кончине С++ слышал часто, но только от людей, которые его совсем не знают.
Немного изменю слова А. Степанова: «Читайте Кнута, а не рассуждайте о жизненном цикле языков программирования»
Спасибо за статью!
Немного изменю слова А. Степанова: «Читайте Кнута, а не рассуждайте о жизненном цикле языков программирования»
Спасибо за статью!
Как всегда у цппшников аргументы в стиле «ты просто не умеешь их готовить».
Надо признать, «умение готовить» — очень важно везде :)
на каждый обед делать себе кулинарный изык несколько затруднительно. ОБычно надо пожрать побыстрее, посытнее и как можно быстрее…
И это часто приводит к язве желудка впоследствии :)
А "на каждый обед делать себе кулинарный изык" вовсе и не надо. Ситуация вообще выглядит не так. Просто кто-то умеет пользоваться фишками различных языков (и, соответственно, работает быстро, эффективно и качественно), а кто-то — нет. Профессионал может быстро приготовить вкусное и полезное блюдо из любых (хороших) продуктов, а дилетант угробит что угодно и останется голодным.
Хотя, надо признать, что для разных задач — разные языки. Как и в кулинарии. Из клубники шашлык не приготовишь.
Хотя, надо признать, что для разных задач — разные языки. Как и в кулинарии. Из клубники шашлык не приготовишь.
>Как всегда у цппшников аргументы в стиле «ты просто не умеешь их готовить».
Аргумент «невозможно сразу начать использовать сложный инструмент правильно» верен для любого сложного инструмента. C++ — как раз такой сложный инструмент.
Так что да, если в вашей С++-программе что-то идёт не так, как вы того ожидали — вы действительно «не умеете его готовить». И это не эксклюзивная фича С++, такое есть в любом другом языке.
Java:
Вопрос: «А-а-а, какого хрена protected-метод доступен из другого класса, не являющегося наследником??»
Ответ: «В Java protected методы доступны в пределах пакета, а раз возникает такой вопрос, то вы не знаете Java».
Python:
Вопрос: «А-а-а, какого хрена я меняю один объект внутри метода, а меняется совсем другой объект и в другом месте??»
Ответ: «В Python объекты передаются по ссылке, и при „присвоении“ одного объекта другому на самом деле происходит создание ещё одной ссылки на тот же самый объект, а раз у вас возникает такой вопрос, то вы не знаете Python».
И так далее, и тому подобное, и таких примеров — сотни и тысячи.
Выучиить язык — это не освоить его синтаксис, написав пять хелловорлдов разной степени сложности по книжке "%languagename% за 48 часов", а понять и прочувствовать его фундаментальные основы.
Аргумент «невозможно сразу начать использовать сложный инструмент правильно» верен для любого сложного инструмента. C++ — как раз такой сложный инструмент.
Так что да, если в вашей С++-программе что-то идёт не так, как вы того ожидали — вы действительно «не умеете его готовить». И это не эксклюзивная фича С++, такое есть в любом другом языке.
Java:
Вопрос: «А-а-а, какого хрена protected-метод доступен из другого класса, не являющегося наследником??»
Ответ: «В Java protected методы доступны в пределах пакета, а раз возникает такой вопрос, то вы не знаете Java».
Python:
Вопрос: «А-а-а, какого хрена я меняю один объект внутри метода, а меняется совсем другой объект и в другом месте??»
Ответ: «В Python объекты передаются по ссылке, и при „присвоении“ одного объекта другому на самом деле происходит создание ещё одной ссылки на тот же самый объект, а раз у вас возникает такой вопрос, то вы не знаете Python».
И так далее, и тому подобное, и таких примеров — сотни и тысячи.
Выучиить язык — это не освоить его синтаксис, написав пять хелловорлдов разной степени сложности по книжке "%languagename% за 48 часов", а понять и прочувствовать его фундаментальные основы.
понять основы можно и за 5 минут, если они простые и понятные. а вот если они представляют из себя тысячу и одну несуразность, то и 10 лет может не хватить. вопрос: зачем нужен язык на освоение умения готовить который требуется 10 лет производя в течении которых говнокод разной степени вонючести?
Для разных целей нужны эти языки. Понятно, что сайт лучше писать на Java/Python/Ruby (ну кроме особых проектов и CGI), а операционную систему лучше писать на C++. Странно, что не все это понимают.
Ну да, время C++ возможно кончается, в нем нет различных новинок программирования, однако вряд ли в этом направлении есть что-то, более развитое, чем C++. Ненавидеть C++ — это крайне странно для программиста.
Наконец, C++ может показаться сложным и нелогичным. Но со временем и опытом к Вам придет понимание, что он прекрасен.
В наше время многое написано на C++, в том числе и те же Python/Ruby. И от этого никуда не деться, нужно лишь понять, почему часто выбирают именно этот язык.
Ну да, время C++ возможно кончается, в нем нет различных новинок программирования, однако вряд ли в этом направлении есть что-то, более развитое, чем C++. Ненавидеть C++ — это крайне странно для программиста.
Наконец, C++ может показаться сложным и нелогичным. Но со временем и опытом к Вам придет понимание, что он прекрасен.
В наше время многое написано на C++, в том числе и те же Python/Ruby. И от этого никуда не деться, нужно лишь понять, почему часто выбирают именно этот язык.
и какая же ОС написана на С++?
Догадайтесь.
Понятно, что не вся ОС, но тем не менее большая часть.
Или я снова перепутал C и C++?
Понятно, что не вся ОС, но тем не менее большая часть.
Или я снова перепутал C и C++?
Насколько я знаю, большая часть BeOS/Haiku. Но, как показывает жизнь, Linux, написанный по большей части на C их сделал.
WinNT. Что многое объясняет ;)
> Ну да, время C++ возможно кончается, в нем нет различных новинок программирования
Посмотрите на новый стандарт.
> Наконец, C++ может показаться сложным и нелогичным.
Не только может показаться, он такой и есть.
> Но со временем и опытом к Вам придет понимание, что он прекрасен.
Одно другому не мешает :)
Посмотрите на новый стандарт.
> Наконец, C++ может показаться сложным и нелогичным.
Не только может показаться, он такой и есть.
> Но со временем и опытом к Вам придет понимание, что он прекрасен.
Одно другому не мешает :)
>>Наконец, C++ может показаться сложным и нелогичным.
>Не только может показаться, он такой и есть.
Сложный — да, нелогичный — вряд ли. Главная «проблема» любой логики в том, что чтобы получить верный вывод, нужно отталкиваться от верных предпосылок. А если предпосылка неверна, то и результат с большой долей вероятности получится неверный. В случае любого языка предпосылками являются знания программистом базовых основ.
То самое (чрезвычайно «любимое» всеми новичками :)) поведение дефолтного конструктора копирования и оператора присваивания в С++ — логично от начала и до конца: в старом объекте был указатель — в новый объект скопировался именно указатель. А если программист не понимает, что такое указатель и чем он отличается от непосредственно объекта и исходит из того, что при копировании указателя происходит копирование объекта — извините, тут нужно чинить «базу», а не обвинять язык в нелогичности.
>Не только может показаться, он такой и есть.
Сложный — да, нелогичный — вряд ли. Главная «проблема» любой логики в том, что чтобы получить верный вывод, нужно отталкиваться от верных предпосылок. А если предпосылка неверна, то и результат с большой долей вероятности получится неверный. В случае любого языка предпосылками являются знания программистом базовых основ.
То самое (чрезвычайно «любимое» всеми новичками :)) поведение дефолтного конструктора копирования и оператора присваивания в С++ — логично от начала и до конца: в старом объекте был указатель — в новый объект скопировался именно указатель. А если программист не понимает, что такое указатель и чем он отличается от непосредственно объекта и исходит из того, что при копировании указателя происходит копирование объекта — извините, тут нужно чинить «базу», а не обвинять язык в нелогичности.
Официальный интерпретатор ruby написан на C.
Его можно выучить за 21 день по книжке =)
Я так и делал, по этой самой книжке Джесса Либерти — прочитал за 2 дня, научился писать самостоятельно за месяц, а потом — несколько лет углубленного изучения и хождения по граблям. Полагаю, с остальными языками ситуация схожая: на освоение синтаксиса нужно относительно немного времени, а на получение знаний по его правильному применению — на порядок больше.
пруф пик
Си тоже не стоит на месте :)
В gcc4.6 наконец добавили очень полезный экстеншен из Plan9 C Compiler'а -fplan9-extensions
В gcc4.6 наконец добавили очень полезный экстеншен из Plan9 C Compiler'а -fplan9-extensions
> C++, по моему впечатлению, занят тем, что переписывает C, заменяя то, что C и так умеет, своими собственными конструктами.
Любой язык-надстройка только это и делает. Единственное действительно полезное добавление в C++ — это шаблоны, да и те пора переработать с оглядкой на D.
Любой язык-надстройка только это и делает. Единственное действительно полезное добавление в C++ — это шаблоны, да и те пора переработать с оглядкой на D.
второй вариант читабельнее, нее?
Это Вы размеры сравниваете? Ну так «сишечка сосет» у J:
Загляните в реализацию qsort в CRT Вашего любимого компилятора C. Значит ли это, что нужно писать на J?
Размер программы давно никого не интересует, если он приносится в жертву читабельности (иногда размер приходит один, но здесь явно не тот случай). Как пример длинные и human-readable названия идентификаторов.
Кстати, variadic template-ы возможно принесут в нашу жизнь type safe форматировнный вывод (a-la String.Format)
quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)Загляните в реализацию qsort в CRT Вашего любимого компилятора C. Значит ли это, что нужно писать на J?
Размер программы давно никого не интересует, если он приносится в жертву читабельности (иногда размер приходит один, но здесь явно не тот случай). Как пример длинные и human-readable названия идентификаторов.
Кстати, variadic template-ы возможно принесут в нашу жизнь type safe форматировнный вывод (a-la String.Format)
Не сочтите за троллинг, я не программист, но знаком и с С, и с С++. И вот мне очень интересно, как на С реализовать шаблоны, например. Правда интересно, с удовольствием бы посмотрел на решение.
Простите, а шаблоны нужны не для того ли, чтобы, условно говоря, извернуться — и обойти систему типов, м? Но если вообще надо что-то обходить — не похоже ли это на workaround архитектурной ошибки?
Нет, не для того. Шаблоны — они про метапрограммирование, а не про обход системы типов. Более того, шаблоны type safe, что является их ГЛАВНЫМ преимуществом перед препроцессорными макросами
Да не надо мне рассказывать, на каком этапе работы компилятора разворачиваются шаблоны, чесслово! :-D Я еще многим могу фокусы из Александреску-стайл оперы показывать.
Однако, со времен работы с С++ мне довелось познакомиться с целой группой языков, где не надо решать подобные задачи столь неуклюжим способом: от Хаскелла до ряда динамических языков — где это совсем уж просто.
«Неуклюжим» — это про местами неоднозначный синтаксис, про проблемы отладки такого кода, про… Ну, полагаю, про проблемы программирования с шаблонами здесь никому рассказывать не надо.
Однако, со времен работы с С++ мне довелось познакомиться с целой группой языков, где не надо решать подобные задачи столь неуклюжим способом: от Хаскелла до ряда динамических языков — где это совсем уж просто.
«Неуклюжим» — это про местами неоднозначный синтаксис, про проблемы отладки такого кода, про… Ну, полагаю, про проблемы программирования с шаблонами здесь никому рассказывать не надо.
Hint: шаблоны разворачиваются на этапе компиляции.
А теперь подумайте, удастся ли в этих условиях «обойти систему типов» ;)
А теперь подумайте, удастся ли в этих условиях «обойти систему типов» ;)
Ох, да у автора бугурт. Причем, похоже, что-то кроме плюсцов он почти ничего и не видел.
Предпочитаю не вести споры на теологические темы, однако хочу заметить, что на сегодняшний день нет альтернативы С и С++ и парадигмы тут ни при чем. Любой язык транслируется в машинный код и процессору без разницы на каком языке этот код писали изначально. Тот, кто сталкивается с программированием на С/С++ знает, что невозможно писать на этих языках без понимания того, как и что делает железо — и это основная проблема для новичков. Когда меня просят рассказать «об указателях и строках» я начинаю с того, что нет никаких указателей и строк — есть адреса в памяти. Какой еще язык программирования даст вам столь тесный контакт с железом и столь полный контроль над выполнением кода? Почему большинство расширений для php, python-а, lua и других языков пишутся именно на С/С++? У этих языков всегда будет своя ниша, они уникальны и разрабатывать что-то еще я не вижу смысла, пока не появится железо, не совместимое идеологически с тем, для которого мы с вами пишем код.
Камль?
Я не знаком с ним, но если там я смогу управлять адресами вызовов методов классов — то возможно, что да.
class T {
public:
void moo () {
printf ( «moo!\n» );
}
void foo () {
printf ( «foo!\n» );
}
};
union hack {
void (T::*pointer)(void);
char * addr;
};
int main () {
T *t = new T();
hack h;
h.pointer = &T::moo;
(t->*h.pointer)();
char *addr = h.addr;
h.pointer = &T::foo;
(t->*h.pointer)();
h.addr = addr;
(t->*h.pointer)();
return 0;
}
class T {
public:
void moo () {
printf ( «moo!\n» );
}
void foo () {
printf ( «foo!\n» );
}
};
union hack {
void (T::*pointer)(void);
char * addr;
};
int main () {
T *t = new T();
hack h;
h.pointer = &T::moo;
(t->*h.pointer)();
char *addr = h.addr;
h.pointer = &T::foo;
(t->*h.pointer)();
h.addr = addr;
(t->*h.pointer)();
return 0;
}
вопрос только зачем это делать…
за такой код в Соловец на вечное покаяние высылать нужно.
хотя бы потому, что указатели на члены классов не обязаны по размеру совпадать с обычным указателем.
хотя бы потому, что указатели на члены классов не обязаны по размеру совпадать с обычным указателем.
Спасибо, капитан! Целью примера было, так сказать, «unleash the power», а не грамотный код сам по себе, да и вообще такие ужасы ни писать ни даже читать я сам никому не рекомендую. Код должен быть красив, понятен и желательно пахнуть фиалками.
Возникает очевидное противоречие: с одной стороны вы вроде как продемонстрировали «силу сильную», а с другой никому не рекомендуете эту силу использовать. Отсюда вопрос: зачем такая фича нужна и зачем требовать от языка её наличия. Нелогично. :-)
Ничего нелогичного. Это не демонстрация «сильной стороны», а скорее «иллюстрация возможностей». А уж кто и как эти возможности собирается использовать — сугубо личное и интимное. Зачем конкретно нужна такая фича, сказать прямо так не берусь, но однажды, помнится, ее использовал. Это был некий класс-обертка для практически прямого маппинга классов C++ в Lua, так что иногда всякие чудеса все таки нужны.
Вы считаете C/C++ серебряной пулей?
Язык D, как потомок C/C++, может быть, даже и подходит. Одна из его проблем в том, что от «оторвался» от предков и огромные объёмы наработок на C/C++ удобно использовать не позволяет.
> Потому что в большом проекте вы хотите встречать только очень простой, скучный, тривиальный, но зато понятный код.
Если это настоящая причина, то с языками вы немного ошиблись. Для этого как раз подходит Common Lisp в императивном или ООП (не функциональном!) стиле, D и Java. Набедокурить можно и в них, но в Python, Ruby и C++ это сделать на порядок проще.
Честно не понимаю как плюсник мог записать D в список непонятных языков.
Если это настоящая причина, то с языками вы немного ошиблись. Для этого как раз подходит Common Lisp в императивном или ООП (не функциональном!) стиле, D и Java. Набедокурить можно и в них, но в Python, Ruby и C++ это сделать на порядок проще.
Честно не понимаю как плюсник мог записать D в список непонятных языков.
Тема GC холиварна. Предлагаю не добавлять в обсуждение ещё один. :)
> Если в С++ коде я вижу int i = 0; foo(++i);, то я могу сказать что будет в переменной i после выполнения foo
В C++ есть тысяча и один способ сломать программу. Ну заменим пару сотен на один — lazy параметры. :) Если бы вы боялись опасных фичей — писали бы на параноидальных языках вроде Java или Ada.
Кстати, за foo(++i) коллеги будут бить линейкой по пальцам и в D, и в C++, и в Java. Но тут в D есть решение, которое я, пожалуй, отправлю рассылку — разрешать только чистые функции в lazy параметрах. т.е. foo(i++) можно, foo(make_some_stuff(i)) можно, foo(++i) — нельзя.
> Если в С++ коде я вижу int i = 0; foo(++i);, то я могу сказать что будет в переменной i после выполнения foo
В C++ есть тысяча и один способ сломать программу. Ну заменим пару сотен на один — lazy параметры. :) Если бы вы боялись опасных фичей — писали бы на параноидальных языках вроде Java или Ada.
Кстати, за foo(++i) коллеги будут бить линейкой по пальцам и в D, и в C++, и в Java. Но тут в D есть решение, которое я, пожалуй, отправлю рассылку — разрешать только чистые функции в lazy параметрах. т.е. foo(i++) можно, foo(make_some_stuff(i)) можно, foo(++i) — нельзя.
Столько разговоров о GC, а делов-то:
// см. digitalmars.com/d/2.0/phobos/core_memory.html
import core.memory;
void main()
{
GC.disable; // отключаем сборщик мусора
…
// profit!
}
Вообще-то, разработчики языка и стандартной библиотеки стараются сводить к минимуму необходимость использования указателей в D, и у них это получается — указатели, в основном, используются для взаимодействия с внешними библиотеками на C и C++.
// см. digitalmars.com/d/2.0/phobos/core_memory.html
import core.memory;
void main()
{
GC.disable; // отключаем сборщик мусора
…
// profit!
}
Вообще-то, разработчики языка и стандартной библиотеки стараются сводить к минимуму необходимость использования указателей в D, и у них это получается — указатели, в основном, используются для взаимодействия с внешними библиотеками на C и C++.
> GC.disable;
При этом успешно начинают течь операции с массивами и лексические замыкания. Не надо FUD, это не наш стиль.
Впрочем, стандартная библиотека (обе) не текут, достаточно следить за своим кодом.
При этом успешно начинают течь операции с массивами и лексические замыкания. Не надо FUD, это не наш стиль.
Впрочем, стандартная библиотека (обе) не текут, достаточно следить за своим кодом.
В модуле std.container есть класс Array — аналог плюсового std::vector. Про него, в частности, сказано: «The memory allocated for the array is reclaimed as soon as possible; there is no reliance on the garbage collector». Используйте Array, если хотите работать без GC. Про то, что за встроенными динамическими массивами прибирает GC, явно сказано в документации, цитирую: «Any generated temporaries get cleaned up by the garbage collector (or by using alloca())», digitalmars.com/d/2.0/arrays.html.
В той же Java, кстати, GC вообще не отключается — и ничего, живут как-то с этим (:
А про лексические замыкания не понял, поясните, пожалуйста.
В той же Java, кстати, GC вообще не отключается — и ничего, живут как-то с этим (:
А про лексические замыкания не понял, поясните, пожалуйста.
А есть ещё язык Ada. Про него мало кто знает, и изучать его — сложнее, чем C/C++, но для больших проектов (хотя и не любой тематики) — это один из лучших вариантов. Опять же, если «уметь готовить».
«Программирование на языке Ада» — сильно звучит ;)
Угу. У меня книжка такая есть. Поскольку не нужна, отправил ее к бабушке храниться. Бабушка богомольная, книжки первое время пугалась.
А как звучит «От Паскаля к Аде»:
Авторы: В. Н. Орлов, В. Ю. Блажнов, Т. Ю. Бардинова, А. А. Маслов,
Издателство: Финансы и статистика, 1990 г.
Авторы: В. Н. Орлов, В. Ю. Блажнов, Т. Ю. Бардинова, А. А. Маслов,
Издателство: Финансы и статистика, 1990 г.
Надо ещё учитывать то, что далеко не всякий разработчик, восторгающийся другими языками программирования, может позволить себе перейти на них с C/C++. Переписать всё заново на другом языке есть возможность не всегда. Состыковать старые наработки с новыми (на другом языке) тоже не всегда просто. А реальная жизнь требует выполнения сроков и соответствия бюджету.
Можно подумать, программисты на С++, начитавшись статей против своего любимого языка, бросятся писать на других языках, как будто раньше и не подозревали, что те существуют. Да, С/С++ сложен, не каждому по силам, ну и что? Альтернативы так или иначе имеются. А умрет язык — ну и что такого? Умрет только от старости, когда каждый сможет с уверенностью сказать, что язык сослужил хорошую службу и может отправляться «на покой».
До конца не умрёт — всё равно останутся заповедные чащи, где он будет водиться ещё многие десятилетия, пугая случайно забредших путников %)
В наше время далеко не каждый программист хотя бы слышал слово «Кобол» (не говоря уже о том, чтобы знать хотя бы базовые фичи и область применения), однако мой бывший коллега (ничуть не «динозавр» из старой гвардии, ему сейчас <30) недавно устроился на новую работу и пишет именно на нём %)
В наше время далеко не каждый программист хотя бы слышал слово «Кобол» (не говоря уже о том, чтобы знать хотя бы базовые фичи и область применения), однако мой бывший коллега (ничуть не «динозавр» из старой гвардии, ему сейчас <30) недавно устроился на новую работу и пишет именно на нём %)
Все эти холивары немного ни про что. Люди пишут на том, что им удобно, и что подходит к задаче.
В этом смысле C++ ещё долго не потеряет смысла.
На мой взгляд, к сожалению. Потому что лучше потратить то же время обучения на понимание OOP, AOP и прочей архитектуры, чем на понимание тонкостей работы со ссылками и всех подробностей сложного языка. А для производительности в современном мире, может быть, даже важнее потратить время обучения на понимание многопоточности.
То есть C++ конечно может всё, но если учитывать, что на проектах бывают джуниоры, я бы предпочёл оценивать их с т.з. вышеописанного, чем разбирать их утечки памяти.
В этом смысле C++ ещё долго не потеряет смысла.
На мой взгляд, к сожалению. Потому что лучше потратить то же время обучения на понимание OOP, AOP и прочей архитектуры, чем на понимание тонкостей работы со ссылками и всех подробностей сложного языка. А для производительности в современном мире, может быть, даже важнее потратить время обучения на понимание многопоточности.
То есть C++ конечно может всё, но если учитывать, что на проектах бывают джуниоры, я бы предпочёл оценивать их с т.з. вышеописанного, чем разбирать их утечки памяти.
Microsoft Office — широко распространенная, расширяемая, встраиваемая и самая нашпигованная фичами система. При портировании Microsoft Office, нужно чтобы в результате не получился монстр и программа быстро реагировала на ваши действия. Вы должны быть уверены, что можно будет написать мощные расширения, которые смотрелись как одно целое с программой.Microsoft Office это и есть монстр.
World of Warcraft — и здесь я рассматриваю не только десктопного клиента, который перерабатывает огромное количество событий, следует куче правил, отрисовывает графику и делает еще кучу всего связанного с игрой. Подумайте также о серверной части. Нужны ли еще какие-либо слова об этой прекрасной программе?
Неофициальный сервер lineage 2 написан на java, и крупнейший русский фришард имеет больший онлайн на одном сервере чем официальный.
Google Chrome — кроссплатформенный браузер, первый по скорости и производительности. Если вы захотите заменить язык программирования, на котором он написан, то придется использовать тот язык, который портируется на многие платформы. Я говорю не только о Mac OSX, Windows или Linux — также имею в виду Android (проверьте, Google TV — это Android с портированным Chrome).Андроид использует как основной язык когобывыдумали… Яву!
Я даю вам возможность самим назвать хотя бы один другой язык программирования, который позволяет написать программы подобные этим и предоставить тот же уровень функциональности, стабильности, расширяемости, портабельности.Написанные на яве программы идут под любой осью, даже не обязательно собирать свою версию под каждую. Уронить программу на яве намертво сложно, а сишные при любом исключении норовят упасть совсем. Что понимается под расширяемостью и функциональностью я не совсем понял.
Если считаете, что проприетарность может мешать широкому применению, то взгляните на Java, который стал новым Cobol’ом в мире бизнеса.Щито? А OpenJDK?
Нет, я не спорю, C/C++ штука чрезвычайно мощная. Но в большинстве случаев это становится его минусом — эту мощь надо еще уметь использовать. Шедевры вроде uTorrent (меньше 400 кб со всей его функциональностью) — редкие исключения.
> Щито? А OpenJDK?
А до OpenJDK широкого применения не было?
А до OpenJDK широкого применения не было?
Неофициальный сервер lineage 2 написан на java, и крупнейший русский фришард имеет больший онлайн на одном сервере чем официальный.
Больше, думается, потому что шара и язык на котором написана серверная часть в этом примере ни о чём не говорит
Андроид использует как основной язык когобывыдумали… Яву!
Основной, но не единственный.
Больше, думается, потому что шара и язык на котором написана серверная часть в этом примере ни о чём не говоритРечь не о популярности, а о способности это количество выдержать. На оффе жесткий лимит в 5000 онлайна не от хорошей жизни. А там 8000 помню было, если не больше.
Основной, но не единственный.Не единственный, но основной.
Андроид использует как основной язык когобывыдумали… Яву!
Вообще-то C/C++. На Java там тока UI. (источник)
Oblitus имел ввиду немного другое: Java — основной язык разработки приложений для Android, а не самой OS.
Смотрите developer.android.com/sdk/ndk/overview.html, раздел Development tools. Там написано, что для C и C++ доступна лишь часть библиотек, необходимых для разработки (приведён их список).
Смотрите developer.android.com/sdk/ndk/overview.html, раздел Development tools. Там написано, что для C и C++ доступна лишь часть библиотек, необходимых для разработки (приведён их список).
>Неофициальный сервер lineage 2 написан на java, и крупнейший русский фришард имеет больший онлайн на одном сервере чем официальный.
Откройте код этого сервера. Потом прочитайте такую замечательную и бесплатную книжку Parallel Programming. И вдруг вас озарит, что тяжело называть программистами тех людей, которые писали основную часть этого сервера.
Лучше приводите пример с Аллодами Онлайн, у них официальный сервер тоже написан на Жаве.
Откройте код этого сервера. Потом прочитайте такую замечательную и бесплатную книжку Parallel Programming. И вдруг вас озарит, что тяжело называть программистами тех людей, которые писали основную часть этого сервера.
Лучше приводите пример с Аллодами Онлайн, у них официальный сервер тоже написан на Жаве.
Уронить программу на яве намертво сложно, а сишные при любом исключении норовят упасть совсем. Что понимается под расширяемостью и функциональностью я не совсем понял.
ну тут уже от рук программиста зависит. Многое чем я пользовался на яве — падало. (не писал, пользовался!)
ну тут уже от рук программиста зависит. Многое чем я пользовался на яве — падало. (не писал, пользовался!)
На серверах С++ прекрасно заменяется Java-ой начиная с обработки HTTP запросов и заканчивая MMORPG. Как пример тому гугловское облако сделано на Jetty (которое полностью написано на Java). Или не менее популярная игра — Lineage, серверная часть написано полностью на Java.
На клиентах С++ держится из-за 3D (игры, CAD и т.д.). Здесь я ничего сказать не могу, т.к. нет опыта работы в этой области. Но думаю когда появится нормальный интерфейс для работы с GPU из Java, то 3D графика будет работать с той же скоростью, что и в C++.
Плюс не забывайте, что Autocad, 3D Max и подобные пакеты существовали до появления Java. Так что, возможно сейчас более выгодно делать подобные приложения на той же Java… Но тут я не специалист — может так уже и делают.
На клиентах С++ держится из-за 3D (игры, CAD и т.д.). Здесь я ничего сказать не могу, т.к. нет опыта работы в этой области. Но думаю когда появится нормальный интерфейс для работы с GPU из Java, то 3D графика будет работать с той же скоростью, что и в C++.
Плюс не забывайте, что Autocad, 3D Max и подобные пакеты существовали до появления Java. Так что, возможно сейчас более выгодно делать подобные приложения на той же Java… Но тут я не специалист — может так уже и делают.
На серверах C++ прекрасно заменяется практически чем угодно. В топике речь про десктопы, судя по примерам.
дело в том что в играх есть не только графика… и всегда есть чем занять процессор, когда он освобождается от графики…
сейчас уже не редкость, что параллельно видеокарте, работает софтовый растеризатор, для того чтоб повысить эфективность кулинга объектов и на видюху отправлять только то, что действительно есть на экране…
сейчас уже не редкость, что параллельно видеокарте, работает софтовый растеризатор, для того чтоб повысить эфективность кулинга объектов и на видюху отправлять только то, что действительно есть на экране…
С — это подмножество С++
Ложь, особенно после C99.
Я никогда не буду писать на C++ парсер для кривого HTML для импорта данных с внешнего веб-проекта. Также я никогда не буду писать на Ruby/PHP аудио-плейер или драйвера. Люди не понимающие зачем нужны различные языки никогда в жизни не занимались программированием полноценно и не решали различные задачи. Спор можно прекратить.
Из этого топика я так и не получил информации почему С++ еще жив и будет жить. :) Автор такой же эмоциональный холиварщик, как тот, кого он цитирует.
Я, например, думаю, что С++ популярен не из-за своей крутой скорости. Как уже сказали выше, Java или C# не особо уступает как на серверах, так и на клиенте. Поэтому думаю основная фишка в том, что:
1. Запускается из коробки без необходимости установки JRE или Mono, тем самым юзеру нужно скачать 400-900Кб и всё гарантировано заработает. Не нужно тянуть 15 метров JRE например и возможно иметь проблемы из-за несовместимы с новыми JRE.
2. Игры — большие наработки в этом направлении тянутся из 90-х, куча отработанных технологий: движки, библиотеки и т.д.
3. Куча «древнего» софта Apache, 3D Max, Autocad, Microsoft Office и т.д., которые писались на С/С++ когда Java, C# еще и не существовали. Естественно, никто не будет переписывать их, когда куча кода написано на С/С++.
У кого еще какие идеи?
Я, например, думаю, что С++ популярен не из-за своей крутой скорости. Как уже сказали выше, Java или C# не особо уступает как на серверах, так и на клиенте. Поэтому думаю основная фишка в том, что:
1. Запускается из коробки без необходимости установки JRE или Mono, тем самым юзеру нужно скачать 400-900Кб и всё гарантировано заработает. Не нужно тянуть 15 метров JRE например и возможно иметь проблемы из-за несовместимы с новыми JRE.
2. Игры — большие наработки в этом направлении тянутся из 90-х, куча отработанных технологий: движки, библиотеки и т.д.
3. Куча «древнего» софта Apache, 3D Max, Autocad, Microsoft Office и т.д., которые писались на С/С++ когда Java, C# еще и не существовали. Естественно, никто не будет переписывать их, когда куча кода написано на С/С++.
У кого еще какие идеи?
Предположу, что из-за того, что память можно выделять самому и сколько хочешь,
можно писать программы, которые менее требовательны к памяти.
Но тестировать надо потом на утечки.
можно писать программы, которые менее требовательны к памяти.
Но тестировать надо потом на утечки.
>2. Игры — большие наработки в этом направлении тянутся из 90-х, куча отработанных технологий: движки, библиотеки и т.д.
Поверьте, еслиб Java и C# были не такими тормозными, в индустрии геймдева первыми бы уже всё переписали на этих языках. Просто маркетинговый бред с микробенчами засрал всем головы.
>3. Куча «древнего» софта Apache, 3D Max, Autocad, Microsoft Office и т.д., которые писались на С/С++ когда Java, C# еще и не существовали. Естественно, никто не будет переписывать их, когда куча кода написано на С/С++.
А как вам такая история. EverNote 4 полностью переписан с C# на C++ по причине тормознутости .NET'а.
Поверьте, еслиб Java и C# были не такими тормозными, в индустрии геймдева первыми бы уже всё переписали на этих языках. Просто маркетинговый бред с микробенчами засрал всем головы.
>3. Куча «древнего» софта Apache, 3D Max, Autocad, Microsoft Office и т.д., которые писались на С/С++ когда Java, C# еще и не существовали. Естественно, никто не будет переписывать их, когда куча кода написано на С/С++.
А как вам такая история. EverNote 4 полностью переписан с C# на C++ по причине тормознутости .NET'а.
Странно получается. Если программа на С++ тормозит — это у программиста руки кривые, а если тормозит программа на C# — то это во всем виноват .NET.
Ок, тогда ждём когда все игры перепишут на Go :) Обещают сравнимую производительность с С++ и простоту Java/C#/D — даже проще. Единственно, там сейчас даже официальных драйверов к популярным БД нету :(
Поверьте, еслиб Java и C# были не такими тормозными, в индустрии геймдева первыми бы уже всё переписали на этих языках. Просто маркетинговый бред с микробенчами засрал всем головы.
Проблема явы не в тормознутости, скорость у нее на уровне. Проблема в легкости декомпиляции.
Программирование в геймдеве отличается от программирования веб-сервисов и окошек на десктопе. Скорость явы и оверхед по памяти ну совсем не дотягивает до того что есть сейчас при использовании кривого Си++, который опять же многие ненавидят, но ничего лучше для решения этих задач пока нет.
Data Oriented Luddites
Data Oriented Luddites
Я на С++ пишу 2d игру под ифон, физика Box2d тоже написана на C++. Все ради скорости. Objective-C использую для UI проектов более 2ух лет, но для игр предпочту C++. Думаю такую красоту которую Кармак и Epic Games выжали из ифона не в последнюю очередь принадлежит C а может даже и C++ ). Так что они жили, живут и будут жить, еще меня переживут думаю ). Под PC увы не в курсе, но думаю там ситуация аналогична.
>Думаю такую красоту которую Кармак и Epic Games выжали из ифона не в последнюю очередь принадлежит C а может даже и C++
Из id software :)
и сейчас он уже предпочитает Си++, вот из твиттера «good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code.»©ID_AA_Carmack
Из id software :)
и сейчас он уже предпочитает Си++, вот из твиттера «good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code.»©ID_AA_Carmack
К вопросу о быстром прототипировании, и что, мол, на C++ просто программировать не умеют.
А на питоне вот за выходные сервер пишут, а не за 2 месяца: habrahabr.ru/blogs/python/78114/
Когда вы говорите о глупых ошибках, то на самом деле это зависит от человека пишущего код. Я написал клиента к memcache с нуля за 1 неделю, используя современный C++ стиль, и библиотека все еще используется в том месте, где я ее написал (подсказка: ищите по ключевому слову memcache++). Переписал сервер с нуля за два месяца, 1 месяц использовал для тестирования и улучшений, и это при том, что работал один — сервер может обрабатывать около 5k запросов в секунду (RPS), при этом используется не более 60% CPU и средняя нагрузка 2:1 для СPU. И мне трудно понять, почему многие испытывают сложно с++, когда мне удается делать подобные вещи.
А на питоне вот за выходные сервер пишут, а не за 2 месяца: habrahabr.ru/blogs/python/78114/
Тут часто путают С и С++. С это не подмножество С++. Это простой и законченный язык, на нем написаны linux, windows, интерпретаторы ruby, python и т.д. Он точно в скором времени не умрет, это как кроссплатформенный ассемблер. С++ это совсем другой язык.
Согласен на 100%. На сегодняшний день С и С++ — это совершенно разные языки программирования. Да, исторические корни С++ никуда не деть, но факт остаётся фактом: эти языки стандартизуются разными Комитетами и идут разными путями. Поэтому совет изучить С перед изучением С++ — это очень (ОЧЕНЬ) вредный совет.
«Ерунда всё это»
Господа, спокойствие, будущее за JavaScript.
Не забудьте про другой конец интернетного провода ;)
Там он тоже есть :)
я его преимущественно там и использую: nodejs.org =)
[sarcasm]Да, осталось написать node-cocoa, node-gtk, node-qt, переписать Darwin и Linux на JavaScript...[/sarcasm]
Вообще, node.js хорош, но у Erlang архитектура лучше. Все делается новыми процессами, они могут падать и это не затронет основной, есть hot swapping и т.д.
Вообще, node.js хорош, но у Erlang архитектура лучше. Все делается новыми процессами, они могут падать и это не затронет основной, есть hot swapping и т.д.
Меня смущает другое. что на все языки програмирования работа идет в пустую. люди пишут заново одни и теже действия — математику, интерпретацию… я не предлагаю взять один язык, я о том чтобы хотя бы для веба был один яп, но можно было подстраивать Синтаксис под себя.
Однако умно — опровергнуть кучу глупых нападок супротив С++ и тем самым как будто бы доказать свою правоту ))))
я пока вижу для С++ одну только нишу — написание компьютерных игр. А в операционные системы, кстати, этот удивительный язык обычно не пускают.
я пока вижу для С++ одну только нишу — написание компьютерных игр. А в операционные системы, кстати, этот удивительный язык обычно не пускают.
Почитал я комментарии, много думал. Пришлось перевести: habrahabr.ru/blogs/htranslations/111348/
Как Java-программист, который начинал с C и C++, напишу свое впечатление.
Java хорош для знакомства с концепциями ООП. Также его проще начать использовать «на полную», чем C++. В первую очередь это обусловлено не сложностью C++, а тем, что для Java имеется довольно большая стандартная библиотека с подробнейшими JavaDOC. И тем, что не нужно напрямую работать с указателями и памятью.
Прискорбно, но факт: научить говнокодера на Java гораздо проще, чем на C++, и ошибок на выходе будет сравнительно меньше. Среди начинающих программистов имеется тенденция «сначала сделать, потом подумать». И Java лучше этому соответствует. А затраты на подобных «специалистов» сравнительно маленькие, т.к. профессионал за такие копейки никогда не возьмется работать.
У Java-библиотек на текущий момент есть весомый плюс — подробное документирование. Любой framework либо имеет свою подробную документацию, tutorial'ы, start guide'ы и примеры, либо является имплементацией одного из стандартных API (а для Java их немало, те же J2EE API). Кстати, в свое время я именно поэтому выбрал Java, т.к. сложность поиска документации для библиотек C++ и последующих попыток использования была сравнительно выше.
Напротив, сложность C++ компенсируется его мощнейшими возможностями, например, полноценными шаблонами и мета-шаблонами. Их так не хватает в Java! Generic'и спасают только для простых случаев, а когда хочется по-максимому обобщить небольшой framework, вырастают гиганты, такие, что Generic'и уже не работают.
Для Java-программистов: при использовании конструкции вида A<B, T extends A<B, T>> возникает очень много проблем, которые при полноценных шаблонах просто не возникли бы.
Про сборщики мусора: все очень удобно, но до той поры, пока не начнутся утечки памяти. И тогда приходится так же снимать дампы, анализировать. А если из-за расточительного использования памяти начинаются несвоевременные вызовы full GC, то время отклика приложения может выйти за допустимые пределы. Так что голову никто не отменял, она нужна все зависимости от языка программирования.
Также нельзя забывать про то, что в наше время есть много профессиональных программистов как на C++, так и на Java. Быстро переучиться с одного на другое не получится, потребуются существенные затраты времени. И ошибки также будут неизбежны на первых порах. Так что команды программистов на C++ и на Java еще долгое время сосуществовать, хотя бы из-за этого фактора.
Кто победит в итоге? Думаю, что ни C++ и ни Java. На текущий момент наблюдается тендекция к объединению различных парадигм (функциональная, логическая, процедурная). Так что, скорее всего, в итоге останется несколько таких мультипарадигменных языков, а какие именно — сильно зависит от того, кто и как будет их продвигать.
Java хорош для знакомства с концепциями ООП. Также его проще начать использовать «на полную», чем C++. В первую очередь это обусловлено не сложностью C++, а тем, что для Java имеется довольно большая стандартная библиотека с подробнейшими JavaDOC. И тем, что не нужно напрямую работать с указателями и памятью.
Прискорбно, но факт: научить говнокодера на Java гораздо проще, чем на C++, и ошибок на выходе будет сравнительно меньше. Среди начинающих программистов имеется тенденция «сначала сделать, потом подумать». И Java лучше этому соответствует. А затраты на подобных «специалистов» сравнительно маленькие, т.к. профессионал за такие копейки никогда не возьмется работать.
У Java-библиотек на текущий момент есть весомый плюс — подробное документирование. Любой framework либо имеет свою подробную документацию, tutorial'ы, start guide'ы и примеры, либо является имплементацией одного из стандартных API (а для Java их немало, те же J2EE API). Кстати, в свое время я именно поэтому выбрал Java, т.к. сложность поиска документации для библиотек C++ и последующих попыток использования была сравнительно выше.
Напротив, сложность C++ компенсируется его мощнейшими возможностями, например, полноценными шаблонами и мета-шаблонами. Их так не хватает в Java! Generic'и спасают только для простых случаев, а когда хочется по-максимому обобщить небольшой framework, вырастают гиганты, такие, что Generic'и уже не работают.
Для Java-программистов: при использовании конструкции вида A<B, T extends A<B, T>> возникает очень много проблем, которые при полноценных шаблонах просто не возникли бы.
Про сборщики мусора: все очень удобно, но до той поры, пока не начнутся утечки памяти. И тогда приходится так же снимать дампы, анализировать. А если из-за расточительного использования памяти начинаются несвоевременные вызовы full GC, то время отклика приложения может выйти за допустимые пределы. Так что голову никто не отменял, она нужна все зависимости от языка программирования.
Также нельзя забывать про то, что в наше время есть много профессиональных программистов как на C++, так и на Java. Быстро переучиться с одного на другое не получится, потребуются существенные затраты времени. И ошибки также будут неизбежны на первых порах. Так что команды программистов на C++ и на Java еще долгое время сосуществовать, хотя бы из-за этого фактора.
Кто победит в итоге? Думаю, что ни C++ и ни Java. На текущий момент наблюдается тендекция к объединению различных парадигм (функциональная, логическая, процедурная). Так что, скорее всего, в итоге останется несколько таких мультипарадигменных языков, а какие именно — сильно зависит от того, кто и как будет их продвигать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О ненависти к С++