LINUX.ORG.RU

Поломана совместимость с С в С++11?

 


2

2
cat test.cpp 
#include <stdio.h>

int main(int argc, char** argv)
{
	auto int i = 2;
	printf("Hello!\n");
	return 0;
}
 gcc test.cpp.
/a.out
Hello!
 g++ test.cpp
 ./a.out 
Hello!
 g++ --std=c++11 test.cpp 
test.cpp: В функции «int main(int, char**)»:
test.cpp:5:11: ошибка: два или более типа в декларации имени «i»

Ваши мнения по этому поводу.

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

это да - выхлопы от ощибок бывают чересчур информативны, но уже есть тенденция ухода от этого - в clang, и gcc4.8

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

Что такое «НАСТОЯЩЕЕ ОО»? И при чем тут другие языки, если мы о С и С++? Вы сами утверждали, что на С нормальное ООП. За слова отвечать не будем?

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

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

Нет. Шаблоны С++ почти идеальны для обобщенного кода. По крайней мере удобнее дженериков Java/C#. Разве что в Haskell я не чувствовал необходимость в шаблонах...

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

это да - выхлопы от ощибок бывают чересчур информативны, но уже есть тенденция ухода от этого - в clang, и gcc4.8

Полумеры, ущербность шаблонов компиляторы не изменят.

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

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

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

В чем их ущербность? Им не хватает только одного - концептов. Но их отложили на следующий стандарт...

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

Нет. Шаблоны С++ почти идеальны для обобщенного кода. По крайней мере удобнее дженериков Java/C#. Разве что в Haskell я не чувствовал необходимость в шаблонах...

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

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

s/Жабски шаблоны/Жабские дженерики/

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

Рассказывайте сказки кому-нибудь другому. Гомогенность дженироков убивает обобщенный код. Если у вас есть тайпклассы всякие и не отдельно прикрученные аналоги, а полноценные и используемые всеми, то полиморфных типов действительно вполне достаточно. А так шаблоны+концепты в С++ самая мощная штука для обобщенного программирования. Без концептов да, есть проблемы. Только не надо про интерфейсы в С# - это совсем другая песня.

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

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

C# generics do not provide the same amount of flexibility as C++ templates. For example, it is not possible to call arithmetic operators in a C# generic class, although it is possible to call user defined operators.

C# does not allow non-type template parameters, such as template C<int i> {}.

C# does not support explicit specialization; that is, a custom implementation of a template for a specific type.

C# does not support partial specialization: a custom implementation for a subset of the type arguments.

C# does not allow the type parameter to be used as the base class for the generic type.

C# does not allow type parameters to have default types.

In C#, a generic type parameter cannot itself be a generic, although constructed types can be used as generics. C++ does allow template parameters.

C++ allows code that might not be valid for all type parameters in the template, which is then checked for the specific type used as the type parameter. C# requires code in a class to be written in such a way that it will work with any type that satisfies the constraints. For example, in C++ it is possible to write a function that uses the arithmetic operators + and - on objects of the type parameter, which will produce an error at the time of instantiation of the template with a type that does not support these operators. C# disallows this; the only language constructs allowed are those that can be deduced from the constraints.

и это еще без учета C++11

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

Вы писали на ObjC? Я писал. С++ гораздо логичнее для сишника(коим я был и, в принципе, остаюсь не смотря на ++, питон, scala). И да, в Objective-C методы через хеши дергаются, что намного тормознее С++ных vtbl. Т.е. я могу взять и в старом сишном коде заменить набор указателей на функции классом, ничего при этом не потеряв. А в Objective-C я так уже делать не буду - это не бесплатно, да и дольше переделывать.

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

Ага, ты попробуй писать код, скажем, с длинной арифметикой на чистом С. Это же ад и израиль! Простенькие мат операции превращаются в нечитаемый ад, где наляпать ошибок - плевое дело. Или с многомерными массивами работать. Не-не-не, С++ нужен.

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

Вы сами утверждали, что на С нормальное ООП. За слова отвечать не будем?

Нормальное для языка без непосредственных языковых средств ОО. И это доказано множеством проектов на С.

и постепенного переноса проекта с С на С++. Сам С уже не нужен.

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

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

«Полноценная ОО» - это когда в рантайме можно заниматься полноценной рефлексией, анализом объектов. То, что в зачаточном и кривом виде в плюсах есть в виде RTTI - и что нафиг ломает совместимость с С.

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

Не-не-не, С++ нужен.

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

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

Торвальдс уже все высказал по этому поводу

Мнение Торвальдса по этому поводу стоит чуть меньше, чем ничего.

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

я все еще жду код

Я не буду тратить время на фигню. В мире много хорошего сишного кода - ищущий обрящет. Да, будет длиннее, чем иногда на плюсах - биг дил... Зато без инфернальностей типа перегрузки операторов, конструкторов, виртуальных и невиртуальных десктрукторов и пр... С - язык ПРОСТОЙ, в отличие от плюсов. В этом его мощнейшее преимущество. Достаточно сравнить размеры документации на оба языка.

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

С++ гораздо логичнее для сишника

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

Т.е. я могу взять и в старом сишном коде заменить набор указателей на функции классом, ничего при этом не потеряв

Какой ужас. За такие хаки - увольнять сразу.

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

Что-то не могу обрести shared_ptr и unique_ptr на Си.

Либо не нужно, либо где-то есть. Принципиальных проблем не вижу. Скорее всего, синтакс подлиннее, чем в плюсах. Биг дил.

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

Зато без инфернальностей типа перегрузки операторов, конструкторов, виртуальных и невиртуальных десктрукторов

А в бэйсике даже такой инфернальности как арифметика указателей нет. Советую.

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

Там же по умолчанию все функции шаблонные с точки зрения плюсов. Он же сам по себе весь из себя обобщенный.

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

Параметрический полиморфизм haskell достаточно сильно от крестового отличается, он всё-таки ближе к дженерикам, насколько я их помню.

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

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

И нам не придется все переписывать. Добиться сборки С++ компилятором - задача не сложная(тем более, в случае gcc или clang'а). А дальше новый код пишем на С++, постепенно(очень) и по мере необходимости переписывая старые подсистемы(или даже их отдельные части) на С++.

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

Это крайне редко требуется в нише С/С++. Метапрограмминг в С++ делается во время компиляции и не сказывается на тяжести рантайма. И это преимущество(если учитывать нишу), а не недостаток. ООП и без рефлексии дает хороший профит по организации кода. Ну и да, даже если мы будем сравнивать сишные структуры + набор функции и С++ные классы-значения(т.е. не полиморфные(в терминах С++, а не Haskell) классы), то сравнение будет не в пользу С.

И еще. RTTI в С++ можно отключить, не отключая ООП.

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

Я не буду тратить время на фигню

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

С - язык ПРОСТОЙ

во-первых это не так, С язык СЛОЖНЫЙ, и сложный он за счет того, что привязан к архитектурам и компиляторам, и надо знать не только ЯП, но и все нюансы, которые могут вылезти, это не считая откровенных undefined behaviors, С++ это все унаследовал, и что более важно - на С получаются сложные решения, даже со сторонними glib и пр. код получается более раздутый и нечитабельный чем на стандартных плюсах

Достаточно сравнить размеры документации на оба языка.

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

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

оба языка Тьюринг-полны.

Именно! А дальше вопрос вкуса.

Бгг. Такие заявления могут сойти с рук только заскорузлым исследовтелям CS, а из инженера делают либо тролля, либо посмешище.

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

руками делать анреф ссылкам

Wetware-реализация не интересует, нужна сишная :)

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

Для хорошей математики люди придумали фортран;)

Очень жду, когда же он сдохнет. В 70-80 он имел смысл, сейчас — нет. Достаточно посмотреть (и ужаснуться) тому, как выглядит добавление новых типов в фортране (подмножество ООП).

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

И это доказано множеством проектов на С

можно название чего-то действительно хорошего на С, что сочетает ООП и появилось в последние 10 лет,?

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

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

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

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

А если есть хороший сишный код и хорошие сишные программисты - НАФИГ не сдалось его делать плюсовым. Оторвать руки тому, кто gobject будет перетаскивать на плюсовую ОО модель.

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

Принципиальная проблема есть - в С отсутствуют деструкторы(а именно там shared_ptr выполняет декремент счетчика на объект и в случае, если он стал 0, удаляет объект). Т.е. в С тебе ПРИДЕТСЯ вызывать руками некий unref/deref(как и сделано в gobject), что убивает на корню саму идею (полу)автоматической сборки мусора и (полу)автоматического освобождения каких-либо других ресурсов.

В gcc у локальной переменной есть __attribute__((cleanup(<функция>))), который позволяет задать вызываемую при уничтожении переменной функцию, но это хозяйство плохо дружит с longjmp и пр., потому не подходит для универсального решения.

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

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

Пока в open-source выбор С еще является политически-выгодным решением. Но это, как я надеюсь, временно.

gobject - тормозное говно по сравнению с С++ ООП. Я делал свое ООП на Си(потом перевел на С++). Так вот я бы никогда не взял gobject для чистого С-проекта. Вся прелесть gobject заключена исключительно в возможности простого биндинга для других языков. И в общем, тут мой выбор уже за vala.

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

А если есть хороший сишный код

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

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

Да, но из-за вездесущих тайпклассов, ущербность дженериков там совершенно не чувствуется, а сами тайпклассы, в принципе, в чем-то схожи с плюсовыми концептами(которые, к сожалению, только планируются). Единственное, что мне не нравится в Haskell - это ленивость по умолчанию. Хотя это спорное мнение, заранее соглашусь.

В общем, на данный момент С++ мне видется единственным приемлемым инженерным решением в данной нише(условно - «системной»). С объективно хуже. D сырой и не выстрелел, да и ушел немного не в ту сторону. Go только на словах лезет в эту нишу, на деле сливает даже яве и имеет абсолютно непрозрачный рантайм. Rust еще меняется(и это сейчас для него естественно) и фиг его знает, чем станет.

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

Параметрический полиморфизм haskell достаточно сильно от крестового отличается, он всё-таки ближе к дженерикам, насколько я их помню.

Тайпклассы к параметрическому полиморфизму мало отношения имеют.

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

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

RISC-процессоры смотрят на тебя с недоумением

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

foo :: (Bar a) => a -> a

Разве тайпкласс здесь определяет параметрический полиморфизм функции? И возвращаясь к самому началу, где здесь большая близость к дженерикам, а не к шаблонам?

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

Да, но из-за вездесущих тайпклассов, ущербность дженериков там совершенно не чувствуется

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

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

Разве тайпкласс здесь определяет параметрический полиморфизм функции?

Он его не определяет, а ограничивает. На мой взгляд это попадает под понятие "иметь отношение".

На вопрос, при чём тут близость к дженерикам я точно ответить не могу, поскольку в последний раз я тыкал шарп четыре года назад. Осталось такое ощущение, плюс я неоднократно встречал похожие высказывания в сети. Поэтому я добавил "вроде".

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