Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: размышления о Qt, STL и pragma
Форум на CrossPlatform.RU > Курилка > Трёп
Алексей1153
[offtop]
Раскрывающийся текст
У меня вот парочка глюпых вопросов возникла
Кстати,

1) а зачем вставлять Q_OBJECT, если нет своих слотов и сигналов ? Или это "дёшево" ?

2) зачем используется неуклюжая конструкция
#ifndef BUTTON_H
#define BUTTON_H
#endif
, если есть #pragma once
?

3) чем использование QMap лучше std::map ? (привычно для меня как то последнее)
[/offtop]

отделено от темы: Создание неограниченного количества элементов
DEADHUNT
если для тебя привычнее std::map (то есть pure C++), то почему лучше использовать не стандартную директиву препроцессора #pragma once ?
Алексей1153
Цитата(DEADHUNT @ 19.7.2010, 20:24) *
то почему лучше использовать не стандартную директиву препроцессора #pragma once

ну, во первых, прагма удобнее, а во вторых - насчёт стандартности не знаю, но вот, к примеру, студийный компилятор (имеется в виду также и VS6) эта прагма уже использовалась, думаю, за 12 то лет люди должны были оценить удобство :)
Litkevich Yuriy
Цитата(Алексей1153 @ 19.7.2010, 21:13) *
1) а зачем вставлять Q_OBJECT, если нет своих слотов и сигналов ? Или это "дёшево" ?
Это общая рекомендация тролей. когда слоты понадобятся, не нужно будет вызывать qmake вручную. Что значит "дёшево"?

Цитата(Алексей1153 @ 19.7.2010, 21:13) *
2) зачем используется неуклюжая конструкция
#ifndef BUTTON_H
#define BUTTON_H
#endif
, если есть #pragma once
все компиляторы поддерживают #pragma once? и что это такое? Как работает стандартная защита от множественного включения знают большинство.

Цитата(Алексей1153 @ 19.7.2010, 21:13) *
чем использование QMap лучше std::map ? (привычно для меня как то последнее)
в комплекте с QMap Qt предоставляет два типа итераторов, STL-подобные и Java-подобные
DEADHUNT
Цитата(Litkevich Yuriy @ 19.7.2010, 20:56) *
Что значит "дёшево"?

значит то что не будет дополнительных затрат памяти и ещё чего-то(например не будут выполняться какие-то дополнительные функции).

Цитата(Litkevich Yuriy @ 19.7.2010, 20:56) *
в комплекте с QMap Qt предоставляет два типа итераторов, STL-подобные и Java-подобные

и это аргумент? Qt не входит в STL и смысл его использовать если он делает то же самое что и std::map, получается что QMap бесполезное дублирование std::map(наверное что бы осложнить переход с Qt).
Litkevich Yuriy
Цитата(DEADHUNT @ 20.7.2010, 0:05) *
и это аргумент?
да
igor_bogomolov
1.
Цитата(Litkevich Yuriy @ 19.7.2010, 21:14) *
Это общая рекомендация тролей. когда слоты понадобятся, не нужно будет вызывать qmake вручную. Что значит "дёшево"?
Добавлю только, что Q_OBJECT нужен не только для сигнал-слотового взаимодействия, а везде где может потребоваться метообъектная информация (qobject_cast, tr, property system и т.д.)

2.
Раз #pragma - значит зависит от компилятора, что не есть хорошо. К тому же конструкцию
#ifndef BUTTON_H
#define BUTTON_H
#endif
понимают все, это уже некий стандарт.

3.
Цитата(DEADHUNT @ 19.7.2010, 21:05) *
и это аргумент? Qt не входит в STL и смысл его использовать если он делает то же самое что и std::map, получается что QMap бесполезное дублирование std::map(наверное что бы осложнить переход с Qt).
Как то вы слишком категоричны. У всего есть свои преимущества и недостатки. Важно их правильно использовать.
Для меня главное преимущество QTL, как и всего Qt - это удобство использования. Qt предоставляет удобные интерфейсы, которые значительно сокращают время разработки, снижая требования к исполнителю.
К тому же, при написании программы, хочется обеспечить некое единство стиля. Поэтому мне не нравится смешивание в одном коде контейнеров Qt и stl. Поэтому если программа пишется с использованием Qt, я стараюсь использовать QTL.

В качестве дополнения видержка из assistent'a
Цитата
Контейнерные классы - классы с неявным совместным использованием данных, они реентерабельны, и они оптимизированы для быстрой работы, низкого потребления памяти и минимального увеличения кода (inline), результат в меньшем исполняемом файле. Кроме того, они потоко-безопасны в ситуациях, где они используются, как контейнеры только для чтения, всеми потоками используемыми для доступа к ним.

Для обхода элементов, хранящихся в контейнере, вы можете использовать один из двух типов итераторов: итераторы в стиле Java и итераторы в стиле STL. Итераторы в стиле Java легче использовать и они предоставляют высокоуровневую функциональность, тогда как итераторы в стиле STL немного более эффективны и могут быть использованы вместе с базовыми алгоритмами Qt и STL.

Qt также предоставляет конструкцию foreach, которая позволяет очень легко перебрать все элементы, хранящиеся в контейнере
haiflive
Ну собствено поясню, программирую на PHP и сейчас пишу программу на C++ и использую фреймворк QT, так что мне удобнее использовать QT_STL, так как они описаны в книге(QT4.5), и хоть как-то походят на PHP, к то му же процетированный выше открывок из книги, убедил меня (ранее) изучать STL от QT..
Сказал же, что я новичёк, C++ не так давно изучил..

А сколько книг вы прочли по QT?.
И посоветуйте пожалуйста мне "современную" книгу по С++ где описаны "#pragma once" и тп

Цитата
Сказал же, что я новичёк, C++ не так давно изучил..

..тоесть начал изучать


Где тут вообще кнопка редактирования собственного поста?
Litkevich Yuriy
Цитата(haiflive @ 20.7.2010, 8:15) *
Где тут вообще кнопка редактирования собственного поста?
появится, когда 20 сообщений наберёшь
Алексей1153
Сделал для себя выводы:
То есть понятно: stl можно дальше продолжать использовать, Q_OBJECT лучше всегда ставить, а прагму - проверить, поддерживает ли компилятор :)
Litkevich Yuriy
Цитата(Алексей1153 @ 20.7.2010, 16:53) *
То есть понятно: stl можно дальше продолжать использовать, Q_OBJECT лучше всегда ставить, а прагму - проверить, поддерживает ли компилятор
всё верно
igor_bogomolov
Цитата(Алексей1153 @ 20.7.2010, 13:53) *
а прагму - проверить, поддерживает ли компилятор
ИМХО. Уж тогда лучше делать так как написано в Wikipedia
Цитата
Можно использовать обе команды, #pragma once и include guards, для написания переносимого кода, что также может принести выгоду от применения #pragma once при оптимизации (если компилятор её поддерживает):
File «grandfather.h»
#pragma once
#ifndef GRANDFATHER_H
#define GRANDFATHER_H

struct foo
{
    int member;
};

#endif /* GRANDFATHER_H */
Алексей1153
igor_bogomolov, мой код вряд ли будет на множестве компиляторов обрабатываться, поэтому мне достаточно просто прагмы. Ну а если повстречается необходимость - то поиск по всему коду спасёт. Но это вряд ли понадобится :)

Проверил сейчас - в креаторе #pragma once прекрасно работает. В студии же всегда работала тоже
Iron Bug
c STL есть две основных заморочки: с многопоточностью он частенько не дружит и память неоптимально жрёт. бывает, что программа начинает "расти" в памяти, хотя нигде ничего не выделяется вроде. это проделки STL-евских векторов и прочих подобных хранилищ. так что аккуратнее с ними надо.
Алексей1153
Iron Bug, многопоточности в STL нет неспроста - это дань скорости работы библиотеки. Если нужна синхронизация - это вручную (или оболочку соорудить)

Насчёт дефрагментации памяти - тут не в STL дело, того же самого можно добиться и вызовами new/delete. Тут уже зависит от подхода к проектированию - если предполагается частая реаллокация, то можно использовать свой пул (или можно аллокатор переопределить) объектов, а в контейнере держать указатели
Алексей1153
Только заметил - название темы. По-моему, не бывает "философия о <чём-либо>", философия - она "философия чего-либо" :)
Litkevich Yuriy
Цитата(Алексей1153 @ 13.8.2010, 1:20) *
По-моему, не бывает "философия о <чём-либо>"
у меня слово "философия" ассоциируется со словом "размышления" :)
Алексей1153
Ну, так то оно так, даже переводится как "люблю мудрствовать", но по-русски не звучит текущее название темы )) А, поскольку, тема создана как бы от моего лица (а я так назвать не мог), вот и возмущаюсь немного :D

Можно оставить просто "Qt, STL и pragma" или "салат из Qt, STL и pragma"
Litkevich Yuriy
а если совсем по народному: размышления о Qt, STL и pragma
подойдёт?
Алексей1153
пойдёт )
igor_bogomolov
Может перенести в "Техника программирования"?
Litkevich Yuriy
Цитата(igor_bogomolov @ 13.8.2010, 4:12) *
Может перенести в "Техника программирования"?
да, пусть здесь будет
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.