Поддерживаю насчёт реализации GC в самом языке.
Мне кажется в С++ сборщик мусора не сильно необходим (может только для того, что бы не отставать от остальных языков).
Если разработчик задумывается о GC — возможно ему просто нужно использовать специализированные аллокаторы. Они, конечно, не дадут вам полностью забыть о проблемах памяти, но позволят более эффективно ей пользоваться.
Для С++ разработчики игр эту область очень сильно «проработали».
Так вы просите показать половину возможностей DevExpress, а что конкретно в эту половину должно входить не говорите :)
Я так понимаю, вы просто хотите сказать, что уже есть решения с очень богатым функционалом (правда за деньги и на одной платформе). Я с вами соглашусь. Могу привести еще один подобный пример QTitan. «Тягаться» с ними в одиночку тяжело, и, я думаю, не нужно.
Мне нравиться один из принципов, которым руководствовался Страуструп, когда создавал C++. Он говорил — Вы не должны платить за то, чем не пользуетесь. Например, если вы не пользуетесь полиморфизмом — вы не должны платить за косвенные вызовы функций, они должны вызываться так же быстро как и в С или даже по возможности встраиваться.
Этот принцип я попытался воплотить и здесь. Грид должен позволять использовать себя и как простой список (ListBox) и как аналог Excel (с дикими раскладками ячеек, возможностью задавать итоговые поля и т.п.). Это похоже на gentoo. Первый пользователь собирает грид с небольшим набором стандартных Views и получает небольшой и шустрый контрол. Второй пользователь собирает грид с другим набором классов (их будет больше и их логика работы будет сложнее и тормознее) — и получает увесистый модуль. Так вот, первый пользователь не платит за всё многообразие, которое потенциально может получить.
Опять же, проведу аналогию с С++. Есть грид, который, как у меня описано, может отображать Views. Сам по себе грид малополезен (как и С++). Но есть реализованный набор стандартных Views (для selection/column-rows resizing/filtering/sorting и т.п.) — это аналог стандартной библиотеки. Таким образом гридом уже можно сносно пользоваться «из коробки». Но если грид позволяет реализовывать дополнительные Views, которые могут сочетаться со стандартными Views или написанными кем-то еще. И все их можно комбинировать в одном контроле (это аналог С++ библиотек). Вот тут появляется мощь. Грубо говоря — если кто-то сделал view для отрисовки цвета, не как у меня в примере в квадратике, а, например, в кружочке и опубликовал этот view, то грид автоматически для всех обогатился новой возможностью.
Моя цель именно такая — постараться найти такую архитектуру грида, при которой повторное использование разных кастомизаций будет легким и естественным. Постараюсь более внятно написать в следующей статье.
пистолет тоже очень опасен, если стрелять им в себя. да и UINT_t может поменяться, судя по вашим же словам!
Я лишь хотел сказать, что пользователь этой библиотеки вначале для себя решит каким будет у него UINT_t и потом никогда-никогда его не менять.
По-честному, если речь о количестве строк или столбцов, то 64-битный беззнаковый тут точно не нужен, это уже наверняка привычка к корпоративному Coding Style в вас говорит :)
Согласен, например нам вполне достаточно unsigned int.
Хотя если заниматься лихачеством — можно создать грид с неописуемым количеством строк и задать текстовую модель, которая сама ничего не хранит, а лишь выдает строковое представление номера строки. По идее этот грид должен на этом синтетическом примере тоже работать и память не особо кушать.
size_t опасен, если будете его сохранять куда-то в бинарном виде, а потом мигрировать проект с 32 на 64 бита.
По поводу github — думаю сначала написать еще заметку — есть еще что рассказать. Реально по срокам, думаю, после новогодних каникул появится что-то более-менее юзабельное.
«Стандартного грида» вроде как нет. Реализовали с нуля — наследование от основного оконного класса CWnd.
Вся платформенная специфика локализована в двух классах: GridWindow — контрол управления и DrawContext — рисовальщик. Всё остальное написано на C++/STL.
UINT_t это typedef на какой-то беззнаковый целочисленный тип (можно для себя решить: использовать «большие» 64bit или «маленькие»32bit числа).
Вы знаете, в этом есть свои плюсы — когда пользуешся чем-то плохим, больше вероятность создать что-то новое (свое). Когда пользуешься посредственным инструментом — сидишь на нём и терпишь: о)
Вернее в QSS нельзя внести новые элементы для своих виджетов.
Для «обрезки» текста вроде есть такой метод QFontMetrics::elidedText, если я не ошибаюсь.
Мне кажется в С++ сборщик мусора не сильно необходим (может только для того, что бы не отставать от остальных языков).
Если разработчик задумывается о GC — возможно ему просто нужно использовать специализированные аллокаторы. Они, конечно, не дадут вам полностью забыть о проблемах памяти, но позволят более эффективно ей пользоваться.
Для С++ разработчики игр эту область очень сильно «проработали».
Полезный подход, в том числе и для локальных оптимизаций.
Вы мне лучше пример грида, который вам нравится приведите? Чем он хорош для Вас? Как он устроен? Чего не хватает в нем?
У реализации в Qt тоже есть недостатки (да и по времени он не сильно моложе MFC).
Я так понимаю, вы просто хотите сказать, что уже есть решения с очень богатым функционалом (правда за деньги и на одной платформе). Я с вами соглашусь. Могу привести еще один подобный пример QTitan. «Тягаться» с ними в одиночку тяжело, и, я думаю, не нужно.
Мне нравиться один из принципов, которым руководствовался Страуструп, когда создавал C++. Он говорил — Вы не должны платить за то, чем не пользуетесь. Например, если вы не пользуетесь полиморфизмом — вы не должны платить за косвенные вызовы функций, они должны вызываться так же быстро как и в С или даже по возможности встраиваться.
Этот принцип я попытался воплотить и здесь. Грид должен позволять использовать себя и как простой список (ListBox) и как аналог Excel (с дикими раскладками ячеек, возможностью задавать итоговые поля и т.п.). Это похоже на gentoo. Первый пользователь собирает грид с небольшим набором стандартных Views и получает небольшой и шустрый контрол. Второй пользователь собирает грид с другим набором классов (их будет больше и их логика работы будет сложнее и тормознее) — и получает увесистый модуль. Так вот, первый пользователь не платит за всё многообразие, которое потенциально может получить.
Опять же, проведу аналогию с С++. Есть грид, который, как у меня описано, может отображать Views. Сам по себе грид малополезен (как и С++). Но есть реализованный набор стандартных Views (для selection/column-rows resizing/filtering/sorting и т.п.) — это аналог стандартной библиотеки. Таким образом гридом уже можно сносно пользоваться «из коробки». Но если грид позволяет реализовывать дополнительные Views, которые могут сочетаться со стандартными Views или написанными кем-то еще. И все их можно комбинировать в одном контроле (это аналог С++ библиотек). Вот тут появляется мощь. Грубо говоря — если кто-то сделал view для отрисовки цвета, не как у меня в примере в квадратике, а, например, в кружочке и опубликовал этот view, то грид автоматически для всех обогатился новой возможностью.
Моя цель именно такая — постараться найти такую архитектуру грида, при которой повторное использование разных кастомизаций будет легким и естественным. Постараюсь более внятно написать в следующей статье.
Согласен, например нам вполне достаточно unsigned int.
Хотя если заниматься лихачеством — можно создать грид с неописуемым количеством строк и задать текстовую модель, которая сама ничего не хранит, а лишь выдает строковое представление номера строки. По идее этот грид должен на этом синтетическом примере тоже работать и память не особо кушать.
По поводу github — думаю сначала написать еще заметку — есть еще что рассказать. Реально по срокам, думаю, после новогодних каникул появится что-то более-менее юзабельное.
Вся платформенная специфика локализована в двух классах: GridWindow — контрол управления и DrawContext — рисовальщик. Всё остальное написано на C++/STL.
UINT_t это typedef на какой-то беззнаковый целочисленный тип (можно для себя решить: использовать «большие» 64bit или «маленькие»32bit числа).