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

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

A>>99% тех, кто на нем пишет — это те что ниасилили С++.

BZ>а среди пишущих на C++ таких 100%


Нет, не 100%. Страуструп освоил C++.

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


AN>Нет, не 100%. Страуструп освоил C++.

Нет, он сказал, что знает на 8 что-ли.

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

E>1. В языке Си есть 3 непересекающихся (в отличии от C++) пространства имен — для struct, union, enum и глобальное для typedef.

Всегда это бесило. Кошмарно неудобно.

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

N>>>К тому же всякие драйвера для линуксов не пишутся на С++.
CC>>Причиной этому является ослиное упрямство ниасилившего Торвальдса. А мы в итоге сейчас в линуксячем кернеле жрём кактусы. Вбив бы!
N>Не думаю, что торвальдс, ведущий разработчик линукса, не осилил с++.
Ну он про С++ писал типичное для ниасиливших.

N> Да и написание драйверов не выглядит таким уж ужасом.
На С — банально много гемору. А в kernel ошибки приводят к более чем неприятным последствиям.

CC>>Под винду драйвера на С++ пишутся легко и приятно. С содроганием вспоминаю времена когда их по дурости пытались писать на С.
N>Майкрософт — это компания которая поддерживает с++ и развивает его куда больше чем все остальные.
Молодцы, чо.

E>>>>C11 когда приняли ? а когда появились всякие __sync_fetch_and_sub ?
C>>>И что дальше-то?
E>>Причинно-следственная связь.
C>А она есть. Сначала появился драфт в комитете С++, потом его принял комитет С.
А перед этим появились различные интересные функции в компиляторах для Си.

C>>>Всё ОК.
E>>Не позорься:
E>>1. В языке Си есть 3 непересекающихся (в отличии от C++) пространства имен — для struct, union, enum и глобальное для typedef. Твой код просто не соберется, ибо test_t не определен в глобальном пространстве имен. Он собрался бы, если бы ты написал struct test_t testit().
C>И що?
Не позорься, вот и то.

E>>2. Возвращать структурные типы стало можно в C99.
C>Бредишь. Это возможно чуть ли не с K&R C, точно было в C89. Классика жанра — возвращение структуры POINT в WinAPI.
1. Что я неприпоминаю, что там за функция в Win32 API возвращает POINT. Можеш напомнить ?
2. У микрософтовского компилятора есть свои специальные надстройки над языком. Еще расскажи тут, что uuidof является частью C++.

C>>>Нет, это полный список.
E>>Это не полный список, как минимум потому, что ты в него не включил даже того о чем написал сам.
C>Нету в С преимуществ.
Исходя из разговора с тобой, мне видно, что языка Си ты вообще-то незнаеш. Грубая путаница с C++.

C>>>Да ну?
E>>Именнно так:
C>Это не эквивалентный код. В Java используется reference-тип.
И там и там приведен код который обьекта — агрегата.

C>>>Про всякие int'ы вообще молчу.
E>>С интами как раз все прекрасно. Неиниуиализированые значения не приводят к падению.
C>

C>class fault_t
C>{
C>    int *ptr;
C>public:
C>    void do_something()
C>    {
C>         if (ptr) printf("%d\n", *ptr); //Whoopsie
C>    }
C>};
C>

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

C>>>Только что подрочил уже.
E>>Хм, просто показал что можно выстрелить себе в ногу можно в любом языке и развеял очередной миф.
C>В С это делается на порядки проще.
Куда уж проще чем в Java-то ? Тебя носом даже в пример потыкали.

C>>>Не разбухивают, по сравнению с макросами.
E>>Да ну ? Давай приводи сравнительный пример.
C>Создай пару контейнеров, разворачивающихся в static-функции.
В Си это делается на порядок проще. Но пример ты так и не привел, ожидаем-с.

E>>1. В языке Си есть 3 непересекающихся (в отличии от C++) пространства имен — для struct, union, enum и глобальное для typedef.
CC>Всегда это бесило. Кошмарно неудобно.
Ботинки жмут ?

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

CC>>>Причиной этому является ослиное упрямство ниасилившего Торвальдса. А мы в итоге сейчас в линуксячем кернеле жрём кактусы. Вбив бы!
N>>Не думаю, что торвальдс, ведущий разработчик линукса, не осилил с++.
CC>Ну он про С++ писал типичное для ниасиливших.
Линус пробовал С++ для ядра в середине 90-х, когда все компиляторы сосали по полной. В итоге в ужасе сбежал, что было вполне разумно на тот момент.

Ну а сейчас просто уже много кода на С написано, есть вся нужная инфраструктура, а многие ядерные разработчики не знают С++. Так что менять что-то сильного смысла нет (кроме того, в ядре куча структур с полями с именами типа "class" или "protected").

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


IV>>>Взяли C и прикрутили к нему сбоку ООП, типа это теперь высокоуровневый язык.
S>>ООП и на С без проблем реализуется. Во ядрах таких ОС как *BSD, Solaris, Linux-ООП ярко выраженный.
A>и в OpenSSL тоже. вот уж где хороший код

Да нормальный там код, даже обработка ошибок более-менее толково реализована. И даже утечек нет, если правильно хвосты зачищать. На плюсах, правда, все это раза в 3-4 компактнее получилось бы.

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

C>>А она есть. Сначала появился драфт в комитете С++, потом его принял комитет С.
E>А перед этим появились различные интересные функции в компиляторах для Си.
А перед этим появилась первая бактерия.

E>>>1. В языке Си есть 3 непересекающихся (в отличии от C++) пространства имен — для struct, union, enum и глобальное для typedef. Твой код просто не соберется, ибо test_t не определен в глобальном пространстве имен. Он собрался бы, если бы ты написал struct test_t testit().
C>>И що?
E>Не позорься, вот и то.
Я это знаю прекрасно, мне просто непонятно причём тут это.

E>>>2. Возвращать структурные типы стало можно в C99.
C>>Бредишь. Это возможно чуть ли не с K&R C, точно было в C89. Классика жанра — возвращение структуры POINT в WinAPI.
E>1. Что я неприпоминаю, что там за функция в Win32 API возвращает POINT. Можеш напомнить ?
В общем, я считаю, что ламеризм (воинствующее незнание) надо наказывать долларом. Так что предлагаю поспорить на $100, что в С89 есть возврат структур, аналогичный побайтному копированию.

C>>Нету в С преимуществ.
E>Исходя из разговора с тобой, мне видно, что языка Си ты вообще-то незнаеш. Грубая путаница с C++.
LOL.

C>>Это не эквивалентный код. В Java используется reference-тип.
E>И там и там приведен код который обьекта — агрегата.
ЩИТО? В Java все объекты — это reference-типы. Если бы в Java были value-типы, то тоже всё было бы как в С++.

C>>Оно скомпилируется и будет падать.
E>Как мы видим, здесь указатель, а не int. Какой неприкрытый фейл...
Можно и int, не вопрос:

int mode;
chmod("/some/file", mode); //Are you feeling lucky today?

E>>>Хм, просто показал что можно выстрелить себе в ногу можно в любом языке и развеял очередной миф.
C>>В С это делается на порядки проще.
E>Куда уж проще чем в Java-то ? Тебя носом даже в пример потыкали.
У тебя нос уже давно в навозе. В Java пишется так:

public class Test
{
   private final IdentityHashMap map;
   void do_something()
   {
      map.get("aa");
   }
};

Оно выдаст ошибку компиляции.

В чистом С пишется так:

struct list_t
{
    struct list_t *next;
    int payload;
};

struct something_t
{
    struct list_t head;
};

А потом ищутся баги с неинициализированным next.

C>>Создай пару контейнеров, разворачивающихся в static-функции.
E>В Си это делается на порядок проще. Но пример ты так и не привел, ожидаем-с.
Да ну?

#define LIST_CLAZZ(T,NM) \
    struct NM { struct NM* next; T payload; }; \
    static void add_to_#NM(NM* tail, T payload) {...};

"Методы" add_to... будут в каждом используемом файле инстанцироваться отдельно, за счёт static'а. Если static убрать, то получим конфликты времени связывания и/или неоптимальный код из-за отсутствия inlining'а.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>Здравствуйте, Abyx, Вы писали:


IV>>>>Взяли C и прикрутили к нему сбоку ООП, типа это теперь высокоуровневый язык.
S>>>ООП и на С без проблем реализуется. Во ядрах таких ОС как *BSD, Solaris, Linux-ООП ярко выраженный.
A>>и в OpenSSL тоже. вот уж где хороший код

ХГД>Да нормальный там код, даже обработка ошибок более-менее толково реализована. И даже утечек нет, если правильно хвосты зачищать. На плюсах, правда, все это раза в 3-4 компактнее получилось бы.

угу, компактнее и надежнее (те же баги типа вылезания за границы буфера, как у HeartBleed) ловились бы дебаг-итераторами
и можно было бы писать юнит тесты.

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

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

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

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

C>>>>Нет, это полный список.
E>>>Это не полный список, как минимум потому, что ты в него не включил даже того о чем написал сам.
C>>Нету в С преимуществ.
E>Исходя из разговора с тобой, мне видно, что языка Си ты вообще-то незнаеш. Грубая путаница с C++.

Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?

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

E>>>>1. В языке Си есть 3 непересекающихся (в отличии от C++) пространства имен — для struct, union, enum и глобальное для typedef. Твой код просто не соберется, ибо test_t не определен в глобальном пространстве имен. Он собрался бы, если бы ты написал struct test_t testit().
C>>>И що?
E>>Не позорься, вот и то.
C>Я это знаю прекрасно, мне просто непонятно причём тут это.
Очень хорошо, что ты знаеш это прекрасно. Осталось совсем малое — писать код без ошибок.

E>>>>2. Возвращать структурные типы стало можно в C99.
C>>>Бредишь. Это возможно чуть ли не с K&R C, точно было в C89. Классика жанра — возвращение структуры POINT в WinAPI.
E>>1. Что я неприпоминаю, что там за функция в Win32 API возвращает POINT. Можеш напомнить ?
Итак, какая функция в WinAPI возвращает POINT ?

C>В общем, я считаю, что ламеризм (воинствующее незнание) надо наказывать долларом. Так что предлагаю поспорить на $100, что в С89 есть возврат структур, аналогичный побайтному копированию.
Вот и начни с себя. Потрать доллары на своё образование.

C>>>Нету в С преимуществ.
E>>Исходя из разговора с тобой, мне видно, что языка Си ты вообще-то незнаеш. Грубая путаница с C++.
C>LOL.
Ага, ЛОЛ.

C>>>Это не эквивалентный код. В Java используется reference-тип.
E>>И там и там приведен код который обьекта — агрегата.
C>ЩИТО? В Java все объекты — это reference-типы. Если бы в Java были value-типы, то тоже всё было бы как в С++.
Если у бабушки был бы член, она была бы дедушкой. Но в обоих случаях осталась бы престарелым человеком. Так и в случае с агрегатными обьектами.

C>>>Оно скомпилируется и будет падать.
E>>Как мы видим, здесь указатель, а не int. Какой неприкрытый фейл...
C>Можно и int, не вопрос:
C>

C>int mode;
C>chmod("/some/file", mode); //Are you feeling lucky today?
C>

1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
2. Этот код также не упадет.

E>>>>Хм, просто показал что можно выстрелить себе в ногу можно в любом языке и развеял очередной миф.
C>>>В С это делается на порядки проще.
E>>Куда уж проще чем в Java-то ? Тебя носом даже в пример потыкали.
C>У тебя нос уже давно в навозе.
Ты свой нос с чужим не путай.

C>В Java пишется так:
А в С++ пишется по другому. И в обоих языках можно элементарно выстрелить себе в ногу.

C>В чистом С пишется так:
C>

C>struct list_t
C>{
C>    struct list_t *next;
C>    int payload;
C>};

C>struct something_t
C>{
C>    struct list_t head;
C>};
C>

C>А потом ищутся баги с неинициализированным next.
ЛОЛ, Что ?

C>>>Создай пару контейнеров, разворачивающихся в static-функции.
E>>В Си это делается на порядок проще. Но пример ты так и не привел, ожидаем-с.
C>Да ну?
C>

C>#define LIST_CLAZZ(T,NM) \
C>    struct NM { struct NM* next; T payload; }; \
C>    static void add_to_#NM(NM* tail, T payload) {...};
C>

C>"Методы" add_to... будут в каждом используемом файле инстанцироваться отдельно, за счёт static'а. Если static убрать, то получим конфликты времени связывания и/или неоптимальный код из-за отсутствия inlining'а.
Теперь напиши пример в templates и сравни как будут инстанцироваться методы.

C>>>>>Нет, это полный список.
E>>>>Это не полный список, как минимум потому, что ты в него не включил даже того о чем написал сам.
C>>>Нету в С преимуществ.
E>>Исходя из разговора с тобой, мне видно, что языка Си ты вообще-то незнаеш. Грубая путаница с C++.

ХГД>Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?
На затравку ты можеш начать медитацию с именоваными инициализаторами без затрат на конструирование обьектов в рантайме.

Здравствуйте, CreatorCray, Вы писали:
CC>Ну он про С++ писал типичное для ниасиливших.
Что например?

CC>На С — банально много гемору.
Какого?
CC>А в kernel ошибки приводят к более чем неприятным последствиям.
Всегда так.

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

A>нет, конечно они не совместимы на все 100%.
A>в С есть еще есть опасные вещи типа неявного каста void* в любой тип.

СИ это своего рода асемблер, то есть это не опасные вещи, а просто необходимые.
В асемблере вообще BYTE,WORD,DWORD,QWORD....
На си пишется все для ядра виндов, и линукса и прочие ядра.
То есть для того что бы не делать ошибок на СИ нужна выскокая квалификация програмиста, а на С++ можно избежать ошибок и используя менее квалифицированную рабсилу.

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

ХГД>>Эээ, а список преимуществ таки будет или это только повод обвинить собеседника в невежестве?
E>На затравку ты можеш начать медитацию с именоваными инициализаторами без затрат на конструирование обьектов в рантайме.

ок, 1 элемент списка есть, а еще?
ты не стесняйся, пиши все сразу

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

S>>Осилить C++ -пара недель почитывания стандарта.
CC>Удачи!

А что там такого сложного?
ИМХА указатели в СИ по уровню сложности понимания сложнее, чем все в С++.
То есть даже ссылки там придумали чтобы народу было проще. ))

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

CC>Здравствуйте, -n1l-, Вы писали:

N>>К тому же всякие драйвера для линуксов не пишутся на С++.
CC>Причиной этому является ослиное упрямство ниасилившего Торвальдса. А мы в итоге сейчас в линуксячем кернеле жрём кактусы. Вбив бы!
CC>Под винду драйвера на С++ пишутся легко и приятно. С содроганием вспоминаю времена когда их по дурости пытались писать на С.

1)Не все, 2) не всегда можно использовать кучу вещей из С++.

Или вы имете ввиду расширенный синтаксис С++?
Ну дык эти как СИ с классами. Это не С++.

U>>В ядре нет поддержки C++ runtime и есть некоторые ограничения на код сгенирированный компилятором, которые затрудняют написание драйверов на C++. Их пишут на C, потому что выбора нет.
A>можно писать на подмножестве С++, которое не требует рантайма и каких-то фич которые плохо работают в ядре.
Можно.

A>это будет очень большое подмножество со многими полезными фичами.
Это будет очень маленькое подмножество — "Си с классами и темплайтами" без какой-либо стандартной библиотеки вообще. Все остальное из С++ выпиливается всед за запретом RTTI, которое тянеят за собой исключения и все остальное.

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