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

В частности, необходимость явного приведения типов заставляет, глядя на код, каждый раз думать - надо ли в данном месте передавать void*?

Ничего оно не заставляет, потому как решение передавать void сделано совсем другим программистом, чаще всего в другом проекте и совсем не рекдо от которого только двоичные либы. И в 99,9(9)% случаев, это решение сделано правильно, ничего универсальнее T (*callback)( mandatory args..., void *user_data) для двоичных интерфейсов пока не придумали.

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

Автор живет на другом конце мира, закончил этот проект N лет назад, и давным-давно позабыл об этом «решении».

Так какая польза _программисту_ от этой бессмысленной операции?

За который надо убивать.

Начинайте с авторов libc.

Убийца ты наш, передай параметр в функцию нити как-нибудь по-другому.

template<typename T> void f(T x) {...}

И это ты собираешься передать в pthread_create?

Сабж не читал?

Сообщение, на которое ты отвечал, является частью вот этой подветки: GCC переходит на С++ компиляцию самого себя с целью улучшения качества кода (комментарий)

Гемморой при переносе на другие плафтормы, если гцц завяжется на плюсовый рантайм.

C++ никогда не требует более кривого кода.

Т.е. код на C++ всегда достаточно кривой?

#include <iostream>
#include <thread>
using namespace std;

template<typename T>
void f(T x) {
	cout<<"fcplm"<<x<<endl;
}

int main() {
    thread th(f<int>, 1);
    th.join();
}

С pthread_create работал лично, с некоторыми частями posix и winapi тоже. По этому и говорю. -_-

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

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

Так какая польза _программисту_ от этой бессмысленной операции?

Проверка себя. Простота поддержки кода других людей.

Никакой ОПЕРАЦИИ тут вообще нет, компилятор не генерит никакого кода (ну, если мы не переопределяем операторы, тут совсем другая история). Считайте это комментарием в коде. Полезным. Требуемым. Функция ожидает, что ей передадут MyStruct *, и указывает это явно.

И еще. Конкретный callback можно вообще определять так:

T MyCallback( mandatory args..., MyStruct *user_data)

И приводить в явном виде (тип не параметра, но функции!), когда передаешь его параметром:

SomeSmartAPIFunction(.... APIFUNCCALLBACK(MyCallback))

pthread_create

thread

Найдите N отличий.

#include <thread>

a.cc:2:18: error: thread: No such file or directory

С pthread_create работал лично

Но, тем не менее, вызов pthread_create не написал. А то, что достаточно толстая обертка спрячет всё, что нужно, как бы очевидно.

Никакой ОПЕРАЦИИ тут вообще нет

Т.е. приведение типа - это не операция в терминах С? Как много нам открытий чудных...

Конкретный callback можно вообще определять так:
T MyCallback( mandatory args..., MyStruct *user_data)

Эй, секундочку. Откуда тот чувак на канарах, который закочнил проект 10 лет назад, знает, какую структуру _я_ буду использовать здесь и сейчас в этом проекте?

передай параметр в функцию нити как-нибудь по-другому.

pthread_create точно не будет ничего кастовать, а сама «функция нити» может получать указатель на все что угодно, т.е. проблемы никакой нет

pthread_create точно не будет ничего кастовать

А кто-то утверждал, что будет?

проблемы никакой нет

Приведи мне код. Тот, который ты уже приводил, но удалил, компилировался с серьезным предупреждением.

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

ага, очень-очень серьезным, про неявное приведение указателя ;)

Но, тем не менее, вызов pthread_create не написал

Госпади, да это же самая сложная операция в мире, только ты один так можешь. Да здесь каждый второй с ним работал. -_-

Но, тем не менее, вызов pthread_create не написал. А то, что достаточно толстая обертка спрячет всё, что нужно, как бы очевидно.

Мы о чём говорим вообще? О void*. Его главная проблема - отсутствие типобезопасности. С шаблонами такой проблемы нет(а ещё они эффективнее, да). Profit.

это не операция в терминах С

В терминах генеримого кода - 0 байтов.

какую структуру _я_ буду использовать здесь и сейчас в этом проекте?

Если он написал эту самую SomeSmartAPIFunction, для него этот указатель прозрачен. Ему ничего приводить не надо. Он передает его тупо в callback при вызове. А то, что я передаю параметром MyCallback - я сам знаю. И я же передаю правильный указатель.

в рамках улучшения качества кода

C++

Заявка на разрыв шаблона?)

Госпади, да это же самая сложная операция в мире, только ты один так можешь.

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

Да здесь каждый второй с ним работал. -_-

Афигеть.

Мы о чём говорим вообще?

Вообще - о том, какие последствия для кода влечет переход с Си на Си++, в частности - я уже давал тебе ссылку.

очень-очень серьезным, про неявное приведение указателя ;)

Хм. То есть ты не считаешь такие предупреждения серьезными? Таки ты реально норкоман.

То есть ты не считаешь такие предупреждения серьезными?

считаю конечно, я вообще собираюсь всегда с -Werror

Таки ты реально норкоман.

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

я вообще собираюсь всегда с -Werror

вдруг ты не поймешь - это про рабочий код ес-но

И приводить в явном виде (тип не параметра, но функции!)

Не сразу заметил. Да, можно. Но это еще более бессмысленная замена шила на мыло - вместо одного приведения типов (аргументов) имеем другое - типов функций. В чем смысл?

void* был _введен_ в си с единственной целью - чтобы ему можно было присваивать значения указателей любого типа, и чтобы из него можно было считать значение указателя любого типа. Это - семантика самого _типа_. Любое присваивание в и из одновременно есть привидение типа. Так зачем это дублировать?

и мыслительный процесс у меня неправильный,

Парадоксальный, я бы сказал.

не переживай

Даже и не думал.

Мне показалось или ты хочешь прочитать вот это?
http://stackoverflow.com/questions/5046755/i-use-c-style-casts-in-my-c-projec...

В терминах генеримого кода - 0 байтов.

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

Тебе показалось, причём совершенно не ведомо с какого бодуна. Где ты обнаружил дочерние классы выше по теме - пусть останется твоим маленьким секретом. ;)

А что, каст только классах бывает? Интересно! Бодун такой, что C касты оставь для C :}

В чем смысл?

Я же сказал - явное указание того, что раньше было неявно.

А _что_ было не явно? Объясни, пожалуйста, я никак не пойму.

Вот прототип:

void (*callback)(void* data);

вот код

void my_callback(void *data) 
{
	struct my_data *p = data;
	...
}

void main(void)
{
	...
	struct my_data data;
	...
	some_library_func(some_library_handler, my_callback, &data);
	...
}

Что в нём «неявного»? Я что-то никак в толк не возьму.

Я где-то читал, что самый адекватный нативный код из Си генерирует gcc примерно версии 2.95. В поздних версиях вроде как что-то поддержали новое и всё поломали.

Я правильно запомнил?

У кого-там на гугл плюсаче аккаунт есть? Спросите что по этому поводу думает Линус.

gcc и раньше конпелялся долго, а теперь этот процесс вообще будет занимать часы. мой домашний «сервер» дурон-700 с 256 мб памяти не выдержит :(

вот оно что, а я сегодня как раз с этим столкнулся.
Два чаю этому господину.

То, что my_callback надо сразу объявлять с правильным аргументом. И приводить при вызове some_library_func. Тогда В ОДНОЙ СТРОЧКЕ будет видно, что данные типа my_data и функция, ожидающая my_data

Я думаю он обрадует нас каким-нибудь вбросом, и так уже один был:-)

видел тред на одной странице:-)

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

Придется бинарный ставить.

а я сегодня как раз с этим столкнулся

Случаем, не стратагус компилял?

Привет срачЪ и шотакот!

Что в нём «неявного»? Я что-то никак в толк не возьму.

вот что в нём неявного:

void* data = ...;
struct my_data *p = data;

что непонятно тут?

Это только если они шаблоны заюзают.

C++ никогда не требует более кривого кода.

ну прально, а то на сях всякие:

mytype1 = add_my_type(mytype1, mytype2);

^ это и есть вырвиглаз. На спп операторы перегрузил и делов то:

mytype1 += mytype2;

Более чистый и понятный код получяется.

А почему не на haskell? :)

И вообще - передачу параметров через void* оценят на этом ресурсе.

Нормальный способ передавать данные в обобщенную функцию.

вот потому что «нормальный» Си по факту считается языком с нестрогой типизацией

В ОДНОЙ СТРОЧКЕ будет видно, что данные типа my_data и функция, ожидающая my_data

Вне зависимости от того, что и куда я приведу, в месте вызова some_library_func информация о типах my_callbak и data не описана - т.е. для читающего исключительно эту строку программиста её нет. Описания типов нет и не может быть в коде вызова функции ни при каких привидениях типов. Информация об их типах содержится только в месте их определения/объявления. Нигде далее по месту их использования их тип не описывается.

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

int a; float b; f(a,b);

Попробуй привести какой-нибудь другой аргумент.

http://nooooooooooooooo.com/

Мне всё понятно. Я все типы и их приведения вижу явно. Мне не понятно, что тебе тут не понятно?

Ни черта не понял. Новость дерьмово написана.

Мне всё понятно. Я всё типы и их приведения вижу явно.

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

Странно читать такие новости в 21м веке. Всё таки с++ это тяжёлое наследие старины, которое живо до сих пор только потому, что кого-то угораздило наговнокодитить на этом говне тоны кода. Если девелоперам гцц хотелось красивого, совремнного, объектно ориентированного языка со строгой типизацией, можно было использовать Vala. Великолепный язык, хоть корнями он из c#, всё же создателям удалось просто невозоможное — сделать из говна конфетку. До сих пор восхищаюсь этим языком. Да пришлось бы многое переписать, да появилась бы необходимость исмользовать gobject, но зато каков бы был результат! А так... сделали огромный шаг назад. Боюсь, что лет через 5 мы будем вспоминать гцц как страшный сон, и не в первую очередь из-за репутации, которую он за это время заработает.