си C99

почему меня должно волновать, можешь ли ты запустить скайп?

твой любимый qt, между прочим, под венду выпускают в 4 версиях — G++, MSVC 2010, 2012 и 2013. а ты продолжай твердить, что проблем нету.

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

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

Видимо, он третий=)

не вижу особого смысла пилить их на крестах, это мало что упрощает в этом случае.

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

почему меня должно волновать, можешь ли ты запустить скайп?

Потому-что ты лузер, который вещает, что в линуксе нет единого плюсового ABI.

твой любимый qt, между прочим, под венду выпускают в 4 версиях — G++, MSVC 2010, 2012 и 2013. а ты продолжай твердить, что проблем нету.

«мой любимый qt», между прочим, отлично работает под вендой, в отличие от сишных поделок. А все проблемы в том, что команде Qt пришлось сделать сложнейшую вещь - собрать бинарники для тех, кто не хочет собирать Qt у себя. И напомни, как давно Visual C++ стал уметь С99? Только в самой последней версии? А С11 когда ждать? Некоторые могут рассуждать о совместимости и проблемах, когда их язык до недавнего времени поддерживался на уровне стандарта 25-летней давности (а теперь только 16-летней, несомненный успех).

(школьник)

не все потеряно. осталось понять, что других случаев не бывает.

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

Вот не надо мне приписывать свои фантазии про линукс и крестовые аби. Я вообще о другом писал, и достаточно подробно. Просто ты до сих пор не понял о чем речь.

Я пока лично не видел поддержки c99 в вижуалах. Но gcc и clang никто не отменял.

Они тебе ответили: у них разработка на си идёт быстрее, чем на крестах. Моё мнение такое, что objective-C гораздо лучше крестов тупо своим рантаймом, именно он меня и побудил изучать Си. От различных Objective-C++ тошнит. Будущее в любом случае за swift/go подобными языками, уже сейчас на них можно зарабатывать прилично, в то время как с крестами будет секс_с_машиной.

Они тебе ответили: у них разработка на си идёт быстрее, чем на крестах.

За счёт чего? Все те небольшие различия, что есть у Си и у сишного подмножества С++, не ускоряют времени разработки. C++ содержит дополнительные средства, которые позволяют сократить время разработки по сравнению с Си.

Моё мнение такое, что objective-C гораздо лучше крестов тупо своим рантаймом

Этот рантайм доступен и из C++.

Кстати, на Лоре тут как-то строки конкатенировали на си. На C++ это будет так: s1 + s2. Вот к тебе лично просьба, привели сишный код, а потом objective-c код.

тошнит

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

Будущее в любом случае за swift/go подобными языками

Будущее за разными языками. И jvm-овские языки ещё живы. И у Си с C++ ещё много работы. Подвинуть их сможет из новых языков разве что Rust.

Повторяю, если ты смог свой проект перевести с си на go и тебя все устраивает, значит и раньше ты взял си зря - можно было брать java, например. Scala, Ocaml. Они все мощнее go, производительность разработки на них, скорее всего, выше. Производительность и аппетиты результата будут на том же уровне. А может тебе будет достаточно даже питона или руби.

уже сейчас на них можно зарабатывать прилично

И что? До уровня си, с++ и java вряд ли зп дотянет. Задачи на перечисленных тобой языках решаются простые, в основном. Вот на go еще да. Знаю команду в одной конторе. Они на него с node.js переползли, если правильно помню. Примеров перехода с Си или С++ вообще не знаю. Как ты перейдешь, если потеряешь все достоинства текущего состояния - лёгкость рантайма, управление памятью, управление параллельными алгоритмами и т.д. и т.п.?

в то время как с крестами будет секс_с_машиной.

Так это основная ниша Си и C++. Желёзки всякие делать (маршрутизаторы, софтсвичи, телекоммуникационное оборудовани и пр.), базы данных некоторые(postgresql, mysql, redis, leveldb и т.д.), всякие системы анализа данных, бэкенды в некоторых случаях, etc. Иногда бывает и гуй, если решаемая им задача сложна алгоритмически, требовательна к вычислительным ресурсам и пр. Да, это все можно назвать «секс-с-машиной». Но если тебе это не нужно, то не подходит ни си, ни c++.

За счёт чего? Все те небольшие различия, что есть у Си и у сишного подмножества С++, не ускоряют времени разработки.

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

На C++ это будет так: s1 + s2. Вот к тебе лично просьба, привели сишный код, а потом objective-c код.

s1+s2 это говнокод. и на надо тащить тот тред сюда. там есть ответ и про си, и про objc.

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

Все зависит от использующего. Можно сделать все наоборот. У нас на работе есть часто используемый eDSL на С++11 с variadic templates, lambdas и пр. Кода с ним стало на порядок меньше, читать и править его крайне просто и удобно. Уже два года как используем - никаких проблем, только плюсы. Хотя для тебя, вероятно, это и есть «сложнее, запутаннее».

s1+s2 это говнокод. и на надо тащить тот тред сюда. там есть ответ и про си, и про objc.

Этот тот тред, где ты писал:

NSMutableDictionary *m = [[NSMutableDictionary alloc] initWithObjectsAndKeys:@1, @"str", nil];
int incrementedValue = [[m objectForKey:@"str"] intValue]+1;
[m setValue:@(incrementedValue) forKey:@"str"];

Как аналог:

map<string, int> m({ 1, "str" });
m["str"]++;

Ну да, не стоит, там все разжевано и очевидно - код на ObjC медленнее, без проверок типов и раздутей. На С это еще ужасней, особенно учитывая, что в C вообще нет стандартных контейнеров и возможности работать без указателей и ручной подчистки памяти.

map<string, int> m({ "str", 1 });
m["str"]++;

self fix

ты что сказать-то хотел? все ответы на твои вопросы уже были дадены в том треде.

зато фичи C++ замедляют.

Ты не прав. Если бы они замедляли, их бы не использовали.

кода становится больше

Меньше.

он сложнее

Проще.

запутаннее

Наоборот, его легче понимать. Ради того фичи и нужны.

его труднее тестировать, менять, читать, понимать и т.п.

Нет, легче.

чиста к слову, если тебе нужен std::map в objc — ты можешь спокойно использовать std::map, это не запрещено. просто файлик в .mm переименуй.

s1+s2 это говнокод

Далеко не всегда. Код этот очень прост и понятен. И работает он быстрее objective-C варианта...

Ты не прав. Если бы они замедляли, их бы не использовали.

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

Меньше.

for (listItem_t *p = list; p; p = p->next) {
   ...
}

for (std::list<Item>::const_iterator p = list.begin (); p != list.end (); p++) {
   ...
}

кода больше в c++. и даже auto тебя не спасет.

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

Тут оба примера на С++.

Код этот очень прост и понятен.

складывает два числа?

и не выделяет при этом память в хипе?

И работает он быстрее objective-C варианта...

пруф?

нет, первый это C.

for (auto & x : list) {

уел. я пока не доучил с++ до этих фич.

зы: ушел из треда, т.к. надоело.

я пока не доучил с++
ушел из треда, т.к. надоело.

LOL

Вариант на С работает только со списками, вариант на С++ с любой коллекцией. Так что не совсем эквивалентно.

for (auto & x : list) {

в данном случае лучше явно указать тип (если это не шаблон):

for (const item& x : list) {

Кода ненамного больше, но читающему будет сразу видно с чем тут работают.

LOL

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

я просто забываю, что крестовики-теоретики в основном говорят о стандарте, который существует только на бумаге, и в паре компиляторов макс для основных десктопных платформ (если повезло). в реальной жизни, у нас C++ тот что работает на всех платформах. в нем нет этого auto x : list

нет, первый это C.

И C++.

уел. я пока не доучил с++ до этих фич.

Да, во многих местах новые плюшки упрощают код. C++ довольно активно развивается.

Жаль. Мне вот тоже не очень понятна позиция отказа от C++ при наличии компилятора и отсутствия технических препятствий.

И C++.

если тебе понадобится код, который работает в C, но не в C++, ты обращайся, я тебе напишу

вот например

int *data = malloc(100);

и да, чтобы ты был уверен, что то выше был именно С код, у переменной «list» тип void *.

я просто забываю, что крестовики-теоретики в основном говорят о стандарте, который существует только на бумаге

Это, блин, C++11. Сейчас 2015 год. Уже принят С++14.

в нем нет этого auto x : list

По-моему даже оффтопиковская студия умеет это... gcc умеет еще с -std=c++0x, то есть как минимум лет 5.

у нас 21 платформ. там далеко не везде есть компиляторы «даже» c++11.

если тебе понадобится код, который работает в C, но не в C++, ты обращайся, я тебе напишу

Я сам справлюсь с этой задачей.

и да, чтобы ты был уверен, что то выше был именно С код, у переменной «list» тип void *.

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

Бывает... Ну если так, то оправдано, конечно.

у нас 21 платформ. там далеко не везде есть компиляторы «даже» c++11.

А ты конкретизируй - где именно их нет. Сходу погуглил PS3 - есть, Android, iOS - сам использую. Всякие win, os x, linux и производные и так очевидны. Так где же?

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

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

Это, если ты вдруг решишь соскочить на эту тему.

я не понял о чем это сообщение.

всмысле, что за люди, которым вы выдаете SDK, и каким боком тут я?

А что тут непонятного? С — отличный язык: простой, легкочитаемый... А С++ — ублюдство какое-то.

Разве «отличный» или «ублюдство» - являются аргументами? Вот отсутствие аргументации и непонятно.

уже сейчас на них можно зарабатывать прилично

Ололо, нищеброд-заедушник о языках рассуждает.

вполне являются, особенно когда это правда :)

а Вы SDL используете в разработке? (не хочу ещё про это отдельную тему создавать)

Разве «отличный» или «ублюдство» - являются аргументами?

Конечно. Ну и простота, ясен пень: на сях очень легко писать. Это тебе не извращение Страуструпа.

А я вот думаю, что не являются. Ну и неправда это.

Конечно.

Какие же это аргументы?

Ну и простота, ясен пень: на сях очень легко писать. Это тебе не извращение Страуструпа.

Да наоборот же.

В общем, в итоге получается, что единственный «аргумент» - это личное негативное восприятие.

Да наоборот же.

4.2

С++ — очень сложный язык. Ты еще с пхытоном сравни... Хотя, пхытон даже сложней, чем С++.

единственный «аргумент» - это личное негативное восприятие

Нет. Объективно С — наилучший язык программирования. Для любых целей, кстати: от мелкоконтроллеров до CGI для веб-морд. Хотя, встречаются извращенцы, которые и жабку в микроконтроллеры втыкают, но мы же про нормальных людей говорим!