Как преобразовать указатель на QObject в указатель на объект нужного класса?

[xintrea]

Далее .. красота ассемблера - а уважаемй апологет ассемблера слышал такие ругательства ARM,MIPS,Cell ? Хотя суда по интеловскому синтаксису команд LEA BX скорее всего нет

Слышал-слышал, не беспокойтесь. Хотя писал код только для KP580BM80, Z80 и Intel x86 реального режима.

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

Вы все правильно написали. Тема ассемблера была развернута только потому, что Константин не верил, что чел, работающий с  ассемблером не может осилить c/c++.

[pastor]

Тут вы меня пугаете... Как так неизвестно, сколько будет валиден возвращаемый указатель? То есть, если указатель защищен const, то известно? А если не защищен const, то неизвестно? Как то это странно все, проясните пажалусто.

Исправился. Это был ход хругой мысли (проконстантные ссылки на временные объекты) - Блог Герба Саттера. Почитайте, интересно. Кстате это вам ещё почва для размышления


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

ЗЫ: Нужно читать нормальные книги, таких авторов как, например, Герб Саттер, а не пособия для чайников. И ненужно слушать, как было сказано выше, МЕГАПРОГЕРОВ ))).

ЗЫЫ: Низачто  неповерю, что у нормального вменяемого программиста на С\С++ возникнут проблемы с использованим, а темболее с пониманием пободных конструкций.

[pastor]

Код:

const char * qPrintable()
const char* qPrintable()
const char *qPrintable()

const QString & str
const QString& str
const QString &str

при компиляции даст одинаковый результат (хотя с & надо еще проверить..).

о_О

Эммм... я забираю свои слова насчет чтения книги Герба Саттера и прочих. Страус Трупа тоже врядли осилите... Читайте что-то её проще, и чем быстрее тем лучше, т.к. с пониманием С\С++ у вас дела обстоят весьма печально, и это факт!

[bezzil]

спасиба за обширную тему подчерпнул для себя много нового.

[ритт]

поДчерпнул? ыыы))))
как дер?мо тазиком? )))))

[SASA]

Прикольный топик, однако…
По поводу асма. Был когда-то написан код для работы с растровой графикой. И написан не просто из любви к искусству, а что б работало быстрее.
Прошло 10 лет. Код  переписали на си, и он стал работать быстрее! Но правда не на много.
Так что, поддерживаю Вячеслава.

Таки резюме - если в прикладной задаче сейчас вылезает асм - IMHO  в консерватории чего-то не впорядке.

[xintrea]

Как-то выдохлись все, надо подбавить газку!

Код:

const char * qPrintable()
const char* qPrintable()
const char *qPrintable()

const QString & str
const QString& str
const QString &str

при компиляции даст одинаковый результат (хотя с & надо еще проверить..).

о_О

Эммм... я забираю свои слова насчет чтения книги Герба Саттера и прочих. Страус Трупа тоже врядли осилите... Читайте что-то её проще, и чем быстрее тем лучше, т.к. с пониманием С\С++ у вас дела обстоят весьма печально, и это факт!

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

[Вячеслав]

Как-то выдохлись все, надо подбавить газку!

Код:

const char * qPrintable()
const char* qPrintable()
const char *qPrintable()

const QString & str
const QString& str
const QString &str

при компиляции даст одинаковый результат (хотя с & надо еще проверить..).

о_О

Эммм... я забираю свои слова насчет чтения книги Герба Саттера и прочих. Страус Трупа тоже врядли осилите... Читайте что-то её проще, и чем быстрее тем лучше, т.к. с пониманием С\С++ у вас дела обстоят весьма печально, и это факт!

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

Хм.... а собственно чем отличаються те два набора строк ? IMHO - ни чем

const char* qPrintable()
char* qPrintable() const
разница есть   А выше сказанное  одно и тож

PS а когда начинается развлекуха с параметром функции типа указатель на Функу , у которой параметром свои указатели на другие функи(функи другого типа) и все это без typedef'ов ...... по неволе virtual'jd полюбишь

[Tonal]

Да, весёлое чтово.

С точки зрения "передачи смысла" сейчас рулят Haskell, Python, Ruby, JS... а так же всякие DSL-и - ведь именно они используются для быстрого прототипирования.
PHP, 1C, AS - это где-то посередине. Это уже не DSL, но до полноценного современного языка им ещё ...

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

2 xintrea Кстати, вот, похоже именно твоя проблема описана:

Большинство людей, думающих, что они знают Си, на самом деле не понимают работы памяти или указателей. Это до них просто не доходит. Удивительно, как эти люди работают программистами, но ведь работают же!
...
Многие программисты на Си просто не знают, как заставить работать указатели. Я, как правило, не отказываюсь от кандидата из-за отсутствия у него какого-то навыка. Однако я обнаружил, что понимание указателей в Си — это не навык, а способность. В начале первого курса на факультете кибернетики набирается человек 200 вундеркиндов, писавших в четырехлетнем возрасте игрушки для Atari 800 на BASIC'е. Они хорошо проводят время, изучая Паскаль, но в один прекрасный день профессор заводит речь об указателях, и они внезапно перестают понимать. То есть абсолютно. 90% потока переходит на отделение политологии, обьясняя это тем, что на кибернетике мало симпатичных студенток. На самом же деле, по неизвестной причине часть человечества просто рождается без того отдела мозга, который понимает указатели. Указатели — это не навык, а способность, требующая особого мышления, и некоторые люди им просто не обладают.

Отсюда: http://russian.joelonsoftware.com/Articles/Interviewing.html

Так же полезно будет почитать:
http://russian.joelonsoftware.com/Articles/BacktoBasics.html
http://russian.joelonsoftware.com/Articles/AdviceforComputerScienceC.html
Да и вообще всё отсюда: http://russian.joelonsoftware.com/index.html

[SASA]

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

IMHO Бред.
Читаю С++ студентам. Что такое указатель не понимает только тот, кого я первый раз вижу на зачёте. Но это у них не от отсутствия способности.

[xintrea]

С точки зрения "передачи смысла" сейчас рулят Haskell, Python, Ruby, JS... а так же всякие DSL-и - ведь именно они используются для быстрого прототипирования.
PHP, 1C, AS - это где-то посередине.

Ну я подумывал пользовать для разработки Python (с Qt биндингами), но что-то пока те программы, которые сделаны с использованием питона, мягко говоря работают кривовато. Часто вообще не работают. Дело видимо не в самом питоне как языке, а в библиотеках и версиях питона. В этом смысле в питоне сейчас имеем разброд и шатание. С Qt и C/C++ я хотябы уверен, что под виндой скомпиленый бинарь и нужные версии DLL, положенные рядом, обеспечат запуск и работу программы (хотя читал что нужно еще какое-то обновление системных dll, но для него есть готовый инсталлятор, и объяснить пользователю или сделать инсталлятор с обязательной установкой обновления не проблема). В линухе посложнее, но считается, что при установленной версии Qt не ниже требуемой, все должно работать.

А вот с питоном все очень плохо. Казалось бы - интерпретируемый язык, делай разработку, включай в релиз все нужные сторонние скрипты чтоб все гарантированно работало. Лицензия позволяет. Так нет же, ставишь прогу - она требует еще что-то, причем о требованиях узнаешь только тогда когда питоновский скрипт вывалится с ошибкой. Доставишь нужное - вроде начинает работать, но вываливается в другом месте. Начинаешь разбираться - там какая-то залипуха с версией питона, скрипту надо 2.5, а в системе другая. Обновишь версию - старые проги перестают работать.

Что далеко ходить - вон в последнем Inkscape 0.46 половина фильтров, сделанных на питоне, не работает. Я не настолько хорошо знаком с питоном, чтоб однозначно сказать - "при правильной подготовке релиза, Python программа будет везде работать так же, как и у разработчика". Пока то, что я наблюдаю - это то, что по каким-то непонятным причинам сделать нормальные, однозначно работающие проги, с использованием питона, не могут. Да, рассказы о том, что это мои кривые руки, не канают . Программы должны делаться так, чтоб после установки они работали и все.

Так что ежели хочется именно "передачи смысла" то зачем использовать С++ - это один из самых сложных из майнстримовских языков, и предназначен он в первую очередь для создания высокоэффективных приложений?

По причинам, описанным выше. А вообще, в любом языке надо стремиться так писать программы, чтоб смысл действий был виден явно. Оптимизирующие компиляторы нынче хорошо обработают как "замудреный компактный" код, так и например код, с разложением для ясности в переменные промежуточных вычислений.

> 2 xintrea Кстати, вот, похоже именно твоя проблема описана:

Большинство людей, думающих, что они знают Си, на самом деле не понимают работы памяти или указателей. Это до них просто не доходит. Удивительно, как эти люди работают программистами, но ведь работают же! ... Многие программисты на Си просто не знают, как заставить работать указатели.

Да, есть такое дело. Скажу больше, многие программисты, которые все-таки умеют работать с указателями на C/C++ (и думают, что они умеют работать с указателями), часто слабо понимают что на самом деле происходит в памяти, и как это выглядит.

Однако я обнаружил, что понимание указателей в Си — это не навык, а способность. ... На самом же деле, по неизвестной причине часть человечества просто рождается без того отдела мозга, который понимает указатели. Указатели — это не навык, а способность, требующая особого мышления, и некоторые люди им просто не обладают.

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

Например, нам объясняют, что переменная указателя - это адрес, который указывает на начало нужных данных. Значит, указатель на число int, и указатель на начало строки - это просто адреса. В 32x битных системах - это просто 4 байта смещения в сегменте данных. Коль указатель на int и указатель на начало строки имеют одно понятие "указатель", и имеют одинаковую структуру (4 байта в которых лежит адрес), значит указатели можно свободно присваивать. То есть по сути, можно легко положить в указатель на int адрес, который лежит в указателе на начало строки. Но тут же в книге мы видим, что нельзя присваивать указатели одного типа указателю другого типа. А почему нельзя то? А потому, пишут в книге, что указатели указывают на данные с разной структурой, и использование такой конструкции приведет к непредсказуемым последствиям. Пишут правильно.

Но не пишут почему нельзя-то такое провернуть? И на каком этапе будет ошибка? Люди начинают гадать - наверное, указатель - это какая-то структура, в которой помимо 4 байтов адреса еще и храниться инфа о типе объекта, на который указатель указывает. Иначе, простое присвоение одного указателя другому, было бы возможным. А профи знают, что это предположение неверное. Что указатель в C/C++ на 32 битной архитектуре - это действительно 4 байта с адресом, и ничего больше. А ошибка будет возникать просто на этапе компиляции, именно компилятор не даст присвоить указатель на один тип указателю на другой тип. А чтобы всетаки это сделать, надо пользоваться механизмами приведения типов, о чем в главах про указатели почему-то не пишут.

Хотя, одну книгу я видел, в которой вроде как было нормальное объяснение с точки зрения низкоуровеневого подхода ("низкоуровневый" я имею в виду низкосистемный уровень объяснения, а не объяснение "для тупых"). Книжка была страниц эдак на 1000 если не больше, на книжке фотография двух дяденек (авторов), а вот как называлась - не помню. Возможно, "Библия C/C++" или что-то в этом роде. Там вроде как было написано просто и понятно. Но стоила книга около 2300 руб, я такие деньги за книгу с серой газетной бумагой отдать не готов, какая бы полезная информация в ней не была написана. Кто-нить может по описанию сказать, что это за книга? Я б ее в электронном варианте посмотрел (хотя, конечно, читение с монитора не идет ни в какое сравнение с чтением с бумаги).

[Tonal]

Используем Python в разработке уже более 5ти лет, в том числе и биндинг к Qt (всю гуйню на нём сейчас пишем).
Особой кривизны не наблюдали.
Выбрали связку Python + Qt именно из за высокой скорости разработки.
Лёгкость поддержки и сопровождения продуктов не отличается от C++ + Qt или Delphi.
С версиями разбираемся просто - py2exe - и у тебя набор из exe и dll-ек нужных для работы твоей проги.
В винде нельзя полагаться на то, что и куда у пользователя установлено в системе...

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

А так, проблемы переносммости есть для любой системы/среды.
Про великолепную Java, у которой был слоган: "сделано однажды, работает везде" по этому поводу слоган чуть изменили: "сделоно однажды, отлаживаем везде!".