Pull to refresh
22
Кирилл Обликов@ocyril

User

7
Subscribers
Send message
Ой, это опечатка у меня, конечно. Больше, а не меньше.

В вашем примере у слота 0 аргументов, а у сигнала 1. Этот аргумент будет проигнорирован, тут ничего страшного.

Вот вам рабочий пример из документации:

connect(sender, SIGNAL(destroyed(QObject*)), this, SLOT(objectDestroyed()));
Вообще-то это всегда было возможно :) Смотрите документацию.

Нельзя только чтобы в слоте было меньше аргументов чем в сигнале. Поэтому иногда приходилось использовать QSignalMapper или свои велосипеды. Теперь с C++11 замыкания существенно упростят нам жизнь!
Аналогия тут неуместна :) Доки и примеры Qt намного лучше чем Handbook.
Соединение все-таки по-моему происходит в runtime. Просто на этапе компиляции теперь можно проверить, осуществимо ли оно.

Насколько я помню, в Qt изначально была идея реализовать механизм сигналов/слотов через шаблоны, как это сделано сейчас в boost. Но от нее отказались, потому что не все компиляторы в то время хорошо поддерживали шаблоны (а для кроссплатформенной библиотеки это критично), и потому что не все, что можно сделать с помощью moc, можно выразить шаблонами.

Подход Qt — более мощный, ценой немного меньшей производительности. А вообще в официальной документации Qt как всегда самое лучшее и полное объяснение: http://qt-project.org/doc/qt-4.8/templates.html

P.S. Я тоже не знаю за что вас минусуют. Вопрос как вопрос.
Документация и официальные примеры. В книгах вы ничего лучше все равно не найдете.
Даже и не знаю, что ответить :) Вообще изначально концепцию слотов в boost как раз позаимствовали из Qt.
В GAE можно использовать горутины. Все они будут исполняться в одном потоке. То есть представьте себе приведенную в статье схему, но только с одной Машиной. Горутины — это средство достижения многозадачности. Одного потока для этого вполне достаточно.
Все, конечно, так. Но память дешевле. И докупая машины, нужно как-то обеспечивать синхронизацию. N машин вряд ли покажут в N раз больше производительности, чем одна. Если, конечно, речь не идет о раздаче статики.
Так ведь память как раз несложно докупить. В самом самом худшем случае потребление вырастет в два раза :)

Нет, я, конечно, понимаю, что баг есть баг, и его надо бы пофиксить. Но ничего смертельного тут нету. Вряд ли это остановит кого-то от использования Go.
Ну а какие вообще плюсы у 32-битной платформы для вебсервера?
Просто нужно использовать 64-битную операционную систему.
Немножко соврал. На самом деле горутина создается на каждое http connection.
Я вот сейчас еще раз проверил исходники. net/http сервер на каждый http запрос создает новую горутину. Поэтому и получается не очень-то быстро для такого простого случая.

P.S. Кстати, при тестировании нужно еще и смотреть, чтобы http headers совпадали.
*выделение очень быстрой функции в горутину
Вряд ли проблема в сборщике мусора. Скорее в планировщике.

Кстати, я недавно делал статью о производительности горутин. И в качестве вывода могу сказать, что выделение очень быстрой функции (например если она работает быстрее чем 10-кратное вычисление sqrt(13)) при GOMAXPROCS > 1 действительно снижает производительность.
Я думаю, многие гики хотят ;) И чем больше у нас гаджетов, тем больше мы зависим от облака.
Я, наверное, не совсем правильно выразился. Бюджет нулевой. Проект свободный (и как слово, и как пиво). Пользователь сам арендует железо и устанавливает туда наше ПО.

Аренда простенького VPS — вполне подъемная цена. Тем более вполне можно хостить это на своем домашнем сервере, на котором вдобавок качаются торренты и прочее… Не говоря уже про то, что если не налягать на файловое хранилище, то можно бесплатно пользоваться серверами Google App Engine или Heroku, не выходя за лимиты.

Например Heroku разрешает использовать один процесс, 512мб оперативной памяти и 5Гб базы данных бесплатно. Для одного пользователя более чем достаточно.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity