A
this->. Как будто не видно, что я обращаюсь к non-static мемберу класса.Size: a a a
2020 May 04
ПК
Лично меня больше всего раздражает не это, а необходимость писать
Это как раз понятно, иначе на каждый идентификатор компилятору пришлось бы лезть в базовые классы
ПК
так пусть лезет, почему это моя проблема должна быть?
Твоя проблема - замедление компиляции
ПК
это не проблема, а вот корявый исходный код и тупые ошибки компиляции на ровном месте - действительно проблема
Ну тут как бы ты не платишь за то что не используешь, код, не обращающийся к мемберу будет за это платить, если переложить это на компилятор
A
С++ и так настолько долго компилится, что ещё 1 мс можно и заплатить за удобство.
Помню, когда мой рабочий проект впервые портировали на Андроид и начали активно там пилить, году в 2012-2013, компилятор был GCC 4.8 или 4.9, и я нарадоваться не мог, насколько быстрее андроидный проект компилился по сравнению с десктопным на той же машине и почти с тем же кодом в MSVC (2010 или 2012 тогда). Но с годами GCC всё замедлялся и замедлялся, сокращая разрыв, а когда Андроид NDK перевели на clang, стало одинаково). Вероятно, и с GCC 7 тоже уже было одинаково.
Помню, когда мой рабочий проект впервые портировали на Андроид и начали активно там пилить, году в 2012-2013, компилятор был GCC 4.8 или 4.9, и я нарадоваться не мог, насколько быстрее андроидный проект компилился по сравнению с десктопным на той же машине и почти с тем же кодом в MSVC (2010 или 2012 тогда). Но с годами GCC всё замедлялся и замедлялся, сокращая разрыв, а когда Андроид NDK перевели на clang, стало одинаково). Вероятно, и с GCC 7 тоже уже было одинаково.
Г
С++ и так настолько долго компилится, что ещё 1 мс можно и заплатить за удобство.
Помню, когда мой рабочий проект впервые портировали на Андроид и начали активно там пилить, году в 2012-2013, компилятор был GCC 4.8 или 4.9, и я нарадоваться не мог, насколько быстрее андроидный проект компилился по сравнению с десктопным на той же машине и почти с тем же кодом в MSVC (2010 или 2012 тогда). Но с годами GCC всё замедлялся и замедлялся, сокращая разрыв, а когда Андроид NDK перевели на clang, стало одинаково). Вероятно, и с GCC 7 тоже уже было одинаково.
Помню, когда мой рабочий проект впервые портировали на Андроид и начали активно там пилить, году в 2012-2013, компилятор был GCC 4.8 или 4.9, и я нарадоваться не мог, насколько быстрее андроидный проект компилился по сравнению с десктопным на той же машине и почти с тем же кодом в MSVC (2010 или 2012 тогда). Но с годами GCC всё замедлялся и замедлялся, сокращая разрыв, а когда Андроид NDK перевели на clang, стало одинаково). Вероятно, и с GCC 7 тоже уже было одинаково.
То есть сейчас лучше использовать clang вместо gcc?
OS
А еще GCC 4 компилировал всякий нестандартный шлак, в итоге апгрейд компилятора сопровождался изменениями кодовой базы
CD
Лично меня больше всего раздражает не это, а необходимость писать
this->. Как будто не видно, что я обращаюсь к non-static мемберу класса.мемберу или тайпнейму или функции?
A
А еще GCC 4 компилировал всякий нестандартный шлак, в итоге апгрейд компилятора сопровождался изменениями кодовой базы
вроде, флаг
-pedantic-errors это лечил. Ну и не указывать -fpermissive, конечно.A
мемберу или тайпнейму или функции?
Пусть компилятор разбирается и подставляет, из контекста понятно, что там на самом деле.
CD
Пусть компилятор разбирается и подставляет, из контекста понятно, что там на самом деле.
int (x);
разберите значение оператора в случаях, если
P.S. кажется, я ошибся с примером, но такие конструкции точно существуют
разберите значение оператора в случаях, если
P.S. кажется, я ошибся с примером, но такие конструкции точно существуют
CD
????