LINUX.ORG.RU

[C++][Qt] Вопрос по макросам и умным указателям

 ,


0

1

Осиливаю потихоньку указанный язык с помощью гугла и форумов.
Вот что посоветуете почитать из не-талмудов (времени увы мало), чтобы не было таких вопросов:
1) Когда можно использовать макросы, а когда не стоит - например, меня всё время тянет на вещи вроде

#define ref &
void printDmth(const QString ref str);
чтобы получить C#, но компилируемый. Но ведь макросы в С++ есть deprecated вещь, и вообще так менять язык не стоит во имя других программистов?
2) Какой вид умного указателя выбрать для хранения глобального объекта «тяжелого» класса сложной структуры, с опять же большими массивами внутри, у которых свои подмассивы и т.д. Может, QScopedPtr? я так понял, он самый быстрый из «умных», а это с учетом размера массивов в классе важно. И раз уж Qt используется, то буст тянуть не хочется - разве что местные *_ptr-ы существенно лучше кутишных.

P.S. Если вопросы тупые, прошу прощения. Всё-таки совсем в одиночку трудно учить такой язык. И да, про D в курсе, но он мёртв.

и вообще так менять язык не стоит во имя других программистов?

Да, не стоит. When in Rome, do as Romans do. Так будет дальше проще

vertexua ★★★★★
()

> Осиливаю потихоньку указанный язык с помощью гугла и форумов.

O_o

Язык нужно учить по тексту стандарта, а не гуглом и форумами

Harald ★★★★★
()
Ответ на: комментарий от vertexua

Вот и я так подумал, но решил спросить. На всякий случай :) А вообще очень жаль, что D загнулся. Мне нравилась его улучшить древние плюсы, не скатившись в ынтерпрайз C#/Java.

anarelian
() автор топика

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

с учетом размера массивов в классе

Какое отношение размер объекта имеет к размеру указателя и скорости его (указателя) копирования?

schizoid ★★★
()

> Осиливаю потихоньку указанный язык с помощью гугла и форумов.

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

LamerOk ★★★★★
()
Ответ на: комментарий от const86

На лоре новостей нет ==> не развивается оно уже. Как-то так.

anarelian
() автор топика
Ответ на: комментарий от schizoid

Я имел в виду накладные расходы при каждом обращении к умному указателю. Разве они не зависят от самого объекта, который мы помещаем в этот самый указатель?

anarelian
() автор топика
Ответ на: комментарий от Harald

А в ЯП-срачах постоянно упоминается, что стандарт С++ опупеть как сложен и длинен, и приводятся в пример более другие языки, ЕМНИП.

anarelian
() автор топика
Ответ на: комментарий от LamerOk

Сарказм оценил, да. Но я же сказал - времени для этого маловато. По крайней мере для серьезных вещей вроде Страуструпа и Александреску. И если посоветуете что-то объемом меньше тыщи страниц, буду только благодарен.

anarelian
() автор топика
Ответ на: комментарий от anarelian

> А в ЯП-срачах постоянно упоминается, что стандарт С++ опупеть как сложен и длинен, и приводятся в пример более другие языки, ЕМНИП.

Более другие языки, ок.

anonymous
()

чтобы получить C#, но компилируемый. Но ведь макросы в С++ есть deprecated вещь, и вообще так менять язык не стоит во имя других программистов?

вам засрали мозг надо использовать что удобно а не что не deprecated макросы применяются там где они нужны а все остальное кто что думает поэтому поводу неважно есть конечно извращения среди макросов например boost/preprocessor но в остальном например linux/list.h макросы применены к месту и без них если ты не ССЗБ будет не так удобно придется все записывать руками

anonymous
()
Ответ на: комментарий от anarelian

Вести одну переменную и изменять её при создании/удалении smart_ptr не так уж и накладно (если, конечно, не копировать этот smart_ptr пицот раз в секунду).

Всё обращение к самому объекту есть возврат указателя на него (который и хранится в почти единственном поле smart_ptr). При объявлении этого оператора/метода inline (явно или неявно), разницы в исходном коде не будет вообще.

schizoid ★★★
()
Ответ на: комментарий от anonymous

Да тут дело даже в другом - фактически, с помощью макросов создаю собственный язык. В котором другие-то люди не разберутся. Пока я макросы только для отладки использую, где они действительно помогают. Но думаю - а где они смогут сильно урезать код? linux/list.h гляну тогда, спасибо.

anarelian
() автор топика
Ответ на: комментарий от schizoid

Моя задача проста - обернуть все указатели так, чтобы доступ к ним быстр, а удалялись они автоматически по закрытию программы (или при выходе из области видимости). Получается, QScopedPtr будет достаточно, или QSharedPtr лучше? просто мне желательно именно Qt-шные «смарты» использовать, чтобы зоопарк не разводить. Вряд ли уж они там такие кривые, как некоторые пишут.

anarelian
() автор топика

1) Так - нахрен не нужно

2) Умный указатель хранить указатель, как это не странно, и пусть он указывает хоть на чёрта лысого - умные указатели надо выбирать по другому принципу.

yoghurt ★★★★★
()
Ответ на: комментарий от anarelian

Если тебе нужно примитивное RAII, чтобы писать эксепшон-сейф код, юзай QScopedPtr. Если объект нужно гонять за пределами области его создания - QSharedPtr.

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

RAII

Оно самое! Ну, недо-GC чтобы получился, чётко отрабатывающий по завершению программы, плюс избавление от ужасов ручных new/delete. Кстати, вопрос по ходу дела по указателям:

struct Foo {
QString bla;
...
};
vs
QString * bla;
...
- не сливает ли первый вариант в производительности? вроде читал, что QString оптимизирован по самые яйца же.

Если объект нужно гонять за пределами области его создания - QSharedPtr.

То есть, если создали объект в одной функции, а юзаем совсем в другой, то нужен QSharedPtr. Иначе, если объект «где родился, там и пригодился» - то QScopedPtr. Так?

anarelian
() автор топика
Ответ на: комментарий от s0L

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

Harald ★★★★★
()
Ответ на: комментарий от anarelian

>не сливает ли первый вариант в производительности?

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

yoghurt ★★★★★
()
Ответ на: комментарий от anarelian

QString и так использует copy-on-write механизм, нет большой разницы, указатель хранить или объект.

Если тебе нужен указатель, который освобождается при выходе из блока, где объявлен - scoped.

Если тебе нужен указатель, который освобождается, когда его никто не использует - shared.

schizoid ★★★
()

Чувак, если ты пытаешься из C++ сделать C#, то тебе и надо брать C#.

C#, кстати, компилируемый(Серьезно. «Виртуальная машина» .NET это абстракция, потому что весь код перед исполнением компилируется в машкоды. Можно даже заранее его компилировать, используя ngen).

А учитывая, что тебя интересуют вопросы типа «какой вид умного указателя выбрать для хранения глобального объекта „тяжелого“ класса сложной структуры, с опять же большими массивами внутри, у которых свои подмассивы и т.д.» то это значит, что C++ - совершенно не тот язык, который тебе нужен. Ты, возможно, его выбрал потому что якобы «на нем можно писать быстрые программы». Да, можно, но только если не выходить за уровень «пару раз пройти через массив, выполняя арифметику на флоатах, желательно с sse-вставками». А вот если у тебя в программе «классы сложной структуры», настолько сложной, что ручками ты за ними следить уже не можешь, и поэтому используешь умные указатели, то из «производительного» C++ получается вот что: http://love5an.livejournal.com/365174.html

lovesan

anonymous
()
Ответ на: комментарий от anonymous

Серьезно. «Виртуальная машина» .NET это абстракция, потому что весь код перед исполнением компилируется в машкоды.

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

m0rph ★★★★★
()
Ответ на: комментарий от schizoid

> Если тебе нужен указатель, который освобождается при выходе из блока, где объявлен - scoped.

В C++11 логика несколько иная: если объект нужен в одном месте - unique_ptr, если сразу в разных - shared_ptr. Первый можно свободно перекладывать туда-сюда, передавать в функции и возвращать. Такая логика существенно расширяет сферу применения unique_ptr, который не приводит абсолютно ни к каким накладным расходам, в отличие от shared_ptr.

const86 ★★★★★
()
Ответ на: комментарий от m0rph

>Так у любой «виртуальной машины» байткод перед выполнением процессором все равно будет преобразован в понятные процессору машинные коды. Не у любой. Жабовый HotSpot например в основном интерпретирует, а JIT'ит только то, что считает нужным.

Вопрос в том, что это преобразование занимает время.

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

Возможен вариант с AOT - тогда весь байткод компилируется _заранее_, типа как «обычными» компиляторами(делается это утилитой ngen, включенной во фреймворк).

anonymous
()
Ответ на: комментарий от schizoid

copy-on-write

А, то есть бесполезных копирований всё равно не будет. Спасибо! Так понял, к QVector3D и т.п. подобным классам это тоже ведь относится?
Про указатели - тоже спасибо, коротко и ясно написали. Выходит, мне нужны и scoped, и shared-ы.

anarelian
() автор топика
Ответ на: комментарий от anonymous

Тут такой вопрос - а на каком уровне надо знать шарп или Common Lisp, чтобы писать на них без тормозов, не наталкиваясь на слабые стороны GC? Я-то шарп знаю плохо, а уж хитрости .net и тем более. Лисп вообще на уровне hello world, не преподавали его в моём мухосранске, благо я математик больше чем кодер.
А на плюсах интерпретатор Паскаля хотя бы писал (тормозной кстати из-за std::vector - теперь сам понимаю, что там ему не место).

Ты, возможно, его выбрал потому что якобы «на нем можно писать быстрые программы».

Честно говоря - да. К тому же, для GUI и вообще кроссплатформенной разработки ничего адекватнее Qt не нашел, а оно плюсики использует. Хотя видел и биндинг к C#.
Ну и в итоге - на чем тогда ж писать?
P.S. Блог интересный. Вот только темы про LISP почему-то редки в Development, а на С++ вовсю пишут.

anarelian
() автор топика
Ответ на: комментарий от anonymous

Вопрос скорее в том, что GC тоже надо уметь использовать - как любой инструмент. Я ведь правильно понимаю, что опыт в С++ в шарпе не применим, и надо досконально выучить особенности и самого языка, и CLR? это чтобы писать нетормозной код.

anarelian
() автор топика
Ответ на: комментарий от Harald

C++ надо учить чтением Саттера и Александреску, а также других авторов. Стандарт в данном полезен только тогда когда уже знаешь язык и хочешь уточнить некоторые детали.

Reset ★★★★★
()
Ответ на: комментарий от anarelian

>Так понял, к QVector3D и т.п. подобным классам это тоже ведь относится?

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

Насколько я помню, вообще все контейнеры в Qt подобным образом построены.

schizoid ★★★
()
Ответ на: комментарий от Reset

А можете конкретные книги указать, только базового/среднего? становиться виртуозом шаблонов я пока не собираюсь - нужно только научиться писать грамотный, поддерживаемый и производительный код.

anarelian
() автор топика
Ответ на: комментарий от schizoid

Ага, нашел, спасибо. Буду впредь знать, что искать-то в горах документации :)

anarelian
() автор топика
Ответ на: комментарий от Vernat

> компилятор переезжает в gcc, так что рано хороните

gdc давно уже есть, или они от своего отказываются в его пользу?

aho
()
Ответ на: комментарий от Vernat

Встряну - я бы только рад был, если бы D динамично развивался, стабилизировался(D2 != D2.х.х достало уже), и оброс библиотеками.
Вы кстати смотрю в курсе событий - не подскажете, где читать свежие новости о D? и особенно интересно, есть ли для него живые Open Source проекты.

anarelian
() автор топика
Ответ на: комментарий от anarelian

> времени для этого маловато. По крайней мере для серьезных вещей вроде Страуструпа и Александреску. И если посоветуете что-то объемом меньше тыщи страниц, буду только благодарен.

http://4.bp.blogspot.com/_e7LB8W_AJh4/S-QBt7K6t8I/AAAAAAAAAFo/F4mXh75R_b4/s16...

LamerOk ★★★★★
()
Ответ на: комментарий от anarelian

> С++11 использовать не буду пока gcc не допилен для него.

Для очень большой части стандарта уже допилен, в том числе смартпоинтеры есть. А ждать полной поддержки бессмысленно, C++98 и то не полностью поддерживается :)

const86 ★★★★★
()
Ответ на: комментарий от aho

проиприетарный переедет, Уолбрайт отказывается от прав на него.

Vernat ★★
()
Ответ на: комментарий от const86

Ну, всё равно как-то Qt надежнее выглядит. Но возможность буду в виду иметь. Не зря же столько ждали этот стандарт - как там, «джва года» :)

anarelian
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.