Думаю по скорости плюсы будут однозначно быстрее

это смотря в каких задачах. :)

но проще писать полюбому на С

это смотря в каких задачах. :)

ещё нужно учитывать кто пишет

> это смотря в каких задачах. :)
Да по идеи в любых.
И да, я имел ввиду скорость разработки.

это смотря в каких задачах. :)

Риччи (если не ошибаюсь) в каком-то интервью говорил что писать на языке попроще всегда проще.

>И да, я имел ввиду скорость разработки.

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

Я и не говорил что он будет. Итог: С еще долго не выбросят. В отличии от С++.

C++ тоже, ибо альтернатив пока не видно. Точнее есть, Ди называется, но оно пока в зачаточном состоянии.

В питоне с исключениями проблем нет.

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

Паттерн Visitor спасет отца русской демократии

>>Однако си прост как бревно, а вот с плюсами можно попасть на хитрость языка, и мучаться довольно долго.

не всегда простой как бревно язык подходит для реальныз проектов. Посмотри на gtk с его GSEAL и прочим бредом, лишь бы С++ не использовать.

Ну да. Тем более, что на чистом Си можно писать в ООП-стиле :) Но зачем, когда есть Си++, подходящий для этого лучше?

Я не пишу на сях в ООП-стиле, читай внимательнее. А при работе с железом нафиг С++ не нужно: там нет таких задач, где этот язык бы пригодился.

Reset

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

Что, я calloc'ом пользоваться не умею? :)

И я не считаю комбинации calloc - free траханьем, по сравнению с описанием ненужных классов и их конструкторов/деструкторов. Тем более, что calloc и new в моем случае - одно и то же, равно как и free и delete.

> По скорости хорошо написанная программа на С++ такая же или быстрее, чем на С.

Откуда такие выводы? Я вот не вижу ни единого «ускоряющего» фактора, зато замедляющих море. Может капитан пояснит, что он имеет в виду?

И не лень тебе каждый раз думать в какой момент надо память освобождать и руками всё это дергать? По-моему такие вещи только отвлекают от решения задачи. И классы не всегда надо описывать, обычно всё уже есть в STL. Если нужен обычный массив, то пишем vector < double > A (10000), потом его спокойно можно передать в C/Fortran часть, а об освобожении и выделении памяти пусть думает компилятор.

А на счет STL значит спорить не будешь?

А ты знаешь почему std::sort быстрее чем qsort ? Вот потому же STL контейнеры быстрее чем контейнеры из glib и шаблоны быстрее функций, которые работают с void * и указателями на функции.

А на счет STL значит спорить не будешь?

Не буду. Но, повторю еще раз: мне нет смысла пользоваться С++. Я уже пытался пару раз свои сишные программы на С++ переписать. Понял, что смысла нет.

Ага, работа с железом это тупое чтение и запись регистров, тут действительно Си++ не нужен.

А ты знаешь почему std::sort быстрее чем qsort ?

Быть такого не может. Единственный вариант: в std::sort используется более быстрый алгоритм. Но я вообще предпочитаю не пользоваться стандартными функциями: для моих случаев есть хорошие шаблоны в «Numerical receipes» :)

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

Быть такого не может.

Это давно установленный факт, который неоднократно обсуждался на лоре. std::sort не использует косвенную адресацию и может быть заинлайнен.

Использовать С++ в задачах, где можно обойтись С, все равно, что микроскопом гвозди заколачивать.

Во всех задачах можно обойтись C и даже ассемблером, но нафиг нужны такие мучения?

но нафиг нужны такие мучения?

Мучения? Недавно на ЛОРе была тема по поводу printf и std::cout. Я придерживаюсь принципа минимизации объема кода, и простоты его чтения. С++ нужен, чтобы не писать, например,

void cmul(complex a, complex b, complex *ans){
     ans->re = a.re*b.re - a.im*b.im;
     ans->im = a.re*b.im + a.im*b.re;
}

В остальных случаях С++ только вредит.

...тем, кто ниасилил.

Я уже привел случаи, которые отличаются от этого и наоборот помогают.

Щас подвалит тяжелая артиллерия и расскажет нам, что стандарт не реализован :)

>Использовать С++ в задачах, где можно обойтись С, все равно, что микроскопом гвозди заколачивать.

Использовать С в тех задачах, где можно обойтись магнитной иголкой - ещё хуже.

По-моему, стандарт на Си в разы тоньше стандарта на С++. Точный объём не скажу чтобы не соврать, щас исать лень. Поправь если ошибаюсь.

> что С надо использовать при более-менее низкоуровневом программировании

далеко не под всякое железо есть плюсовые компиляторы

Короче, Reset, хватить спорить: каждой вещи свое место. Странно, что до сих пор не вклинились лисперы :)

Странно, что до сих пор не вклинились лисперы :)

Они уже спят, зубами к стенке :)

По-моему, стандарт на Си в разы тоньше стандарта на С++.

Если не изменяет склероз, C где-то 550стр., С++ 790

А только ans=a*b

аналогом ans = a * b тут будет cmul(a, b, &ans), а не то, что ты написал

аналогом ans = a * b тут будет cmul(a, b, &ans), а не то, что ты написал

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

Насчёт исключений, скользкий вопрос. Даже в языках с супер-нативно-современной поддержкой (типа Java/C#) мне не понятно, больше вреда или пользы от них. Основная проблема - перестаёшь думать, кинул исключение и всё, ловите. Плюс, на семь бед один ответ - какой-нибудь InvalidArgument, т.к. на разные ситуации создавать разные классы эксепшном намного неудобнее, чем коды ошибок. В тексте разница есть, но его что, парсить, что ли.

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

Однако, с любовью индусов к catch-all и это уже не аргумент в пользу эксепшнов.

1.1 Scope
This International Standard specifies requirements for implementations of the C++ programming language.
The first such requirement is that they implement the language, and so this International Standard also
defines C++. Other requirements and relaxations of the first requirement appear at various places within this
International Standard.
C++ is a general purpose programming language based on the C programming language as described in
ISO/IEC 9899:1990 Programming languages – C (1.2). In addition to the facilities provided by C, C++
provides additional data types, classes, templates, exceptions, namespaces, inline functions, operator over-
loading, function name overloading, references, free store management operators, and additional library
facilities.
1.2 Normative references
ISO/IEC 2382 (all parts), Information technology – Vocabulary
ISO/IEC 9899:1999, Programming languages – C
ISO/IEC 10646-1:2000, Information technology – Universal Multiple-Octet Coded Character Set
(UCS) – Part 1: Architecture and Basic Multilingual Plane
The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is here-
inafter called the Standard C Library.¹⁾

The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.



__________________
1)
With the qualifications noted in clauses 17 through 27, and in C.2, the Standard C library is a subset of the Standard C++ library.

>Тем не менее ООП хорош не везде

Безусловно. Но я говорил не о «всеобщей хорошести ООП», а о том, что нечёткое выделение сущности объекта - обычно проблема проработки идеологии, а не особенность проекта :)

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

«Умные функции» (которые меняют своё поведение в зависимости от типов входящих данных) - страшное зло. В Форте, например, это ещё в 1980-м поняли и в ANS Forth 83 начали от них избавляться :)

Функция должна быть простой. Тогда её проще писать и легче отлаживать.

>Помнится, ты утверждал что они не нужны, причем упорно.

Я утверждал, что не вижу в них надобности в своих проектах. Это немного не то, что «они не нужны» ;)

Что таки поменялось?:)

Наверное, моя чаша ещё не до конца наполнилась :-p Программист тогда может считаться программистом, когда он открыт для новых идей, методов, технологий. Но при этом программист может считаться опытным программистом только тогда, когда он новые идеи, методы, технологии применяет только после тщательного рассмотрения и внимательной критики :D

...

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

1. Примеры аналогичные qsort как уже сказали.

2. Исключения.

3. Вообще в С++ больше функций будет инлайниться, т.к. функции нередко в хедерах описываются.

4. Когда на С эмулируются объекты, это точно медленнее С++.

> Частично макросы

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

>Да и отлаживать портянку из макросов, в случае Ё, не сильно легче, чем код с шаблонами.
Хм. отлаживать макросы?

аналог map это tree.h из *bsd, но отлаживать это невозможно

«Умные функции» (которые меняют своё поведение в зависимости от типов входящих данных) - страшное зло

Если говорить об ООП, я имел ввиду мультиметоды. Почему же они зло?

Да и даже без них такой вариант:

def foo (x):
    if type (x) == class1:
        dothis (x)
    elif type(x) == class2:
        dothat (x)

Лучше, чем

class class1:
.......
    def foo()
.....
class class2:
    def foo()

Так в 1 случае нужно поправить 1 место в программе, а во 2 - столько мест, сколько разных классов эта функция должна обрабатывать. Это моё мнение быдлокодера)

Эти вопросы обычно решаются через полиморфизм.

> По-моему, стандарт на Си в разы тоньше стандарта на С++

Не читал стандарт Си++ :) Понятно, что Си++ очень сложен, и стандарт должен быть толще, но пойнт в том, что сам Си не прост. Простой язык - это Паскаль первой версии.

2. Исключения.

Здесь же показывали, что они очень медленные.

3. Вообще в С++ больше функций будет инлайниться, т.к. функции нередко в хедерах описываются.

В C это будут макросы, а может и те же инлайн-функции.

4. Когда на С эмулируются объекты, это точно медленнее С++.

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

Ерунда, C - очень простой язык (в плане освоения, в плане разработки нужно всё хорошо продумать, чтобы потом не запутаться). Единственное, с чем могут быть проблемы - с указателями, которые могут ссылаться не туда, куда бы вам хотелось и с утечкой памяти. Приходится отвлекаться на такие мелочи, что несколько не удобно.

2. Исключения.

Здесь же показывали, что они очень медленные.

Ссылку в студию. Которая показыавет, что код с исключениями при нормальном выполнении программы (т.е. когда исключения не бросаются) намного медленнее кода с проверкой return value практически каждой вызываемой функции.

3. Вообще в С++ больше функций будет инлайниться, т.к. функции нередко в хедерах описываются.

В C это будут макросы, а может и те же инлайн-функции.

Макросы вместо функций это что то кошмарное. С инлайн-функциями ступил, я думал их в С нет, оказывается в С99 ввели.

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

Потому что компилятор в случае С++ понимает, что делает программист, у него больше пространства для оптимизаций.

> Ерунда, C - очень простой язык (в плане освоения

Хелловорлды на любом языке простые.

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

Такой вот он - простой Си.

Ликбез

Хм, правильно я понимаю, что inline функции - те же макросы, только их аргументы вычисляются прежде, чем передаться этой функции.

Т.е.

#define MUL (a, b) a*b

inlune int mul (int a, int b) {return a*b;}

MUL (2+2,4+5) == 15

mul (2+2, 4+5) == 36

И ещё читал, что inline - только «рекомендация» компилятору, что он сам выбирает, делать ли функцию inline или «обыкновенной». Интересно, по какому критерию.

А то я этот C99 фигово знаю

Хелловорлды на любом языке простые.

Нифига)

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

Что, простой?

Такой вот он - простой Си.

Дык, любой проект надо продумывать, тут чуть больше (что у меня, правда, мало вышло, когда я писал игру)

> public class HelloWorld { public static void main(String[] args) { System.out.println(«Hello world!»); } }

Что, простой?

Да. Многословный, но простой.

Такой вот он - простой Си.

Дык, любой проект надо продумывать, тут чуть больше

Ага. Изобрести, например, объектную систему (как сделали в GTK) - как раз «чуть больше».

C - не простой, в нем очень много неочевидностей, если не вчитываться в толстый стандарт. Особенно если нужна кроссплатформенность.

http://linuxdude.com/Steve_Sumit/C-faq/top.html