GCC переходит на С++ компиляцию самого себя с целью улучшения качества кода

Лучше б на D переходили.

GNU переходит на C++. epic fail

Мне казалось или я до этого говорил о С++? А pthread_create ЕМНИП является функцией C-шной библиотеки. Проти случаев использования void* в чистом C я и не возражал ибо там замену ему найти проблематично...

Это даст указание а-ля «i am sure to do this», то есть в случаи ошибки это будет осознанный выбор программиста, а не банальная невнимательность. Ошибка никуда не денется, просто отловить ее будет проще(если код будет посложнее указанного)

QObject

И получится Qt

очевидный фикс

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

А вообще лучше бы придумали какую-то альтернативу крестам без указателей, со сборкой мусора (ну что-то вроде Vala), с человеческими лямбдами и т.д. Кресты это тупиковый язык программирования.

теперь тут строчка, осознанна введенная программистом с желанием «я хочу выстрелить себе в ногу^W^W^W^W привести именно к такому типу». А не «я приравнял что-то к чему, компилятор на ошибку не ругнулся, значит всё ОК»

ИМХО reinterpret_cast - это последнее дело и нужно точно понимать что ты делаешь, вызывая его. static_cast получше будет...

Уж сколько лет я вижу как кресты(как и фряху) пытаются закопать. Да вот чё-то только они не закапываются. Может потому, что не все так плохо, как воют анонимные аналитики?

P.S. В C++ как и в ЛЮБОМ языке программирования есть свои недостатки(К.О., да). Просто каждому - своё...

Сбрендил? Речь о касте void*

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

D уже давно придумали.

C++ это один сплошной недостаток. спятивший волосатик придумал какое-то УГ, ну а лемминги из коммерческого IT как зеленые мухи набросились на эту какашку.

foo *p = static_cast<foo*>(arg);

Вообще, reinterpret_cast.

Да, точно.

*Язык* не защищает тебя в этом случае. Вообще никак.Если ты присваиваешь какое-то значение, ты в любом случае _знаешь_, что именно ты присваиваешь. Всё, что язык по настоящему заставляет тебя сделать - напечатать несколько бессмысленных букв.

Причём, не просто бессимвольных, а потенциально опасных. Если тип указателя потом изменится с void* на что-то более осмысленное, напечатанный тобой код будет это явно ингорировать, что как раз действительно чревато потенциальными ошибками.

. Ошибка никуда не денется, просто отловить ее будет проще

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

О да..... если C подмножество C++ то обязательно в нём (C++) писать именно в сишном стиле. А потом появляются проекты типа gSOAP, падающие под нагрузкой, да ещё и так, что даже крякнуть ничё не успевает и формить HTTP хидеры. А само слово struct не кажется лишним? раз уж заговорили о удобоваримости кода.

Похоже на такие новости надо вводить комментирование только зарегистрированными пользователями.

Если хотите нормальный типобезопасный язык, на котором не нужно неделями искать сигфолты - юзайте Паскаль. Компилятор FreePascal доступен даже под bada, для него доступны почти все существующие библиотеки Еще lua норм

...тормознутый, плохо переносимый и недопиленный

ну что за бред... как может тормозить код, который билдится через промежуточную стадию pure c. да что может быть тормознутее плюсов, с их говношаблонами. В инете полно тестнов, где плюсы сливают производительности даже руби. Я смотрю в треде слишком дофига старых пердунов, которые ухайдохали годы жизни на освоение плюсов, и просто отказываются замечать, что есть гораздо лучшие решения. На мир надо ширше смотреть, господа. Всё-таки прав был человек, который утверждал, что плюсы портят мозг программистам.

Давно ещё, когда начали проект переписывания.

Вы несомненно хотели сказать: 'Проект закапывания.' Уверен, не обошлось здесь без засланных казачков, всё таки это удар в самое сердце проекта GNU...

А чем конкретно вала не устраивает. Там делов-то осталось, убрать конченные конструкции вида Class, ~Class и всё. Можно юзать.

А чем конкретно вала не устраивает. Там делов-то осталось, убрать конченные конструкции вида Class, ~Class и всё. Можно юзать.

Точнее Class(), ~Class().

какая драма

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

то есть если сгенерировать сразу в машинный код, программа автоматом будет летать «быстрее процессора»? охлол :)

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

только придурки которые не знают что такое шаблоны, но мнение имеют

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

да, в интернете полно макак с кривыми руками, интернет он такой, что делать

Всё-таки прав был человек, который утверждал, что плюсы портят мозг программистам.

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

А pthread_create ЕМНИП является функцией C-шной библиотеки.

Наркоман?

Вы несомненно хотели сказать: 'Проект закапывания.'

Ну я даже с вами соглашусь отчасти.

А разница в чём?

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

+1

Почему некоторые не могут этого понять? (

Если хотите нормальный типобезопасный язык, на котором не нужно неделями искать сигфолты - юзайте Паскаль.

Эти сказки хорошо рассказывать тем, кто не писал на Паскале, да.

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

+1

и С++ это решает:

$ cat ./1.cpp
struct A {};
struct B {};

int main()
{
	A a;
	void* vp = 0;

	B* p1 = static_cast<B*>(vp);
	B* p2 = static_cast<B*>(&a);
}
$ clang++ ./1.cpp
./1.cpp:10:10: error: static_cast from 'A *' to 'B *' is not allowed
        B* p2 = static_cast<B*>(&a);
                ^~~~~~~~~~~~~~~~~~~

даешь ядро линупс на си++11 ^_^

и С++ это решает

А в Си решено из коробки, если типы не приводить )

А в Си решено из коробки, если типы не приводить )

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

тормознутее плюсов, с их говношаблонами

Жестят тут анонимусы ))) Пишите на vala короче, код потом преобразуется в С, который скомпилируется в машинный код компилятором который внезапно написан на С++ )))

Но в Си это невозможно, использование void * неизбежно, и мелкие удобства при его использовании приятны.

когда мы кастим от Parent* к Child*, то каст не выписываем; когда кастим наоборот, то выписываем:

Сhild* child_ptr = (Child*) parent_ptr;

теперь вопрос — почему мы должны сделать исключение из этого простого (и возможно даже естественного) правила, когда у нас роль Parent* играет void* ?

void*, кстати, нужен в плюсах, когда хочется сделать например свой параметрический полиморфизм

В С++ необходимость в void* возникает только в двух случаях:
1) использование кода на С
2) недостаточная компетентность прогера (местоположение рук, головы)

3) необходимость реализовать языковые конструкции, не поддерживаемые напрямую с++, скажем, параметрический полиморфизм

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

Да, не без недостатков!

На Java переписать. Я серьезно )

void*, кстати, нужен в плюсах, когда хочется сделать например свой параметрический полиморфизм

use case можно?

когда мы кастим от Parent* к Child*, то каст не выписываем; когда кастим наоборот, то выписываем:

Сhild* child_ptr = (Child*) parent_ptr;

1) ты тут что-то перепутал
2) c-style cast не даёт никакой гарантии

Лучше тогда на Scala или Clojure.

На Java переписать. Я серьезно )

ужасный ЯП :) он и не остался(не стал) действительно простым, как задумывалось, и развитие у него достаточно кривое и медленное, так что лучше сразу смотреть на Go или D, правда пока лучше именно смотреть

>Лучше б на D переходили.

Хорошо пошутил.

1) ты тут что-то перепутал

да, должно было быть «когда мы кастим от Child* к Parent*, то каст не выписываем»

2) c-style cast не даёт никакой гарантии

да (вместо Child* можно взять хоть int*), и что это меняет? язык заставляет явно выписать хоть абы какой (т.е. не дающий никакой гарантии), но каст

Читал где-то, что иначе будут накладные расходы на обработку несуществующих исключений. Ну и в libc почти все функции так помечены.

__attribute__((nothrow)) и throw() (до C++11, по крайней мере) — абсолютно разные вещи.

throw() из плюсов как раз-таки может привести к накладным расходам — по стандарту должен вызывать unexpected(), если вдруг из функции брошено исключение, противоречащее её спецификации исключений. Как следствие, компилятор должен добавлять такую проверку в код для каждой функции со спецификацией исключений (в gcc отключается при помощи -fno-enforce-eh-specs).

А вообще лучше бы придумали какую-то альтернативу крестам без указателей, со сборкой мусора (ну что-то вроде Vala), с человеческими лямбдами и т.д. Кресты это тупиковый язык программирования.

Go? Указатели, правда, есть, но без арифметики, сборка мусора присутствует, анонимные функции в наличии.

Параметрический полиморфизм поддерживается С++ напрямую, достаточно посмотреть на такие сущности как например потоки: cin, cout. Или я ваш пример не так понял.

ООП заключается в абстрагировании данных через интерфейсы, если вы передаете void* значит вы оперируете данными напрямую, а это уже не ООП.

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

Оптимизации? Виртуальная машина никогда не позволит сделать быстрый код. Применение виртуальной машины делает работу удобнее, но платить за это приходится скоростью.