А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

Если в связке C + Java/Python/whatever то достаточно.

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

Разные области применения.
C — в микроконтроллеры и подобное "встраиваемое".
C++ — всё ж повыше.

Линуксовое ядро — C.
Верхний уровень вроде того же Qt — C++.

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


M>Если в связке C + Java/Python/whatever то достаточно.

Да, в связке.

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

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

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

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

Java не нужен.
99% тех, кто на нем пишет — это те что ниасилили Scala.
что какбэ намекает на то, что люди не способные осилить язык никому не нужны.
тем более что есть строгая корреляция между знанием языка и знанием различных технологий и практик программирования.

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

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

Осилить C++ -пара недель почитывания стандарта. Это написавшие ZFS С++ не осилили?
Вообще С++ это для сотрудников всяких Pupkin Ink. пишущих на С++ по неспособности изучить что-то
сложнее стандарта C++, и думающих, что их жалкие, доморощенные, для пропихивания откатами, поделки,
есть вершины инженерного творчества.

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

R>Java не нужен.
Java конечно не нужна

R>99% тех, кто на нем пишет — это те что ниасилили Scala.
только C vs C++ не имеет никакого отношения к Java vs Scala.
Java и Scala — это разные языки для одной платформы, как например Delphi, С++ и D, или C# и VB.

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

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

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

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

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

A>А С — это просто урезанный С++

facepalm

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++?
можно
более того, можно и не знать, но утверждать, что ты программист

R>Вообще, насколько важно знать С++ или достаточно только С?
для разработки различных ядер систем и системного ПО, драйверов или программирования микроконтроллеров обычно достаточно

R>Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.
дело в сфере применения, а не стране

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

A>А С — это просто урезанный С++

Май твиттер ваз хакд? Вы ещё скажите, что C полностью совместим по синтаксису с C++.

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

A>>А С — это просто урезанный С++

MD>Вы ещё скажите, что C полностью совместим по синтаксису с C++.

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

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

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

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

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

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

Скорее C++ не нужен.
С — отличный низкоуровневый язык для написания драйверов, прошивок и критичных к скорости выполнения участков программы, вообщем, там, где нужен маленький размер без кучи ненужных библиотек или скорость.
Например, в программе есть критичный к скорости выполнения или размеру кода участок, можно использовать какую-нибудь стороннюю библиотеку, в которой будет куча лишнего кода для решения конкретной задачи, а можно написать велосипед на C, который будет меньше и работать быстрее.
А высокоуровневые задачи пишутся на высокоуровневом же языках, например, на Java, C# и т.д.

А C++ — это попытка скрестить ужа с ежом, два разных подхода, служащих для решения разных задач.
Взяли C и прикрутили к нему сбоку ООП, типа это теперь высокоуровневый язык.
В результате язык потерял в скорости, увеличился размер стандартных библиотек, как следствие — потерял Сишную нишу(драйвера и т.д.).
И как высокоуровневый язык получился кривой, переусложнённый, с кучей подводных камней и т.д., в результате для написания прикладных программ от него сейчас отказываются.
Это всё равно что на Газель поставить двигатель от спорткара, чтобы на ней и грузы можно было возить, и ночью с пацанами погоняться. Лучше уж иметь два отдельных инструмента для решения разных задач(отдельно грузовик и отдельно спорткар).

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

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


IV>Скорее C++ не нужен.

Плюсую.

IV>Взяли C и прикрутили к нему сбоку ООП, типа это теперь высокоуровневый язык.

ООП и на С без проблем реализуется. Во ядрах таких ОС как *BSD, Solaris, Linux-ООП ярко выраженный.

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

IV>Скорее C++ не нужен.
IV>С — отличный низкоуровневый язык для написания драйверов, прошивок и критичных к скорости выполнения участков программы, вообщем, там, где нужен маленький размер без кучи ненужных библиотек или скорость.
маленький размер чего?
IV>Например, в программе есть критичный к скорости выполнения или размеру кода участок, можно использовать какую-нибудь стороннюю библиотеку, в которой будет куча лишнего кода для решения конкретной задачи, а можно написать велосипед на C, который будет меньше и работать быстрее.
ну если он меньше, то он может хоть толще?

IV>А C++ — это попытка скрестить ужа с ежом, два разных подхода, служащих для решения разных задач.
IV>Взяли C и прикрутили к нему сбоку ООП, типа это теперь высокоуровневый язык.
IV>В результате язык потерял в скорости, увеличился размер стандартных библиотек, как следствие — потерял Сишную нишу(драйвера и т.д.).
конечно полиморфизм делает код медленнее, особенно статический.
IV>И как высокоуровневый язык получился кривой, переусложнённый, с кучей подводных камней и т.д., в результате для написания прикладных программ от него сейчас отказываются.
лямбда выражения опять же придумали всякие непонятные... то ли дело старые добрые указатели на функции. особенно в плане производительности.
эх, коллега, вы не представляете как же приятно пообщаться с экспертом

IV>Единственная ниша C++ — с одной стороны достаточно большие приложения, чтобы их писать целиком на C, с другой стороны, требовательные к скорости выполнения кода(например, геймдев, и то не весь).
эээ что? т.е. ты тоже согласен что С только для hello-world-ов?

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

IV>>Скорее C++ не нужен.
S>Плюсую.
ко-ко-ко

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

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

A>и в OpenSSL тоже. вот уж где хороший код

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

A>А С — это просто урезанный С++, по этому если ты знаешь С, но не знаешь С++,
Что за ерунду ты пишеш. Языки изначально были несовпадающим множеством, а сейчас еще больше и разошлись в разные стороны.

A>то для меня это выглядит так, что ты — программист С++, который
A>- использует минимум возможностей языка и не способен писать выразительный, идиоматичный код
В C99 есть такие возможности которые в C++ и не снились.

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

A>- не в состоянии нормально применять ООП и ФП там где это надо
Это известное заблуждение. На самом деле ООП практически не зависит от используемого языка. Нет никаких принципиальных проблем в том, чтобы применять ООП на языке Си.
Элементы обобщенного програмирования в Си тоже можно неплохо применять, а частности — первые наброски Степановом того, что сейчас называется STL были сделаны на Си, довольно оригинальным способом.

A>- не может писать нормальные юнит-тесты
Ну конечно. Идеология юнит тестирования вообще никак не опирается на язык — можно использовать любой. Для тоже Си есть куча библиотек в помощь для организации тестировнаия.

A>- пишет огромное количество бойлерплейта, в коммитах огромные диффы, это тяжело читать/ревьювить
Диф между linux kernel и FreeBSD kernel тоже огромный — его тяжело читать и ревьювить!

A>С не нужен.
A>99% тех, кто на нем пишет — это те что ниасилили С++.
A>что какбэ намекает на то, что люди не способные осилить язык никому не нужны.
* У языка С++ есть обьективные проблемы с переносимостью и маштабируемостью получаемого решения. В пределах группы из платформ с более-менее одинаковыми характеристиками этих проблемы иногда не так заметны, но как только характеристики платформы начинают отличаться хоты бы на порядок — все эти проблемы вылезают.
* У языка Си такие проблемы тоже конечно есть, но в совершенно другом маштабе, побороть который уже предстааляется возможным. Ну и сама рантайм библиотека на несколько порядков проще — производителям "железа" не представляется сложным её портировать или реализовать в отличии от libstdc++. В добавок к этому, ABI для языка Си более консервативное, оно не меняется даже при изменении основной цифры версии (в отличии от ABI С++ которое меняется даже при изменении minor цыфры версии). Поэтому, хочеш быть максимально переносимым между платформами — пиши только на Си. Собственно, так многие и делают.

A>тем более что есть строгая корреляция между знанием языка и знанием различных технологий и практик программирования.
В среде опытных разработчиков — такой корреляции нету.

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

A>>А С — это просто урезанный С++, по этому если ты знаешь С, но не знаешь С++,
E>Что за ерунду ты пишеш. Языки изначально были несовпадающим множеством, а сейчас еще больше и разошлись в разные стороны.
Да ну? Почему atomics в С тогда взяли из С++? Точнее, они совместно работали.

Единственным крупным расхождением являются именованные поля в инициализаторах структур и мелочи типа variable-sized arrays.

A>>то для меня это выглядит так, что ты — программист С++, который
A>>- использует минимум возможностей языка и не способен писать выразительный, идиоматичный код
E>В C99 есть такие возможности которые в C++ и не снились.
ЩИТО?

A>>- предпочитает использование небезопасных конструкций языка
E>В любом языке есть небезопасные конструкции, даже в той же Java выстрелить себе в ногу гораздо проще и потом часами искать ошибку — Например, можно просто забыть создать экземпляр класса какой нибудь коллекции в конструкторе.
ЩИТО?

E>Элементы обобщенного програмирования в Си тоже можно неплохо применять, а частности — первые наброски Степановом того, что сейчас называется STL были сделаны на Си, довольно оригинальным способом.
Ага, через макросы.

Но в РФ за это знание платить будут мало.

A>>>А С — это просто урезанный С++, по этому если ты знаешь С, но не знаешь С++,
E>>Что за ерунду ты пишеш. Языки изначально были несовпадающим множеством, а сейчас еще больше и разошлись в разные стороны.
C>Да ну? Почему atomics в С тогда взяли из С++? Точнее, они совместно работали.
Ты ничего не путаеш ? Атомарные переменные пришли в С++ из Си. Например sig_atomic_t вообще древний тип из стандарта POSIX.

C>Единственным крупным расхождением являются именованные поля в инициализаторах структур и мелочи типа variable-sized arrays.
Не только.

A>>>то для меня это выглядит так, что ты — программист С++, который
A>>>- использует минимум возможностей языка и не способен писать выразительный, идиоматичный код
E>>В C99 есть такие возможности которые в C++ и не снились.
C>ЩИТО?
Ага.

A>>>- предпочитает использование небезопасных конструкций языка
E>>В любом языке есть небезопасные конструкции, даже в той же Java выстрелить себе в ногу гораздо проще и потом часами искать ошибку — Например, можно просто забыть создать экземпляр класса какой нибудь коллекции в конструкторе.
C>ЩИТО?
Ага. И главное super вызывать не забывай.

E>>Элементы обобщенного програмирования в Си тоже можно неплохо применять, а частности — первые наброски Степановом того, что сейчас называется STL были сделаны на Си, довольно оригинальным способом.
C>Ага, через макросы.
Работает и работает неплохо.

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

C>>Да ну? Почему atomics в С тогда взяли из С++? Точнее, они совместно работали.
E>Ты ничего не путаеш ? Атомарные переменные пришли в С++ из Си. Например sig_atomic_t вообще древний тип из стандарта POSIX.
Нет, не путаю. RTFM стандарты.
Вот статьи с обзором: https://lwn.net/Articles/586838/ и https://lwn.net/Articles/588300/

Фактически, это кодификация разных барьерных intrinsinc'ов и CAS-операций, которые раньше делались расширениями компиляторов.

C>>Единственным крупным расхождением являются именованные поля в инициализаторах структур и мелочи типа variable-sized arrays.
E>Не только.
А что ещё?

A>>>>- использует минимум возможностей языка и не способен писать выразительный, идиоматичный код
E>>>В C99 есть такие возможности которые в C++ и не снились.
C>>ЩИТО?
E>Ага.
Я весь внимание. Можно список?

E>>>В любом языке есть небезопасные конструкции, даже в той же Java выстрелить себе в ногу гораздо проще и потом часами искать ошибку — Например, можно просто забыть создать экземпляр класса какой нибудь коллекции в конструкторе.
C>>ЩИТО?
E>Ага. И главное super вызывать не забывай.
Можно пример? Вообще-то, super() выполняется автоматически.

E>>>Элементы обобщенного програмирования в Си тоже можно неплохо применять, а частности — первые наброски Степановом того, что сейчас называется STL были сделаны на Си, довольно оригинальным способом.
C>>Ага, через макросы.
E>Работает и работает неплохо.
Плохо. Криво, без частичной специализации и без многих оптимизаций.

C>>>Да ну? Почему atomics в С тогда взяли из С++? Точнее, они совместно работали.
E>>Ты ничего не путаеш ? Атомарные переменные пришли в С++ из Си. Например sig_atomic_t вообще древний тип из стандарта POSIX.
C>Нет, не путаю. RTFM стандарты.
C>Вот статьи с обзором: https://lwn.net/Articles/586838/ и https://lwn.net/Articles/588300/
C>Фактически, это кодификация разных барьерных intrinsinc'ов и CAS-операций, которые раньше делались расширениями компиляторов.
Стандарты разные бывают. Ко всему прочему есть де-факто стандарты.


C>>>Единственным крупным расхождением являются именованные поля в инициализаторах структур и мелочи типа variable-sized arrays.
E>>Не только.
C>А что ещё?
Много чего. Возврат структурных типов из функций, например.

A>>>>>- использует минимум возможностей языка и не способен писать выразительный, идиоматичный код
E>>>>В C99 есть такие возможности которые в C++ и не снились.
C>>>ЩИТО?
E>>Ага.
C>Я весь внимание. Можно список?
Ты можеш составить его сам.

E>>>>В любом языке есть небезопасные конструкции, даже в той же Java выстрелить себе в ногу гораздо проще и потом часами искать ошибку — Например, можно просто забыть создать экземпляр класса какой нибудь коллекции в конструкторе.
C>>>ЩИТО?
C>Можно пример?

public class AAA {
    public AAA( ... ) {
        //nodes = new IdentityHashMap();
    }

    public void selectAll(boolean tag) {
        for (Node node: nodes.values()) {
            node.select = tag;
        }
    }

    public void addNode(String id, Node node) {
        nodes.put(id, node);
    }

    IdentityHashMap<String, Node> nodes;
};

C>Вообще-то, super() выполняется автоматически.
Возможно.


E>>>>Элементы обобщенного програмирования в Си тоже можно неплохо применять, а частности — первые наброски Степановом того, что сейчас называется STL были сделаны на Си, довольно оригинальным способом.
C>>>Ага, через макросы.
E>>Работает и работает неплохо.
C>Плохо. Криво, без частичной специализации и без многих оптимизаций.
Никто не говорил что будут все фишки, а работает нормально и с хорошей оптимизацией.

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

C>>Фактически, это кодификация разных барьерных intrinsinc'ов и CAS-операций, которые раньше делались расширениями компиляторов.
E>Стандарты разные бывают. Ко всему прочему есть де-факто стандарты.
Вот в С11 их взяли из С++.

E>>>Не только.
C>>А что ещё?
E>Много чего. Возврат структурных типов из функций, например.
Не позорься, а?

E>>>>>В C99 есть такие возможности которые в C++ и не снились.
C>>>>ЩИТО?
E>>>Ага.
C>>Я весь внимание. Можно список?
E>Ты можеш составить его сам.
Вот полный список:

- пусто -

C>>Можно пример?
E>

E>public class AAA {
E>    public void selectAll(boolean tag) {
E>        for (Node node: nodes.values()) {
E>            node.select = tag;
E>        }
E>    }
E>    public void addNode(String id, Node node) {
E>        nodes.put(id, node);
E>    }
E>    IdentityHashMap<String, Node> nodes = new IdentityHashMap();
E>};
E>

И всё. В отличие от С, в Java доступны нетривиальные in-place конструкторы. Тем более, что такая ошибка — это вообще из стиля "ну вот я тут забыл написать весь код и оно ничего не работает".

C>>Плохо. Криво, без частичной специализации и без многих оптимизаций.
E>Никто не говорил что будут все фишки, а работает нормально и с хорошей оптимизацией.
Работает плохо, и разбухивает код. Не говоря уж о сплошных ODR-нарушениях при попытках оптимизировать.

C>>>Фактически, это кодификация разных барьерных intrinsinc'ов и CAS-операций, которые раньше делались расширениями компиляторов.
E>>Стандарты разные бывают. Ко всему прочему есть де-факто стандарты.
C>Вот в С11 их взяли из С++.
C11 когда приняли ? а когда появились всякие __sync_fetch_and_sub ?

E>>>>Не только.
C>>>А что ещё?
E>>Много чего. Возврат структурных типов из функций, например.
C>Не позорься, а?
Да это ты не позорься, если не знал.

E>>>>>>В C99 есть такие возможности которые в C++ и не снились.
C>>>>>ЩИТО?
E>>>>Ага.
C>>>Я весь внимание. Можно список?
E>>Ты можеш составить его сам.
C>Вот полный список:
C>

C>- пусто -
C>

Не в состоянии составить список ?

C>>>Можно пример?
E>>

E>>public class AAA {
E>>    public void selectAll(boolean tag) {
E>>        for (Node node: nodes.values()) {
E>>            node.select = tag;
E>>        }
E>>    }
E>>    public void addNode(String id, Node node) {
E>>        nodes.put(id, node);
E>>    }
E>>    IdentityHashMap<String, Node> nodes = new IdentityHashMap();
E>>};
E>>

C>И всё. Тем более, что такая ошибка — это вообще из стиля "ну вот я тут забыл написать весь код и оно ничего не работает".
Дело в том, что в C++ такую ошибку допустить в принципе нельзя.

C>В отличие от С, в Java доступны нетривиальные in-place конструкторы.
Мне абсолютно побоку на "нетривиальные in-place конструкторы", я на них не надрачиваю.

C>>>Плохо. Криво, без частичной специализации и без многих оптимизаций.
E>>Никто не говорил что будут все фишки, а работает нормально и с хорошей оптимизацией.
C>Работает плохо, и разбухивает код. Не говоря уж о сплошных ODR-нарушениях при попытках оптимизировать.
МММ, щас ты меня будеш лечить что templates в C++ не разбухивают код ? Угомонись уже, код оптимизируется очень хорошо.

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

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

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

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

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

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

Не надо это рассказывать людям, которые драйвера писали и на С и на С++.
Просто небо и земля. Сишная рукопашка и вынужденный boilerplating просто выносили моск.

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

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

Профнепригодность detected.
Без шуток. Это no hire сразу.

S>И эти качества вообще параллельны на международных опенсорсных проектах.

Да, в опенсорсе тот ещё говнокод.

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

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

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

E>>>Стандарты разные бывают. Ко всему прочему есть де-факто стандарты.
C>>Вот в С11 их взяли из С++.
E>C11 когда приняли ? а когда появились всякие __sync_fetch_and_sub ?
И что дальше-то?

E>>>Много чего. Возврат структурных типов из функций, например.
C>>Не позорься, а?
E>Да это ты не позорься, если не знал.

struct test_t
{
   int a, b;
};

test_t testit()
{
   return {1, 2};
}

int main()
{
   test_t res = testit();
   printf("%d %d\n", res.a, res.b);
}

Всё ОК.

C>>

C>>- пусто -
C>>

E>Не в состоянии составить список ?
Нет, это полный список.

C>>>>Можно пример?
E>>>

E>>>public class AAA {
E>>>    public void selectAll(boolean tag) {
E>>>        for (Node node: nodes.values()) {
E>>>            node.select = tag;
E>>>        }
E>>>    }
E>>>    public void addNode(String id, Node node) {
E>>>        nodes.put(id, node);
E>>>    }
E>>>    IdentityHashMap<String, Node> nodes = new IdentityHashMap();
E>>>};
E>>>

C>>И всё. Тем более, что такая ошибка — это вообще из стиля "ну вот я тут забыл написать весь код и оно ничего не работает".
E>Дело в том, что в C++ такую ошибку допустить в принципе нельзя.
Да ну?

class AAA
{
    IdentityHashMap *nodes;
    AAA()
    {
        //Whoopsie
    }
};

Про всякие int'ы вообще молчу.

C>>В отличие от С, в Java доступны нетривиальные in-place конструкторы.
E>Мне абсолютно побоку на "нетривиальные in-place конструкторы", я на них не надрачиваю.
Только что подрочил уже.

C>>Работает плохо, и разбухивает код. Не говоря уж о сплошных ODR-нарушениях при попытках оптимизировать.
E>МММ, щас ты меня будеш лечить что templates в C++ не разбухивают код ? Угомонись уже, код оптимизируется очень хорошо.
Не разбухивают, по сравнению с макросами.

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

N> К тому же всякие драйвера для линуксов не пишутся на С++.

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

> Плюс и для C есть много современных фреймворков.

Например?

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

У меня есть знакомый, который вообще умный парень, знает хорошо С, но С++ мягко говоря не особо. И вот у него код получается немного странный из-за этого: состояние в глобальных переменных, макросы там где не нужно (практически весь публичный API получается состоящим из макросов), нереинтерабельные функции, и куча других "идиом" С. (При этом заголовочные файлы у него имеют расширение .hpp.) Я сначала не понимал почему. А причина в том, что на С трудно писать хороший код, и он выработал для себя набор приёмов, которые облегчают для него написание кода, но получающийся код изабилует вышеупомянутыми косяками. Так вот, я бы посоветовал тебе проверить, нет ли в твоём С коде похожих особенностей, которые легко предотвратить на С++.

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

U>Например?

Они в основном для embedded systems. Понятно дело, что на десктопах и даже мобилках для старого доброго си места нет.
PS
ZigBee api например

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

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

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

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

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

E>>>>Много чего. Возврат структурных типов из функций, например.
C>>>Не позорься, а?
E>>Да это ты не позорься, если не знал.
C>

C>struct test_t
C>{
C>   int a, b;
C>};

C>test_t testit()
C>{
C>   return {1, 2};
C>}

C>int main()
C>{
C>   test_t res = testit();
C>   printf("%d %d\n", res.a, res.b);
C>}
C>

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


C>>>

C>>>- пусто -
C>>>

E>>Не в состоянии составить список ?
C>Нет, это полный список.
Это не полный список, как минимум потому, что ты в него не включил даже того о чем написал сам.

C>>>И всё. Тем более, что такая ошибка — это вообще из стиля "ну вот я тут забыл написать весь код и оно ничего не работает".
E>>Дело в том, что в C++ такую ошибку допустить в принципе нельзя.
C>Да ну?
Именнно так:
C>

C>class AAA
C>{
C>    IdentityHashMap nodes;

C>    AAA()
C>    {
C>        // everything is ok
C>    }
C>};
C>

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

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

C>>>Работает плохо, и разбухивает код. Не говоря уж о сплошных ODR-нарушениях при попытках оптимизировать.
E>>МММ, щас ты меня будеш лечить что templates в C++ не разбухивают код ? Угомонись уже, код оптимизируется очень хорошо.
C>Не разбухивают, по сравнению с макросами.
Да ну ? Давай приводи сравнительный пример.

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

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

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

E>2. Возвращать структурные типы стало можно в C99.
Бредишь. Это возможно чуть ли не с K&R C, точно было в C89. Классика жанра — возвращение структуры POINT в WinAPI.

C>>Нет, это полный список.
E>Это не полный список, как минимум потому, что ты в него не включил даже того о чем написал сам.
Нету в С преимуществ.

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

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

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

Оно скомпилируется и будет падать.

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

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

Здравствуйте, 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++.

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

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

!!! Так это делает "это" уже не С++.
То есть если хорошо знать С++ то ясно понятно, что чтобы именно его особые (отличные от СИ) возможности использовать то нельзя уйти от всего внутри.
То есть это уже не C++, а скорее СИ с классами!

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

CC>Удачи!

Себе пожелай. Мне на тщательное изучение стандарта не две недели, а четырёх дней хватило, лет пять
назад. Это проще раз в сто, чем, например, топология бесконечномерных простанств. Имеенно
тогда увидел его уродливость С++. С++-кривое, уродливое безобразие. Лучшие языки, по мне-это С и Lisp, perl.
И когда это, разные поциенты, перестануть думать, что те, кому не нравится C++, это обязательно те которые не смогли его
осилить? По себе судят?

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

R>А можно ли быть программистом-системщиком, но знать только С, без С++? Вообще, насколько важно знать С++ или достаточно только С? Не только в России, но за бугром тоже. В Америке, я знаю, именно С больше в почете.

Нет не достаточно. Надо знать C++.
Только знание СИ, это мало для создания коммерческого софта.

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


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

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

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

S>И когда это, разные поциенты, перестануть думать, что те, кому не нравится C++, это обязательно те которые не смогли его
S>осилить? По себе судят?

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

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

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

Они это не поймут. ))
Тут я как-то столкнулся — типа "пришлите пример кода драйвера". Я высылаю — .... бабаба.... Ответ: Ну это же все на СИ, а нам хотелось увидеть как вы на С++ пишете.
Вот и это был ответ тех.спеца типа. )) Ну тимлидера из ядренной разработки. Я плакаль. ))

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


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

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

Скорее всего.

A>и можно было бы писать юнит тесты.

Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали

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

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

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


CC>Профнепригодность detected.
CC>Без шуток. Это no hire сразу.

А мне мнение и видение сотрудников Pupkin Inc. из РФ о профпригодности в кодотворстве параллельны.
Там, где приходится вращаться, о профпригодности судят по другим признакам, в которые желание оформлять
код как цветочную клумбу, или букет для подарка женщинам, не входят.

CC>Да, в опенсорсе тот ещё говнокод.

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

ХГД>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
Те кто хочет, пишут юнит тесты и на Си с использованием соответсвующих фреймворков или без. Фреймворки для этого есть, cmockery например.

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

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

Ну да, было бы удобно. Но мелочь.

A>>ок, 1 элемент списка есть, а еще?
A>>ты не стесняйся, пиши все сразу
E>А зачем торопиться ? Составные литералы еще никто здесь не упомянал ?

А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать

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

E>Но в РФ за это знание платить будут мало.

Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.

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

A>>>ок, 1 элемент списка есть, а еще?
A>>>ты не стесняйся, пиши все сразу
E>>А зачем торопиться ? Составные литералы еще никто здесь не упомянал ?
ХГД>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.

task.state = (state_t) { .priority = 10, .name="task1" };

E>>Но в РФ за это знание платить будут мало.
PML>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.
Все уехали.

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

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

E>>Но в РФ за это знание платить будут мало.

PML>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.

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

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

A>>и можно было бы писать юнит тесты.
ХГД>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
я как-то не очень себе представляю юнит-тесты на Си. слишком мало возможностей чтобы подцепить фейки/моки, слишком много бойлерплейта.

по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

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

ХГД>>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
E>Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.
E>

E>task.state = (state_t) { .priority = 10, .name="task1" };
E>

Вот именно — "в отсутствии вызовов конструкторов". С чего бы им в плюсах отсутствовать? В C++11 даже POD могут иметь кое-какие конструкторы.

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


A>я как-то не очень себе представляю юнит-тесты на Си. слишком мало возможностей чтобы подцепить фейки/моки, слишком много бойлерплейта.

A>по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

Хотите пример? Есть такой DTrace. Посмотрите как он реализован в solaris, не где нибудь ещё, вроде freebsd,
а именно в солярисе. И увидите не что иное как реализацию организации модульного тестирования всего ядра,
на всём его протяжении. На каждом, хоть что-то значащем, его участке.

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


A>>>и можно было бы писать юнит тесты.
ХГД>>Если бы кому-то хотелось писать юнит-тесты, они бы их и для C написали
A>я как-то не очень себе представляю юнит-тесты на Си. слишком мало возможностей чтобы подцепить фейки/моки, слишком много бойлерплейта.

Ну фреймворков-то полно, как-то наверное цепляются. И вообще, в C слишком много бойлерплейта не бывает

A>по крайней мере я просто никогда не видел юнит-тестов в проектах на Си. (не регрессионных, а именно юнит-тестов)

В плюсовом опенсорсе тоже как бы не особо распространенное явление

ХГД>>>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
E>>Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.
E>>

E>>task.state = (state_t) { .priority = 10, .name="task1" };
E>>

ХГД>Вот именно — "в отсутствии вызовов конструкторов". С чего бы им в плюсах отсутствовать? В C++11 даже POD могут иметь кое-какие конструкторы.
И это очень плохо. Не всегда есть желание и даже возможность вызывать конструктор, например до старта main в статических данных

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

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

S>Хотите пример? Есть такой DTrace. Посмотрите как он реализован в solaris, не где нибудь ещё, вроде freebsd,
S>а именно в солярисе. И увидите не что иное как реализацию организации модульного тестирования всего ядра,
S>на всём его протяжении. На каждом, хоть что-то значащем, его участке.

дай ссылку на код или репозиторий, а лучше на конкретные файлы с тестами,
а то я нашел пару каких-то dtrace, но юнит-тестов там не было

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

PML>>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.
N>Город, зарплата, небудте голословными.

Москва.
Зарплата по результатам собеседования Для редких специалистов индивидуальный подход.

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

E>>>Но в РФ за это знание платить будут мало.
PML>>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.
E>Все уехали.

Возможно. А может перепрофилировались на "клепателей формочек".

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

ХГД>>>>А какой от них в плюсах был бы прок? Анонимные объекты и так без проблем можно создавать
E>>>Какой прок ? В отсутсвии вызовов кострукторов для POD хотя бы.
E>>>

E>>>task.state = (state_t) { .priority = 10, .name="task1" };
E>>>

ХГД>>Вот именно — "в отсутствии вызовов конструкторов". С чего бы им в плюсах отсутствовать? В C++11 даже POD могут иметь кое-какие конструкторы.
E>И это очень плохо. Не всегда есть желание и даже возможность вызывать конструктор, например до старта main в статических данных

E>Поясню. Если Вы напишете на С++ модуль к ядру Линукса и в этом модуле будет нечто статическое (необязательно обьект), для которого компилятор сгенерит инициализирующий конструктор, то Вас ждет много удивительных открытий и незабываемых часов с отладчиком и дизассемблером.

От записи штоле защищено? И на выяснение этого факта надо много часов с отладчиком и дизассемблером? Ужас-ужас, а дустом не пробовали? В смысле, constexpr constructor тоже почему-то не годиццо?

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


A>дай ссылку на код или репозиторий, а лучше на конкретные файлы с тестами,
A>а то я нашел пару каких-то dtrace, но юнит-тестов там не было

Ну, скорее всего, лучше начать отсюда, и дальше по ссылкам для построения картины.

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

PML>>>Знакомые в России не могут нанять хорошего С программиста, платить готовы хорошо, но специалистов на рынке мало.
N>>Город, зарплата, небудте голословными.

PML>Москва.
PML>Зарплата по результатам собеседования Для редких специалистов индивидуальный подход.

Если зарплату стесняются озвучить, то и ответ соискателей, наверное, обычный — "ищи дурака за 4 сольдо"

В 2008 г. я работал в одной конторе, в которой мы писали системный софт (на уровне userspace) для промышленных контроллеров, я писал на C вместо C++. Это не были легковесные контроллеры типа PIC, на них крутился полновесный Linux. При этом JVM там была несколько неуместна, потому что кроме системы ещё выполнялась технологическая задача, которая писалась на своём DSL, и кто знает, какого размера она могла быть, а также нужно было ещё гарантировать, что JVM не будет портить время циклов в наших soft-realtimе сервисах. Для многих системных вещей, по крайней мере тех, с которыми я работал, C++ был бы удобнее, и если бы я его знал достаточно хорошо, стоило как раз на C++ всё реализовывать. Но мои коллеги всё писали на C, и поскольку вся система (userspace надстройка над Linux и всякие системные вещи типа коммуникации, диагностики) уже были написаны на C, я решил не выпендриваться с C++. В принципе, некоторые вещи в моём коде были бы лаконичнее и менее костыльны (яркий пример тому — динамические массивы, списки), в C этого нет, и приходится тащить сторонние библиотеки или прибегать к жутким макросным поделкам.

Сейчас некоторые системные вещи, которые I/O-bound, я писал бы на Rust, или чём-нибудь компилируемом под ARM и современнее C++.
Но проблема многих контор в том, что уже есть куча кода, написанная на языке X, а руководство скептически относится к смене инструмента по прихоти новых сотрудников, нужны очень веские причины, чтобы уговорить ввести в разработку новый язык Y. Связано это, очевидно, с боязнью сокращения прибыли в случае ошибок и недооценок дополнительного времени, потраченного на введение в разработку нового языка Y и его поддержки. Переписывать же грамотно спроектированную систему с X на Y, если она работает годами, требуя небольших расширений, не меняющих архитектуру, никто не будет, потому что это неоправданные затраты человеко-часов, непонятно, ради чего. Не бывает системщиков, не знакомых с C, и пока ядра ОС пишут на C, и существуют другие проверенные временем промышленные системы, написанные на C, будут востребованы C-программисты.

Самый быстрый код — компилируемый на C (ещё есть всякие фортраны, но я их не рассматриваю), и поскольку вседа есть приложения (а вернее, их bottlenecks), в которых нужно выжать максимум из железки (например, за счёт использования векторизации, специфичной для конкретного класса процессоров), будет жить и C.

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

PML>>Москва.
PML>>Зарплата по результатам собеседования Для редких специалистов индивидуальный подход.

ХГД>Если зарплату стесняются озвучить, то и ответ соискателей, наверное, обычный — "ищи дурака за 4 сольдо"


1. Обращаю ваше внимание, что это не я ищу такого программиста, соответственно и суммы озвучивать мне будет неправильно.
2. Для большинства компаний неозвучивание сумм публично — это стандартно, нравится вам это или нет: Яндекс, Abbyy, Касперский.

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

A>>дай ссылку на код или репозиторий, а лучше на конкретные файлы с тестами,
A>>а то я нашел пару каких-то dtrace, но юнит-тестов там не было

S>Ну, скорее всего, лучше начать отсюда, и дальше по ссылкам для построения картины.

и что это? где сами тесты-то?

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

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

Это все отлично, но мне-то зачем такое писать? Я же конкретно про список отсутствующих в плюсах мегафич С спрашивал Чисто для расширения кругозора — на чистом Це я писал довольно мало и очень давно.

__>Самый быстрый код — компилируемый на C (ещё есть всякие фортраны, но я их не рассматриваю), и поскольку вседа есть приложения (а вернее, их bottlenecks), в которых нужно выжать максимум из железки (например, за счёт использования векторизации, специфичной для конкретного класса процессоров), будет жить и C.

С чего бы коду на C быть быстрее кода на C++? Если автор кода не очень криворук, естественно.

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

ХГД>>Если зарплату стесняются озвучить, то и ответ соискателей, наверное, обычный — "ищи дурака за 4 сольдо"

PML>
PML>1. Обращаю ваше внимание, что это не я ищу такого программиста, соответственно и суммы озвучивать мне будет неправильно.

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

PML>2. Для большинства компаний неозвучивание сумм публично — это стандартно, нравится вам это или нет: Яндекс, Abbyy, Касперский.

Ну так они и не жалуются, что не могут толковых спецов найти
А вот если и зарплата секретная, и с наймом работников проблемы — то вывод сам собой напрашивается.

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

A>и что это? где сами тесты-то?

Там они расписаны ровно настолько, насколько нужно было для организации
определённого наблудения за состоянием определённых объектов и параметров в работающем ядре.
Но точно также, расставлением хуков DTRACE_PROBE, можно организовать мониторинг в рантайме исполнения любой функции,
и наблюдать за состоянием любого объекта в ядре.

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

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

A>>и что это? где сами тесты-то?

S>Там они расписаны ровно настолько, насколько нужно было для организации
S>определённого наблудения за состоянием определённых объектов и параметров в работающем ядре.
S>Но точно также, расставлением хуков DTRACE_PROBE, можно организовать мониторинг в рантайме исполнения любой функции,
S>и наблюдать за состоянием любого объекта в ядре.

ты вообще в курсе что такое юнит-тесты? >_<

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

A>ты вообще в курсе что такое юнит-тесты? >_<

Вы сами то в курсе, что то что называется модульным тестированием, может
проводится не только так, как Вас учили в ВУЗе, или как оно расписано
каким-то корифеем в книжке. Вы в курсе, что, например, некоторые линуксоиды кернельщики то, что
называется юнит тестированием, проводят вообще с помощью printk(), и этого им за глаза хватает.

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

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

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

Кстати, опасность неявного каста void* сильно приувеличенна. void* встречаются на так уж часто в нормально написанной программе.

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

N>Майкрософт — это компания которая поддерживает с++ и развивает его куда больше чем все остальные.
N>Кто-то даже говорит что единственная. Так что неудивительно...
Eсть какое-то подтверждение? Потому что (со стороны) ситуация выглядит несколько другой. Скажем, поддержку нового стандарта они до сих пор, кажется, не доделали. При этом конкуренты (clang, gcc) ещё не принятый С++14 внедряют. Помню ещё читал про какие-то фичи (кажется, про аттрибуты) они заявляли, что-то типа "у нас уже реализовано другим способом и переделывать не будем". Опять же, дотнетом несколько уменьшили роль С++.

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

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

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

Знаете, мне почему то кажется что так можно написать к любому отношению ххх/ххх+.

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

E>Поясню. Если Вы напишете на С++ модуль к ядру Линукса и в этом модуле будет нечто статическое (необязательно обьект), для которого компилятор сгенерит инициализирующий конструктор, то Вас ждет много удивительных открытий и незабываемых часов с отладчиком и дизассемблером.

Это не только в линуксе. В NT тоже самое. И в любом микроконтроллере, где нету стандартного С++ стартапа. Надо стартап правильный написать. И никаких часов отладки с дизассемблером. Просто не надо быть [censored] и надо знять что для Ц/Ц++ есть инициализаторы и финализаторы которые исполняются до/после мэйна стартапом.

Для чистого Си это тоже актуально, странно что ты не в курсе. Статики-то надо инитить, и в _atexit напиханные функции вызывать.

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

ХГД>От записи штоле защищено? И на выяснение этого факта надо много часов с отладчиком и дизассемблером?

Ну, справедливости ради, GDB та еще какашка А может автор живую отладку не осиливает, и пользуется исключительно sprintf-ом в файл/компорт/etc.

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

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

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

1>ххх не нужен.
1>99% тех, кто пользуются этой штукой — это те что ниасилили ххх+.
1>что какбэ намекает на то, что люди не способные осилить ххх+ никому не нужны.
1>тем более что есть строгая корреляция между знанием этой штуки и знанием различных технологий и практик пользования такими штуками.

1>Знаете, мне почему то кажется что так можно написать к любому отношению ххх/ххх+.

да, можно, и что?
у тебя много таких пар ххх/ххх+ ?

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

IID>Это не только в линуксе. В NT тоже самое. И в любом микроконтроллере, где нету стандартного С++ стартапа. Надо стартап правильный написать. И никаких часов отладки с дизассемблером. Просто не надо быть [censored] и надо знять что для Ц/Ц++ есть инициализаторы и финализаторы которые исполняются до/после мэйна стартапом.

IID>Для чистого Си это тоже актуально, странно что ты не в курсе. Статики-то надо инитить, и в _atexit напиханные функции вызывать.

Если Вы про .init/.fini _start/_end, то не это проблемы создаёт.
Ядро, при сборке, линкуется в некоторое виртуальное адресное пространство.
И некоторая его часть, которая исполняется на старте, в которое управление
передаёт загрузчик, линкуется вне этого пространства, которое
работает в режиме реальных адресов, но которому должны быть доступны объекты,
слинкованные в простарнство виртульных адресов, для их инициализации.
И в этом пространстве многие объекты должны распологаться на строго
определённых участках, отмеряемых в смещениях между объектами, занимать
строго определённое местоположение относительно других.
Такая тонкая организация карты расположения объектов возможно только
на чистом С, и С++ с его служебными полями, которые компилятор помещает
в память, занимаемую объектами, так как ему захочется, здесь нарушит всю
структуру и карту пространства памяти в которое линкуется ядро. Поэтому
никаких классов, конструкторов, шаблонов, динамического полиморфизма
через виртуальные фукнции и прочие С++-змы.

Здравствуйте, Andrew.W Worobow, Вы писали:

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

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

AWW>То есть для того что бы не делать ошибок на СИ нужна выскокая квалификация програмиста, а на С++ можно избежать ошибок и используя менее квалифицированную рабсилу.

Это заблуждение. В мире СИ нужно делать много специфической работы, которой нет в других ЯП. Безусловно, минусом это является только когда речь заходит о вполне конкретных задачах, типа "сделать за 2 часа и чтоб работало".

На сайте есть совершенно замечательная статья — в ней вместо C++ можно подставить C.

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

1>>Знаете, мне почему то кажется что так можно написать к любому отношению ххх/ххх+.

A>да, можно, и что?
То что это не конструктивно и довольно категорично.
A>у тебя много таких пар ххх/ххх+ ?
А причем тут пары? Берите все что угодно вместо них.
Собственно в ваших собственных рассуждениях можно заменить С на С++, а С++ на С)))

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

S>Ядро, при сборке, линкуется в некоторое виртуальное адресное пространство.
S>И некоторая его часть, которая исполняется на старте...
S> многие объекты должны распологаться на строго
S>определённых участках...
S>С++ с его служебными полями, которые компилятор помещает
S>в память, занимаемую объектами, так как ему захочется
Наверное, в детерминированной программе, каковой является гипотетический компилятор C++ "как захочется" означает определённых набор правил?

S>структуру и карту пространства памяти в которое линкуется ядро. Поэтому
S>никаких классов, конструкторов, шаблонов, динамического полиморфизма
S>через виртуальные фукнции и прочие С++-змы.
Шаблоны-то тут при чём, раз всё линкуется статически?

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

AWW>>То есть для того что бы не делать ошибок на СИ нужна выскокая квалификация програмиста, а на С++ можно избежать ошибок и используя менее квалифицированную рабсилу.

A>Это заблуждение. В мире СИ нужно делать много специфической работы, которой нет в других ЯП. Безусловно, минусом это является только когда речь заходит о вполне конкретных задачах, типа "сделать за 2 часа и чтоб работало".

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

То есть СИ более низкоуровневый язык, а чем ниже уровень, тем ближе к "железу", тем выше нужна квалификация. Ну что бы написать тоже самое на C# надо скажем 10 строчек, на СИ надо 100. C# даст кучу предупреждений которые в силу самого языка вожможно выявить и подсказать программисту.
В СИ есть у тебя указатель на буфер, это просто адрес, и крутись как хочешь — весь контроль тебе передали, в С++ уже есть ссылки, ошибок наделать можно меньше.

Если в языке много поводов сделать ошибок, это писать на нем без ошибок — нужна более высокая квалификация.

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

Здравствуйте, Andrew.W Worobow, Вы писали:

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

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>То есть на СИ писать сложнее, но когда это необходимо то нужна более квалифицирванная рабсила.
Память это не самая большая беда когда пишется большая и сложная система. Куда более серьёзная проблема в том, что на С нет никаких способов писать безопасный код.

AWW>То есть СИ более низкоуровневый язык, а чем ниже уровень, тем ближе к "железу", тем выше нужна квалификация.
Чем сложнее инструмент тем выше нужна квалификация.
Те же самые индусы, что у нас пишут на С пишут кое какие части на С++. Туда просто без слёз не взглянуть: нагромождения буста в таких причудливых комбинациях что просто диву даёшься как они такое вообще придумали и как оно вообще умудряется работать. Там где можно сделать просто они делают сложно.

AWW>Если в языке много поводов сделать ошибок, это писать на нем без ошибок — нужна более высокая квалификация.
Печаль в том, что по факту на С говнокодят в стиле: скомпилировалось — значит ошибок нет.

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

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

Ваганыч, ты?

Здравствуйте, Andrew.W Worobow, Вы писали:

S>>>Осилить C++ -пара недель почитывания стандарта.
CC>>Удачи!
AWW>А что там такого сложного?
Получение опыта использования.

AWW>ИМХА указатели в СИ по уровню сложности понимания сложнее, чем все в С++.
Я встречал людей которые указатели не понимали, да.

AWW>То есть даже ссылки там придумали чтобы народу было проще. ))
Там ещё много чего есть кроме ссылок.

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

S>Здравствуйте, CreatorCray, Вы писали:
CC>>Удачи!

S>Себе пожелай. Мне на тщательное изучение стандарта не две недели, а четырёх дней хватило, лет пять
S>назад. Имеенно тогда увидел его уродливость С++. С++-кривое, уродливое безобразие. Лучшие языки, по мне-это С и Lisp, perl.

Т.е. на С++ ты ничего серьёзного не писал.

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

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

C> Так что менять что-то сильного смысла нет (кроме того, в ядре куча структур с полями с именами типа "class" или "protected").
Так получилось что я щас пишу код в полулинуксячье ядро. И мне там очень не хватает возможностей С++. Огромное колво мест можно написать нормально, а не через задницу, как оно написано сейчас.

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

CC>>Ну он про С++ писал типичное для ниасиливших.
N>Что например?
google linus c++ rant

CC>>На С — банально много гемору.
N>Какого?
Рукопашка везде и во всём. Boilerplating. Принципиальная невозможность писать safe код.

Здравствуйте, Andrew.W Worobow, Вы писали:

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

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

Дайте мне в С:
классы с конструкторами, деструкторами, операторами и наследованием
перегрузка функций
templates (variadics included)

и я уже буду счастлив.

AWW>Ну дык эти как СИ с классами. Это не С++.
Даже С с классами уже помогает сократить объём кода раза эдак в 2-3 и облегчить жизнь разработчику за счёт автоматизации.

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

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

S>Похоже, Вы драйверы под линукс не то что не писали, но и уже написанные не видели.
Я пишу код в linux-based ядре. Нихрена там нет, спагетти и говнокод.

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

S>А мне мнение и видение сотрудников Pupkin Inc. из РФ о профпригодности в кодотворстве параллельны.

Меня тоже, я от РФ нахожусь очень далеко.

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

Сколько было человек в самой большой команде где ты когда либо работал за деньги?

S>Вот когда сотрудники Pupkin Inc из Мск выкатят что-то, хоть отдалённо приближающееся,
S>по степени распространённости и востребованности в мире, к опенсорсным проектам, тогда
S>и смогут судить о опенсорсных проектах.

Классическое "Сперва добейся!" (С)
Тут давеча закончился VMworld, и если ты там был (в чём я сомневаюсь) ты мог посмотреть на то, что мы выкатываем.

Здравствуйте, Andrew.W Worobow, Вы писали:

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

AWW>!!! Так это делает "это" уже не С++.
Т.е. чтобы писать на С++ надо обязательно использовать каждую фичу языка? Одну забыл и всё, программа уже не на С++?

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

E>При этом возникает еще куча разного гемороя, как-то поддержка компиляторных хвостиков самого языка C++.
Это кстати не так уж сложно. Один раз собирается библиотека и на этом всё. МС кстати об этом сама позаботилась.

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Тут я как-то столкнулся — типа "пришлите пример кода драйвера". Я высылаю — .... бабаба.... Ответ: Ну это же все на СИ, а нам хотелось увидеть как вы на С++ пишете.
AWW>Вот и это был ответ тех.спеца типа. )) Ну тимлидера из ядренной разработки. Я плакаль. ))

Всё правильно тебе ответили. Не надо писать на С когда есть возможность писать на С++.

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

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

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

E>1. Глобальная переменная в С и С++ инициализируется нулем. Балбес.
А с чего ты взял что это глобальная переменная?

Согласен. Когда нет озвученной ветки, это разговор ни о чем.
Причем яндекс и всякие лабы озвучивают минимум и максимум.

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

PML>>2. Для большинства компаний неозвучивание сумм публично — это стандартно, нравится вам это или нет: Яндекс, Abbyy, Касперский.

ХГД>Ну так они и не жалуются, что не могут толковых спецов найти

Вы не поверите

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

N>Согласен. Когда нет озвученной ветки, это разговор ни о чем.
N>Причем яндекс и всякие лабы озвучивают минимум и максимум.

Публично или лично вам на собеседовании?

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

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

CC>>>Ну он про С++ писал типичное для ниасиливших.
N>>Что например?
CC>google linus c++ rant

CC>>>На С — банально много гемору.
N>>Какого?
CC>Рукопашка везде и во всём. Boilerplating. Принципиальная невозможность писать safe код.
как везде и во всем? А как же GTK?
Небезопасны там только указатели. Там в принципе больше ничего особого и нет, так что тоже голословно.