LINUX.ORG.RU
ФорумTalks

Если вы пишете на c++98/99, то какие ограничения не позволяют вам перейти на c++11/14/17?

 ,


0

5

Я могу придумать только одно и одно с большой натяжкой:

На какой-то embedded железке нельзя обновить ос и компилятор. Ну или начальство не разрешает... что странно.

Какие есть ещё? И да, разумеется разработка под Linux.

★★★★★

Ответ на: комментарий от tailgunner

И кстати, в Си тоже не все все «объекты языка» имеют одинаковую стоимость.

Как будто есть языки, в которых всё имеет одинаковую стоимость.

Но не вижу в своих словах ничего, что могло бы навести на такую мысль.

Тебя «Капитаном Очевидность» не называют ещё?

i-rinat ★★★★★
()
Ответ на: комментарий от cvs-255

Хм, я думал, ты крутой спец. Сделаю себе пометочку)

DELIRIUM ☆☆☆☆☆
()

Я учил Си по книжке, выпущенной ещё до принятия первого стандарта. Нафига мне что-то ещё знать?

Shadow ★★★★★
()
Ответ на: комментарий от cvs-255

Да, реализации одного и того же алгоритма средствами C++ и C как правило имеют разницу в скорости от 1,5 и более раз.

Вот тут бы пруфов добавить.

?

trex6 ★★★★★
()
Ответ на: комментарий от cvs-255

Для быстрого и оптимизированного кода для высоких нагрузок есть C

А если быстрый оптимизированный код должен быть ещё и читаемым?

thunar ★★★★★
()
Ответ на: комментарий от cvs-255

А по скорости C уделывает обоих

Механизм?

thunar ★★★★★
()
Ответ на: комментарий от cvs-255

Если для написания высокопроизводительного кода надо использовать лишь подмножество языка, то это и значит, что язык - медленный.

Я так понял, что в C вручную созданная эмуляция таблицы виртуальных функций будет работать быстрее?

thunar ★★★★★
()
Ответ на: комментарий от sniper21

Я и не говорил, что C# по скорости равен C++

cvs-255 ★★★★★
()

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

stevejobs ★★★★☆
()

Есть всякие фанаты старых версий MSVS и C++ Builder, что мешает им использовать новый компилятор.

grem ★★★★★
()
Ответ на: комментарий от sniper21

да да, я имел ввиду «ого, их не ограничивают C89!»

t184256 ★★★★★
()
Ответ на: комментарий от grem

Можно подумать в новых версиях MSVS рай. благодать и C99, ага.

t184256 ★★★★★
()
Ответ на: комментарий от i-rinat

Это да, даже fortran90 уже довольно богат встроенными функциями обработки строк.

Я пока пытаюсь понять, что месяц назад меня заставило написать такое: str.substr(0, str.length()).find_first_of(" ")

grem ★★★★★
()
Ответ на: комментарий от i-rinat

Я к тому, что в Debian 7 использование C++11 доставляет ощутимые неудобства

По сравнению с С++03? Не верю. Можно задать гайдлайн, допустим пользоваться только nullptr, range-for и любдами, будет вполне юзабельно и строго лучше чем сидеть на 03

annulen ★★★★★
()
Ответ на: комментарий от stevejobs

На этих устройствах java тупо по памяти не пройдет, или в крайнем случае там есть какая-нибудь древняя версия ME которая никому на фиг не уперлась

annulen ★★★★★
()
Ответ на: комментарий от annulen

джавы нет, а заказчики, которые за неё платят огромные деньги Ораклу - есть, вот это дела! xD

имеются в виду в том числе всевозможные станки на заводах, embedded, вышки сотовой связи, и так далее. Странные тулчейны, не-x86 процессоры, вот это всё

stevejobs ★★★★☆
()
Ответ на: комментарий от Virtuos86

Лет пятнадцать назад разработчики библиотеки ACE рассказывали такую историю:

К ним обратилась некая компания за консультациями по поводу использования ACE. Мол, стартует большой проект, который должен быть не просто кросс-платформенным, а еще и должен работать на куче всяких разных и не очень известных платформ. На вопрос о том, почему же не была взята Java, а остановились на C++ и ACE был получен ответ: «ACE работает на большем количестве платформ, чем Java».

Видимо, за прошедшие 15 лет ситуация кардинально поменялась :)

eao197 ★★★★★
()
Ответ на: комментарий от stevejobs

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

annulen ★★★★★
()
Ответ на: комментарий от Shadow

Мне в приданое с женой досталась книга «язык си» Уэйт, Прата, Мартин и я считал это самым главным )

vaddd ★☆
()
Ответ на: комментарий от i-rinat

Я к тому, что в Debian 7 использование C++11 доставляет ощутимые неудобства

неправда, кстати emplace (ЕМНИП) там есть

next_time ★★★★★
()
Ответ на: комментарий от cvs-255

А по скорости C уделывает обоих

тащем-та нет: любая программа на С тривиальным образом сводится к программе на С++

next_time ★★★★★
()
Ответ на: комментарий от next_time

неправда, кстати emplace (ЕМНИП) там есть

Есть, но доставляет некоторые неудобства. Попробуй вот это скомпилировать (https://godbolt.org) в GCC 4.7 и в 4.9:

#include <map>
int main() {
    std::map<int, int> s;
    s.emplace(1, 2);
}

i-rinat ★★★★★
()
Ответ на: комментарий от next_time

Ну, в Debian 7 — 4.7.2, а в Debian 8 — 4.9.2. Версия 4.8 как-то между выпусками повисла, так что меня больше беспокоила разница между 4.7 и 4.9. В 4.9 уже норм.

i-rinat ★★★★★
()
Ответ на: комментарий от cvs-255

А по скорости C уделывает обоих

Ну, положим, std::sort, скажем, на массиве int-ов выигрывает у qsort(.., .., .., cmp_int_fn)

kawaii_neko ★★★★
()
Ответ на: комментарий от Kronick

Пишут аналог std::string, то есть набор функций, работающих с парами указатель + длина.

i-rinat ★★★★★
()
Ответ на: комментарий от thunar

Я так понял, что в C вручную созданная эмуляция таблицы виртуальных функций будет работать быстрее?

Если тебе в С понадобилась эмуляция таблицы виртуальных функций, ты, явно что то делаешь не так.

BlackJack
()
Ответ на: комментарий от BlackJack

Если тебе в С понадобилась эмуляция таблицы виртуальных функций, ты, явно что то делаешь не так.

На такой эмуляции построены чуть ли не все более-менее сложные проекты на Си. Они все делают что-то не так?

tailgunner ★★★★★
()
Ответ на: комментарий от BlackJack

Ну так аффтар же зачем-то _НЕПРЕМЕННО И ОБЯЗАТЕЛЬНО_ хочет использовать абстрактные классы и утверждает что на чистом С _ЭТОТ ЖЕ_ алгоритм будет работать быстрее. Пускай аргументирует.

thunar ★★★★★
()
Последнее исправление: thunar (всего исправлений: 1)
Ответ на: комментарий от tailgunner

На такой эмуляции построены чуть ли не все более-менее сложные проекты на Си. Они все делают что-то не так?

Насколько я понимаю таблица виртуальных функций нужна только в том случае если ты пытаешся использовать класс из библиотеки написанной на С++ и не имеющей С-style API в приложении написанном на С.Обертку для класса сделать на С++ на порядок проще.Тут возникает вопрос зачем закручивать гвозди отверткой.

BlackJack
()
Ответ на: комментарий от BlackJack

Если тебе в С понадобилась эмуляция таблицы виртуальных функций, ты, явно что то делаешь не так.

На такой эмуляции построены чуть ли не все более-менее сложные проекты на Си

Насколько я понимаю таблица виртуальных функций нужна только в том случае если ты пытаешся использовать класс из библиотеки написанной на С++ и не имеющей С-style API

Эмуляция таблицы виртуальных функций - это:

struct ops {
  foo (*op1)(bar1, bar2);
  baz (*op2)(bzz, boo);
};

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Но тогда это ООП головного мозга.Это не лечится.

BlackJack
()
Ответ на: комментарий от BlackJack

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

Но тогда это ООП головного мозга.Это не лечится.

Если вы пишете на c++98/99, то какие ограничения не позволяют вам перейти на c++11/14/17? (комментарий)

tailgunner ★★★★★
()
Ответ на: комментарий от BlackJack

Указатели на функции лежат в структуре ops, на которую ссылаются отдельные экземпляры структур-объектов. По сути этот указатель и определяет текущий тип объекта. Функция фабрика может порождать объекты с различным поведением, несмотря на то, что фактически она возвращает структуру одного и того же типа.

Никогда не видел, что ли?

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.