Re[12]: Достаточно ли знать С без знания С++ для устройства н - О работе

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-функции.

	От:	eskimo82
	Дата:	04.09.14 23:41
	Оценка:

	От:	Cyberax
	Дата:	04.09.14 23:43
	Оценка:	+2

	От:	eskimo82
	Дата:	04.09.14 23:45
	Оценка:

	От:	eskimo82
	Дата:	04.09.14 23:52
	Оценка:	-1

	От:	Cyberax
	Дата:	05.09.14 00:11
	Оценка: