Производительность Java, C и C++

«extensions»

слово extensions вам перевести или вы сами с гуглом справитесь?

кавычки видишь?

Вряд ли он знает, что кавычки означают :)

там еще дальше написано:

// They are used, strictly speaking, only by the moc.

так вы наверно мне расскажете, как собрать Qtшную программу С++ным toolchainом? gcc, ld, все дела. я просто знаю, что С++ные программы собираются с помощью gcc и ld. в особо злых случаях gold с параметрами. но собираются, инфа 100%.

я раньше думал что ты тролль, но ты реально дебил)

Одинаковое.

Если выкинуть, то работать не будет.

стоооооп. то есть если я пишу:

class foo {
  ...
public slots: 
   void a();
signals:
   void b();
}

class foo {
   ...
public: 
   void a();
public:
   void b();
}

может у вас какое-то своё определение макросов?

Вопрос: чем вызвано массовое увлечение написанием десктопного ПО на java

Откуда это видно и слышно? У меня на десктопе от силы 2-3 приложения на Java, остальное на C/C++. И это скорее исключение, чем правило. У других - ни одного.

стоооооп

Куда еще «стооооп»? Вы и так тормозите страшнее некуда.

Компиляция в случае C++ — это получение объектного файла. Объектный файл, так уж получилось, строится C++ компилятором. Что для Qt-шной программы, что для не-Qt-шной.

Однако, для получения _работающей_ программы, одного объектного файла недостаточно (т.е. одной лишь стадии компиляции недостаточно), нужно еще собрать все необходимое для этого объектного файла, как то: другие объектные файлы (построенные посредством компиляции других единиц трансляции) и необходимые библиотеки (как стандартные, так и сторонние).

И вот тут выяснится, что если отказаться от обработки C++ кода Qt-шной программы moc-ом, то сборка не пройдет, т.к. нет тех кусков C++ кода, за генерацию которых отвечает moc.

Отсюда и «Если выкинуть, то работать не будет».

При этом сам исходный C++ код, который идет на вход moc-у, остается точно таким же, moc в него никаких изменений не вносит. Что и не позволяет считать moc компилятором для компиляции Qt-шных программ, а Qt не позволяет считать каким-то новым языком программирования.

Что из вышеизложенного вам не понятно?

qt уже предлагает делать модульные сборки...

То есть для сборки какой-нибудь qt-приблуды больше не надо каждый раз разворачивать qt-everywhere-opensource-src-4.8.7.tar.gz размером 241 МБ, что-то из него доставать и компилировать?

ну 5 версия вроде так и компилируется по модульно, отдельно core, отдельно widgets и так далее. Только проблем, вроде, от этого стало не меньше, а больше.

Однако, для получения _работающей_ программы,

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

Вот, по поводу slots: https://github.com/qt/qtbase/blob/401d9b527823ffc8691e8a624ee3d40495622359/sr... Ну и emit там чутка пониже: https://github.com/qt/qtbase/blob/401d9b527823ffc8691e8a624ee3d40495622359/sr...

не так уж сложно «размотать» эти макросы, и окажется что «public slots» == «public», «private slots» == «private», «signals» = «public». это не я придумал, так препроцессор делает.

так почему

одного объектного файла недостаточно

? это же макросы. прогнать их через препроцессор достаточно. или это всё таки не макросы? вот давайте этот вопрос проясним. «slots» и «signals» это макросы или не макросы?

так почему

Есть очевидный, но неполиткорректный ответ: вы дебил. Объясняет вообще все. Делает ненужным дальнейшее объяснение.

Есть еще один ответ: вы тролль. Опять же, дальнейшее объяснение не нужно.

Если не то, не другое, то читать до просветления: Производительность Java, C и C++ (комментарий)

как же тяжело ответить на такой простой вопрос, предполагающий только два ответа «да» или «нет».

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

как же тяжело ответить на такой простой вопрос, предполагающий только два ответа «да» или «нет».

не так уж сложно «размотать» эти макросы, и окажется что «public slots» == «public», «private slots» == «private», «signals» = «public». это не я придумал, так препроцессор делает.
так почему

да

как же тяжело ответить на такой простой вопрос

Это не простой, это вопрос не имеющий смысла. Посему ответить на него не представляется возможным. Тем более, что просто огромный объем пояснений уже был дан выше.

простой пример

в хедаре заданно:
...
signals:
  void error_connect(QAbstractSocket::SocketError);
  void ready_to_parse(const QByteArray);
вот что оказалось в файле moc_*.cpp
// SIGNAL 0
void link_master::error_connect(QAbstractSocket::SocketError _t1)
{
    void *_a[] = { Q_NULLPTR, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 0, _a);
}

// SIGNAL 1
void link_master::ready_to_parse(const QByteArray _t1)
{
    void *_a[] = { Q_NULLPTR, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 1, _a);
}

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

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

«slots» и «signals» это макросы или не макросы?

.....барабанная дробь......

это не макросы. это keywords, которые порождают дополнительный код. точно также как virtual создает entry в vtable и трамплины для коррекции this. конкретная реализация - в виде дополнительного кода на С++ или в виде кода в gimple, или кода в llvm ir - не влияет на суть, т.к. она скрыта от разработчика.

это не макросы

Я вас ткнул в код самого Qt, где английским по белому было сказано, что это макросы.

это keywords,

С точки зрения moc-а — несомненно. Для С++ — ничего подобного. Поэтому C++ный компилятор эти «keywords» проглатывает так же хорошо, как и BOOST_SCOPE_EXIT.

которые порождают дополнительный код

Точнее говоря, moc генерирует дополнительный C++ный код (в отличии от ситуации с virtual в случае с компилятором языка C++).

Поэтому moc — это кодогенератор. Но никак не компилятор. И уж тем более, не тот компилятор, посредством которого компилируются Qt-шные программы.

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

а то представление, с которым работают, явно различает public и public slots.

и slots не ведет себя как макрос - он ведет себя как keyword, который «невидим» для компиляторов с++, но вызывает нетривиальные изменения во внутреннем устройстве класса во время сборки.

эти слова меняют результат компиляции класса. без них и с ними у вас разный функционал. как это сделано под капотом - это вообще десятый вопрос. я туда не смотрю. я написал в моей программе slots и signals и получил конкретный функционал. в С++ этого нет ни с какими макросами.

да какая разница что генерирует moc. это его внутренние данные, с которыми разработчик не работает. он там может хоть музыку сочинять.

да какая разница что генерирует moc

Для того, чтобы понять, является ли moc компилятором, и есть ли такая штука, как новый язык Qt/C++, — просто принципиальная разница.

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

ну 5 версия вроде так и компилируется по модульно, отдельно core, отдельно widgets и так далее. Только проблем, вроде, от этого стало не меньше, а больше.

И получили кучу архивов с исходниками от 1 до 60 МБ, от которых почти невозможно отказаться, и что это меняет? Пример списка необходимых исходников: http://www.freshports.org/devel/qt5-buildtools/ Если хочешь что-то собирать, будь добр, постоянно держи среду разработки на своей машине. Если нужно что-то собрать маленькое и единичное, то распакуй их все (а потом удали).

я и говорю что проблем вроде больше, хотя четко отделяется обязательная и не обязательная часть

как новый язык Qt/C++

Где в стандарте почитать про moc расширения для крестов? Новый синтаксис -> новый язык. Культешный код компилятором крестов не собирается, значит, не кресты. Вот сгенерированный после moc код — кресты. А то так можно договориться, что любой язык, транслируемый в си — си, даже кресты, особенно времен сифронта.

Новый синтаксис -> новый язык.

Нет нового синтаксиса. Еще раз, для вновь прибывших: тот же самый С++ный код, который подается на вход moc-у, затем (или перед тем) подается на вход C++компилятору. Тот же самый код.

Все остальные аргументы касательно того, почему moc — это генератор, а не компилятор, уже было многократно описанны выше. Перечитайте хотя бы пару последних станиц обсуждения.

Нет нового синтаксиса.

Где в стандарте описаны signal: и slot: ?

почему moc — это генератор

Генератор сахарка, да, реализующий синтаксические расширения. Язык с расширенным синтаксисом — это уже новый язык, очевидно. Иначе у нас бы и рэкет звался бы схемой, и кресты — сишкой.

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

Компиляторы — это программы, которые преобразуют исходные тексты программ, написанные на языке программирования высокого уровня, в программу на машинном языке, «понятную» компьютеру.

В этом определении есть такое интересное словосочетание: исходные тексты программ.

По смыслу, исходные тексты программ - это то, из чего собирается программа.

Исходный: начальный, существовавший вначале, отправной: исходное состояние, исходная точка, исходное положение, исходные постулаты.

По английски, это source code. Посмотрим, что значат эти слова:

Source(noun): any thing or place from which something comes, arises, or is obtained; origin

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

Что там внутри «компилятора» происходит, из каких «компонентов» он состоит и какие форматы передачи данных между компонентами использует - мне не интересно.

У меня на руках есть исходные коды, и никаких больше. Ничего больше я не знаю. Если у меня на машине установлены средства для компиляции программ на С++ - я соберу программу на С++ но не соберу программу на Qt. пусть даже 100 раз moc внутри себя генерит С++ный код. но не соберется. «error: undefined reference to 'vtable for Foo'». А если добавить средства для работы с Qt - смогу собрать.

Значит, Qt > С++.

Где в стандарте описаны signal: и slot: ?

А где в стандарте описаны BOOST_SCOPE_EXIT или BOOST_FOREACH? Или у нас теперь еще и Boost/C++ язык появился?

Генератор сахарка, да

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

Язык с расширенным синтаксисом — это уже новый язык, очевидно

Так ведь нет этого языка с расширенным синтаксисом. Остался все тот же C++, который обрабатывается все тем же C++ным компилятором.

Иначе у нас бы и рэкет звался бы схемой, и кресты — сишкой.

У вас — все может быть. А вот в C++, даже во времена Cfront-а, компилятор переводил код с _одного_ языка (C++) на _другой_ язык (С) и дальше обрабатывался код только на другом языке (С). Чего в случае с Qt и moc нет в принципе.

они не реализованы на С++. они именно что «нереализованы» - одним словом слитно. это сделано чтоб чисто С++ный код мог includить qt-заголовки и не видел слов, которых в стандарте c++ нет.

BOOST_SCOPE_EXIT

Это макрос. Макросы — часть языка.

Так ведь нет этого языка с расширенным синтаксисом.

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

Да, генератор, а не компилятор нового языка

Генератор синтаксического сахарка для нового языка, называемого Qt (надмножество крестов).

Ничего больше я не знаю.

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

BOOST_SCOPE_EXIT

Это макрос. Макросы — часть языка.

В коде Qt видно, что emit — это макрос. И? Что можно заключить из ваших слов?

Генератор синтаксического сахарка

Вы уверены, что понимаете термин «синтаксический сахар»?

emit — это макрос.

А slot и signal? Валидные макросы? Скомпилируются без moc?

синтаксический сахар

Конечно, а вам я рекомендую перечитать Aho того же или еще кого, и ознакомиться с понятиемя «язык» и «грамматика».

К слову BNF крестов.

http://www.nongnu.org/hcb/

Не вижу ни слотов, ни сигналов.

А slot и signal? Валидные макросы? Скомпилируются без moc?

Тему, блин, перечитайте. Ссылки уже были дадены на их точные определения.

Конечно

Тогда как вам могло прийти в голову словосочетание «генератор синтаксического сахара»? Генератор, Карл!

Ссылки уже были дадены на их точные определения.

https://github.com/qt/qtbase/blob/401d9b527823ffc8691e8a624ee3d40495622359/sr...

Это? Ну так этого кода не достаточно. Сишный препроцессор очень куц и не позволяет написать макрос, реализующий сложную кодогенерацию. Там же написано даже:

// They are used, strictly speaking, only by the moc.

Крестовый компилятор без moc код не собирает.

генератор синтаксического сахара

Генератор, транслирующий новый синтаксис в кресты. Не стоит придираться к словам.

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

расскажите это разработчикам буста, они до сих пор не в курсе и зачем-то фигачат сложную кодогенерацию именно «куцыми» макросами

сложную кодогенерацию именно «куцыми» макросами

Где там сложная кодогенерация? Что, прям синтаксис языка расширяют макросами, аки в лиспе?

Сишный препроцессор настолько куцый, что на нем даже дженерики не наваяешь, о чем вообще речь.

Крестовый компилятор без moc код не собирает.

1. Крестовый компилятор код не собирает, собирает линкер. Крестовый компилятор генерирует объектный код.

2. Крестовый компилятор вполне себе генерирует объектный код по исходным С++ным описаниям (в которых применяются slots/signals/emit) даже если moc вообще не запускался. Только этого объектного кода будет недостаточно для сборки работающей программы.

Генератор, транслирующий новый синтаксис в кресты.

И этого достаточно, для того, чтобы считать moc компилятором?

компилятором

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

Вопрос был в том, можно ли считать кресты с культи-расширениями крестами.

Поскольку можно скормить С++ компилятору определение Qt-шного класса и получить нормальный .o/.obj-файл даже без использования moc-а, то безусловно.

Сишный препроцессор настолько куцый, что на нем даже дженерики не наваяешь, о чем вообще речь.

не отсвечивай своим невежеством, а разберись в теме, потом продолжим разговор

не отсвечивай своим невежеством, а разберись в теме, потом продолжим разговор

Можно увидеть вменяемую реализацию параметрического полиморфизма на сишных макросах?

Можно увидеть вменяемую реализацию параметрического полиморфизма на сишных макросах?

можно, но ты не выполнил мои условия для продолжения дискуссии

можно

Так и запишем: Степанов не разобрался в теме, stl нужно было пилить на макросах.

Так и запишем: Степанов не разобрался в теме, stl нужно было пилить на макросах.

ты не Степанов и рядом с ним не стоишь по знаниям, не льсти себе

да какая разница что генерирует moc. это его внутренние данные, с которыми разработчик не работает. он там может хоть музыку сочинять.

музыку ветра в твоей черепной коробке?

А ведь наверняка были подобные срачи между, скажем, ASM-ерами и > C-шниками
Типо: «Чо это за хрень, где не понятно что соберется на виходе, и весь > этот крап потом тупо не влезет в память», «памяти не напасешся», >«жырноСи» ...

В моей воображаемой параллельной вселенной ASM-еры победили, и мы >все живем счастливо, пишем все на ASM-е и все у нас летает на 1М >оперативки и процы не греются ...

но нет, прогресс сцуко

Да вообще похрену, ICC есть.

Далее, часто используемые функции в Java написаны нативно, в результате чего скорость выполнения определённых операций над массивами, например, равна C++.

нативно

скорость выполнения равна C++

Ага, конечно

У меня кот с неделю назад упал с системного блока и выдернул провод из корпуса. ИБП тут не поможет.

Термоклей поможет.

Термоклей поможет.

Суровые у вас способы воспитания котов..