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»

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

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

Ты не понимаешь философию С++ - там из коробки даже ввода/вывода нет - в смысле это уже в стандартной библиотеке. А вот thread_pool'а в стандартной библиотеке нет, есть разные реализации.

Но я сторонник event-driven, у меня «пул», как правило, создается в простом цикле(формируем N потоков, выполняющих event-loop), а потом такой же цикл с join'ами. Как основу использую boost::asio, как правило.

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

Ты тоже сейчас можешь хоть сколько оправдываться.

не понял о чем ты, ну да ладно

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

Ты не понимаешь философию С++

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

Вангую, он обязательно появится в следующем стандарте.

baverman ★★★
()

Вот кстати, если уж тут собрались эксперты по современному Си++: как принято реализовывать кольцевые списки? Если ссылка на следующий элемент является shared_ptr, то получаем циклические ссылки; если у последнего узла делать ссылку на следующий в виде weak_ptr, то получается, что каждый узел должен тащить с собой 2 ссылки: shared_ptr и weak_ptr.

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

Для начала скажи, зачем тебе кольцевой список именно на списках.

Потом объясни, какой узел считать последним.

А вообще проще будет написать отдельный тип «кольцевой список», который бы отвечал за освобождение узлов. А сами узлы пусть ссылаются друг на друга простыми указателями. Примерно так делают std::list.

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

Для начала скажи, зачем тебе кольцевой список именно на списках.

Кольцевой список мне для примера. Насчет «на списках» не понял - я не ограничиваю методы реализвции.

Потом объясни, какой узел считать последним.

Псоледний вставленный.

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

Спинлок - это только в ядре можно. В юзерспейсе из-за вытесняющей многозадачности спинлок может подвесить ЦПУ на длительное время. Если использовать while(1) { ... usleep(...); }, то система, во-первых, проиграет в интерактивности, во-вторых, в производительности. Так что спинлок в юзерспейсе - говнокод.

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

std::unique_ptr<T, D> make_c_res(T *data, D deleter)

Не очень понимаю, что вы этим хотите до меня донести. Существование STL? Гм.

Я же выше писал что развитие пошло именно по этому пути: «белый сагиб заворачивает в классы «небезопасные» вызовы С-библиотек, а ПТУ-шник индус это потом использует».

Насколько такая декомпозиция эффективна? Сложно сказать. Судя по качеству программного обеспечения - так себе. Именно поэтому мне непонятно зачем народ размахивает RAII, ООП, метапрограммированием, последним стандартом С++ и доказывает что уж это точно та самая серебрянная пуля. Нет, это среднего качества идеи, каких-то прорывных преимуществ перед использованием старых идей они не дают. Более того, их освоение занимает достаточно много ресурсов с невнятным результатом.

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

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

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

В юзерспейсе из-за вытесняющей многозадачности спинлок может подвесить ЦПУ на длительное время.

И? Это сразу делает его более дорогим чем пассивные примитивы синхронизации?

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

А что про тип думаешь, ИМХО, самое оптимальное решение. Узлам нет смысла считать ссылки друг на друга - хозяин у них один - список.

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

А что про тип думаешь, ИМХО, самое оптимальное решение

Может быть. Я не пишу на Си+ очень давно, так что не в курсе современных подходов.

Узлам нет смысла считать ссылки друг на друга

А если ссылка на узел выдается наружу (т.е. владельцем является не список)?

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

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

На счет успешности проектов - это все ваши фантазии.

И что значит, насколько эффективна такая декомпозиция? Разве бывают ситуацию, где явное ручное освобождение ресурсов лучше, чем автоматическое? Чем программа, говорящая явно fclose(f) лучше той, что закрывает файл тогда, когда он не нужен? Чем язык, не позволяющий делать второе, может быть лучше?

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

Мы тут сравнивали два языка - С и С++. Первый всем хуже второго.

Как язык - может быть, но рантайм Си гораздо прозрачнее, а ABI - гораздо проще.

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

Не понял. Тип ноды будет закрытым для клиентов списка и владельцем никто быть не может.

Т.е. использовать будут как-то так:

circular_list<int> lst {1, 2, 3, 4, 5};

Правда я так и не понял, какую(ие) задачу(и) вы хотите с помощью него решить.

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

Это единственное, да. Но никто вам не мешает выставлять extern «C» функции для внешнего мира.

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

Там нет STL. lol

Точно. Это я увидел std: и поленился гуглить. Ну, срезал, чо. Пойду порыдаю

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

Мы тут сравнивали два языка - С и С++. Первый всем хуже второго

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

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

Может быть С++ программисты настолько интеллектуально выше остальных людей, читают очень много умных книг что им не хватает времени писать нормальный код? Как объяснить то что мне здесь показывают как легко и просто надо писать идеальные не падающие и не текущие программы на С++, а в реальной жизни сплошное УГ, которое крешится и течет? Одни загадки

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

Опять фантазии... Никто тут ничего не говорил о каких-то там идеальных программах. Вам показалось. Что у вас там крушится и течет, а что работает стабильно? Почему опять нет конкретики? Вас тут С++ники примерами завалили уже, а у вас в ответ отмазки и фантазии.

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

Что вы опять о чем-то, что пощупать незя? Можете как-либо показать, в чем заключается преимущество С?

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

У Си нет преимуществ. Просто некоторые оправдывают свою тупость и лень сказками о какой-то непомерной сложности С++.

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

В С++ куча неоднозначностей, которых нет в С. Особенно это касается шаблонов и всяких там новых type_traits'ов. Многие вещи в С++ приходится зазубривать и они очень быстро забываются, если какое-то время не берешь С++.

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

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

Ну так не используй эти неоднозначности... Они возникают в весьма нетривиальном коде.

Используй С++ хотя бы как улучшенный С - namespace, RAII, разумно шаблоны, ООП и исключения.

anonymous
()

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

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

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

Об этом напишите команде разработчиков nginx (которые пишут свой код на чистом Си) и пришлите мне ссылку, чтобы мне посмотреть на Вашу «дуэль».

ООП, С++, и все новые тренды на их базе (в том числе java, go) отвлекают от создания реально полезных, экономичных и быстрых программ, хотя бы на том же чистом Си.

Еще раз, если Вы считаете себя умнее разработчиков nginx, напишите им об этом.

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

Об этом напишите команде разработчиков nginx (которые пишут свой код на чистом Си)

ООП, С++, и все новые тренды на их базе (в том числе java, go) отвлекают от создания реально полезных, экономичных и быстрых программ, хотя бы на том же чистом Си.

Почитай исходный nginx, там ООП на си. Почитай код Linux. Конкретно kobject.

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

Одного взгляда на код nginx достатачно, чтобы понять, что он говно, а админам не нужно писать код.

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

ООП - это не только структуры + методы, но и наследование как минимум, этого я не вижу в «ООП на си».

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

но и наследование как минимум, этого я не вижу в «ООП на си».

struct parent
{
    int m1_;
};

struct child
{
    struct parent parent_;
    int m2_;
};

child* c = ...;
parent* p = (parent*) c;
wota ★★
()
Последнее исправление: wota (всего исправлений: 1)
Ответ на: комментарий от wota

Это не более чем построение списка для древовидной структуры.

Надесь что знаете, чем наследование в ООП отличается от связанного списка элементов (в роли элементов в Вашем примере структуры).

Слова child и parent здесь даже не намекают на излишество в виде классов и их наследование в ООП.

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

Это не более чем построение списка для древовидной структуры
Надесь что знаете, чем наследование в ООП отличается от связанного списка элементов (

тут нет никакого списка, смотри внимательно

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

Именно так в С++ реализовано наследование... Если в классе(или базовом классе) есть виртуальные функции, то будет еще указатель на таблицу указателей на функции.

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

Ты хочешь развести нездоровую дискуссию? Или у тебя есть аргументы в пользу того, что в ядре не используются подходы ООП?

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

Ты хочешь развести нездоровую дискуссию?

Нет ты.

Или у тебя есть аргументы в пользу того, что в ядре не используются подходы ООП?

У меня есть аргумент, что kobject относится к «использованию ООП» лишь чуть больше, чем никак. Я по работе драйверы пишу и и с kobject знаком не на уровне «почитай код Linux».

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

Пример полиморфизма в рантайме в сях, в ядре - VFS, драйверы блочных/символьных устройств. Достаточно описать некоторые функции VFS и зарегать свою ФС в ядре. В ядре вообще подобный подход повсеместно используется с таблицами функций.

http://www.tldp.org/LDP/khg/HyperNews/get/fs/vfstour.html

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

У меня есть аргумент, что kobject относится к «использованию ООП» лишь чуть больше, чем никак.

Это повод для хамства? Не мог сразу так написать?

Напиши лучше, почему kobject не относится к ООП (никак не относится к ООП).

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

Это повод для хамства? Не мог сразу так написать?

Пиши о том, что знаешь.

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

Значит, ты плохо знаком с ООП.

Что именно заставило тебя так подумать?

Можешь объяснить, что ты называешь ООП?

Грейди Буч объяснит.

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

Он ничего не может объяснять. Он пишет только о том, что знает, но ничего по теме.

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