Нужно:

— Постоянные адреса уже существующих элементов контейнера (чтобы оно не менялось при изменении контейнера).
— Быстрый доступ в (не знаю каком, см. ниже про OpenMP) порядке.
— Хорошая скорость копирования.

Абсолютно пофиг на скорость добавления и удаления элементов.
Размер заранее известен (не во время компиляции, а непосредственно перед созданием).

Что тут лучше использовать и почему?

Конечная цель — создать контейнер, заполнить его 10000 объектами. Далее в цикле (I) миллион раз запустить цикл (II), в котором запускается член-функция (рассчёты) для каждого из объектов. Причём цикл II запускать многопоточно (с использованием OpenMP). Каждые 1000 шагов цикла I делать в памяти копию контейнера.

Такие дела. Что выбрать? Совсем не обязательно STL-ное.
А что выбрать, если то же самое, но требуется динамическое добавление-удаление элементов (пофиг, с какой скоростью... причём добавлять элементы надо только в конец)

Нужно создать класс, который действовал бы аналогично QRubberBand. То есть чтобы его можно было создавать во вьюпорте View и изменять его параметры (размер, позицию), не заботясь о его перерисовке (чтобы он при этом сам перерисовывался).

Можете привести пример для, например, эллписа (и чтоб описывался он, по традиции Qt, как QRect). Использовать хочется по некоторой аналогии с QRubberBand:

В хедере View делаю:

QPoint m_origin;
AbstractRubberBand* m_rubberband;

И используется в этом View оно так:

void Widget::mousePressEvent(QMouseEvent *event)
 {
     m_origin = event->pos();
     if (m_rubberband == NULL) {
         m_rubberband = new (m_instrument == Ellipse ? EllipseRubberBand(this) : RectangleRubberBand(this) );
     }
     m_rubberband->setGeometry(QRect(origin, QSize()));
     m_rubberband->show();
 }

 void Widget::mouseMoveEvent(QMouseEvent *event)
 {
    if (m_rubberban != NULL) {
       m_rubberband->setGeometry(QRect(origin, event->pos()).normalized());
    }
 }

 void Widget::mouseReleaseEvent(QMouseEvent *event)
 {
    if (m_rubberban != NULL) {
     m_rubberband->hide();
     // делаем что надо с полученной фигурой и удаляем m_rubberband
    }
 }

Также нужен инструмент полигональной линии — в него последовательно (сигналами или ещё как) отправляются QPointF'ы или сигналы изменения позиции одного из его точек, потом опять же прячем его, получаем shape и удаляем его.

От чего танцевать, что наследовать?

Прошу сменить мне ник на не матерный Obey-Kun.

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

звёздочки — всё, что у меня есть... хнык.

У меня унаследованы от Qt'шных свои View и Scene.

На данный момент делаю различные инструменты: прямоугольное выделение, эллипсоидное выделение, полигональное выделение (всё в стиле GIMP). Также существует анкер-привязка (как в Автокаде, если упрощённо: квадратик, который «прилипает» к ближайшей точке сетки).

Сейчас я их кладу в сцену, т.к. таким образом легко получается их перерисовывать. Например, бывает нужно переместить анкер и тогда я посылаю сигнал anchorPositionChanged(QPoint). Или юзер хочет изменить размер прямоугольного выделения, тогда он берёт и тащит за угол, что приводит к посыланию соответствующих сигналов.

Куда идеологически правильно помещать анкер и эти инструменты? Таки в сцену?

Стоит ли наследовать прямоугольное и эллипсоидное выделение от QRubberBand, или от чего тогда?

class MyConstants
{
public :
    static const long constant1 = 1;      //всё ок 
    static const double constant2 = 2.2;  //ругается при g++ -pedantic
};

Ругается так: «ISO C++ запрещает инициализацию элемента-константы ‘constant2’ нецелочисленного типа ‘const double’».

Смотрим в стандарт:

ANSI C++ 98, 9.2 «Class Members» item 4

A member-declarator can contain a constant-initializer only if it declares a static member (9.4) of const integral or const enumeration type, see 9.4.2.

ANSI C++ 98, 9.4.2 «Static Data Members» item 2

If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant-initializer which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions. The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an initializer.

Объясните, пожалуйста, к чему в стандарте такое странное ограничение?

Избавляюсь от вэрнингов вроде «... should be initialized in the member initialization list».

Два вопроса:

1. А действительно ли стоит это делать? Например, есть такой код:

Class SomeClass
{
  double m_a;
  double m_b;
  double m_c;
public:
  SomeClass(a, b):
    m_a(a),
    m_b(b) {  }  // конструктор для "повседневного" применения

  SomeClass() {  } // это для того, чтобы можно было делать vector элементов этого типа

  void calculateC()
  {
    m_c = /* адская формула с участием a и b */;
  }

  double getC () const { return m_c; }
  void setA (double a) { m_a = a; calculateC(); }
  void setB (double b) { m_b = b; calculateC(); }
}

Насколько оправдано здесь инициализировать m_c в SomeClass(a, b) и все переменные в SomeClass()?

2. Каким образом инициализировать «ненужные» в конструкторе члены? Касательно этого примера, как следует делать:

  SomeClass(a, b):
    m_a(a),
    m_b(b),
    m_c() {  }

или

  SomeClass(a, b):
    m_a(a),
    m_b(b),
    m_c(0) {  }

Есть матрица 2*N, типа того:

1.0 2.2
1.2 2.5
0.2 3.4
2.1 1.5
2.0 1.7
0.6 2.1

Представлена она как vector<Point> (ну не суть).

Надо нанести точки на плоскости и построить по ним кривую.

Я так понимаю, MathGL для такого непригоден... хотя хотелось бы, т.к. привычная библиотека. Верно понимаю?

Чем можно сделать это в минимальное кол-во строчек кода?

совсем недавно видел тут ссылку на ютюбовский ролик

русский

чувак идёт и напевает (без слов)

улыбается

такие дела

дайте ссылку

роллик был в теме про мультик или что-то такое

ещё была калитка и забор, вот

I. Требуются инструмент, рисующий прямоугольники. Также требуются выделяющие инструменты (овал, прямоугольник). Принцип действия одинаков — юзер тыкает кнопкой мыши по View, растягивает нечто, видит как оно изменяется, отпускает кнопку и мы получаем в своё распоряжение заданный QRectF (как я понимаю, с овалами также лучше работать через QRectF).

То есть работать с этим делом предполагается как-то так (по аналогии с QRubberBand):

    void Widget::mousePressEvent(QMouseEvent *event)
    {
        origin = event->pos();
        if (!myInstrument)
            myInstrument = new MyInstrument(MyInstrument::НУЖНАЯ_ФОРМА, this);
        myInstrument->setGeometry(QRect(origin, QSize()));
        myInstrument->show();
    }

    void Widget::mouseMoveEvent(QMouseEvent *event)
    {
        myInstrument->setGeometry(QRect(origin, event->pos()).normalized());
    }

    void Widget::mouseReleaseEvent(QMouseEvent *event)
    {
        myInstrument->hide();
        // делаем, что надо и удаляем myInstrument
    }

Если я верно понимаю, в Qt из подобного есть только прямоугольное выделение — QRubberBand. Но оно умеет рисовать только прямоугольники и отрезки. То есть надо бы унаследовать и добавить нужные формы, но сколько я ни медитировал на код этого виджета, я так и не понял, где там вообще рисуется прямоугольник. Что нужно сделать, чтобы оно рисовало овалы (и вообще возможно ли это)?

II. Ещё требуется выделение-лассо (точнее, полигональное выделение) — юзер расставляет точки, соединяет начальную точку с конечной и мы получаем в своё распоряжение полигон (как в гимпе, только без возможности рисования кривых). Как быть, от чего идти? От QGraphicsItem?

III. На сцене расположены прямоугольнички. Требуется функция, которая возвращала бы ссылки на все прямоугольники, которые более чем половиной площади попадают в заданную фигуру (в моём случае в элипс или полигон). Это нужно для выделения. Представляю себе так:

void MyGraphicsScene::setSelectionArea ( const QPainterPath & path, const QTransform & deviceTransform )
{
  // Находим все фигуры, которые перекаются c selectionArea() методом IntersectsItemShape и методом ContainsItemShape. Вычитаем второе из первого, для полученного списка обычной математикой находим площадь пересечения, дальше всё ясно
}

Далее работа идёт через стандартный QList<QGraphicsItem *> MyGraphicsScene::selectedItems () const.

Есть ли более изящное решение? В частности, хотелось бы как-то определять площадь пересечения средствами Qt, а не своими алгоритмами (которые надо делать отдельно для элипсов и полигонов).

Раньше на ноуте с интелем (но не на десктопе с нвидией) частенько происходило опаньки на главной ЛОРа и некоторых топиках т.ру. Сегодня обновился — больше не падает. Такие дела.

Слава Гуглу!

.

Создал свой Item:

class Cell: public QGraphicsItem
{
    public:
        Cell(QRectF &inRect, QColor &color);

        QRectF boundingRect() const;
        QPainterPath shape() const;
        void paint(QPainter *painter, const QStyleOptionGraphicsItem *item, QWidget *widget);
    private:
        QRectF m_rect;
        QColor m_color;
};

Как его использовать?

Ну то есть я могу сделать что-то вроде

           QRectF myrect(0,0,40,30);
           QColor mycolor(QColor::fromHsv(qrand() % 256, 255, 190));
           Cell *myCell = new Cell(myrect, mycolor);
           scene()->addItem(myCell);

Но выглядит это как-то неправильно. Где хранить массив айтемов? По логике ведь это надо делать в сцене. Чтобы потом можно было их удалять. Чтобы у сцены была функция addCell(Cell*) и всё такое.

Как делать правильно?

Имеется унаследованный от QGraphicsView виджет Area. Переопределены drawBackground() и drawForeground().

scene()->addRect(some_rectangle) добавляет в сцену QGraphicsRectItem и рисует прямоугольничек. Делаем 10000 прямоугольников и получаем тормоза при, например, масштабировании (которые почему-то особенно заметны под виндой).

painter->drawRect(some_rectangle), вызванный для 10000 прямоугольников к тормозам не приводит.

Почему так?

Как делать свой QGraphicsItem, который делал бы прямоугольник и не тормозил? Всякие операции не нужны, только рисовать и удалять.

Неожиданно для себя купил хардтейл. Scott Comp Racing. Вел двухтысячного года, его привезли из США кому-то в подарок и он висел в квартире до вчерашнего дня. Продали за 15000 р. По-хорошему, тут одна только трансмиссия столько стоит. А такие хорошие рамы и неубиваемые вилки сегодня очень сложно найти.

http://picasaweb.google.com/ObeyKun/sVDnDL?feat=directlink

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

Есть поле прямоугольников, все имеют разные размеры. Это _не_ сетка, а более сложная сущность. Само поле не обязательно прямоугольное. Например, всё может выглядеть так: http://rghost.ru/1142360.view (на цвета не обращайте внимания, они тут для красоты :)).

У каждого прямоугольника есть температура. Она меняется во времени (размеры же остаются неизменными). Требуется визуализация этого поля. Примерно вот так: http://mathgl.sourceforge.net/png/dens.png.

Ячеек может быть вплоть до 15000 (в среднем 5000), отрисовка требуется в идеале раз в секунду.

Какие инструменты использовать?

P.S.: я описал общий случай. Из-за ограничений редактора (или, скорее, упрощений во благо пользователя), по сути работать приходится с прямоугольными наборами прямоугольников. Например, вот поле из трёх наборов — http://rghost.ru/1142542.view : в первом наборе прямоугольники 4x4, во втором 2x3, в третьем (перекрывает первое поле) 1x1. Так что и рендер, наверное, буду затачивать под этот частный случай.

В продолжение предыдущей темы.

Есть файл вида

4 45 54 43 
456 45 545 45 
66 65 76 
 
544 546 
45

Из него требуется получить 2 массива: массив с числами первого столбца не пустых строк и массив массивов последующих за ними чисел. То есть тут выйдет так:

{4, 456, 66, 544, 45}

{
  {45, 54, 43},
  {45, 545, 45},
  {65, 76},
  {546},
  {}
}

#include <iostream> 
#include <vector> 
#include <fstream> 
#include <sstream> 
using namespace std; 
 
int main() { 
    ifstream txtInput("input.txt", fstream::in);
    int lineNum = 0; 
    while (!txtInput.eof()) { 
        istringstream fullLine; 
        string tmpTxtLine; 
        getline(txtInput, tmpTxtLine); 
        ++lineNum; 
        fullLine.str(tmpTxtLine); 
 
        while (fullLine.good()) { 
            //тут будем заполнять массив, но пока что (временно) просто показываем по одному числу
            double x; 
            fullLine >> x; 
            cout << x << " "; 
        } 
        cout << endl; 
    } 
} 

Для упомянутого выше файла вывод такой:

 
4 45 54 43  
456 45 545 45  
66 65 76  
76  
544 546  
45  
45 

В конце лишнее число. Почему? Как делать лучше?

Смотрел godaddy, directi, enom, namecheap, moniker, dynadot. Дешевле всего — у enom: по 6 баксов в год. Кто использует? Нормально там? Есть кто-нибудь ещё дешевле?

Есть текстовый файл вида

1 121
3 123
5 111

Надо считать все числа из него в массив. 3 раза я это делал и 3 раза по разному. В последний раз примерно так:

bool ReadFile()
{
    int i;
    if(!file.is_open())
    {
        file.open("data.txt",fstream::in);  //то открываем его
        
        if (file.fail())                    //возвращаем ошибку, если не смогли открыть
        {
            //соответствующий throw
        }
    }
    //тут считываем фигню
    if(file.eof())                      //если файл кончился, закрываем его и возвращаем false
    {
        file.close();
        return false;
    }
    //дописываем фигню в соответствующие массивы
    return true;
}

//соответственно, используется оно так:

while(ReadFile())
{
  //...
}

А как надо?

Иногда вижу префиксы m у перменных (mSomeVar) и I (большая i) у классов (ISomeClass). Насколько я понимаю, второе говорит о том, что класс является интерфейсом. А что есть m?

Какие ещё бывают префиксы?

Если у меня проект графического редактора на Qt, у которого есть поле, область инструментов, линейки масштаба, палитра и т.п., следует ли давать всем этим виджетам какой-то префикс?

Спасибо.

резал перчики чили. потом пошёл и помыл лицо. руками.

уже 15 минут сижу мордой в тазике с холодным молоком. вне него ужасно жжёт.

что делать?