Сейчас сложно сказать, что компилятор X поддерживает или не поддерживает некий стандарт С++ (11/14/17). Конкретные фичи могут быть впилены, а могут быть не впилены. Поэтому смотритм en.cppreference.com/w/cpp/compiler_support
ber_enot ух ты, нашел отличный вариант с привязкой к коллекции колонок через приаттаченное свойство: stackoverflow.com/questions/320089/how-do-i-bind-a... , так что возможно даже получится сделать полностью в рамках mvvm паттерна, положив коллекцию колонок рядом с коллекцией ItemViewModel в объемлющую ViewModel.
ber_enot Идея и состоит в том, что она совместима с mvvm на уровне заполняемых данных, но не метаданных. Генерировать колонки вовсе не обязательно во viewmodel, можно это сделать и отдельным кодом в code behind, или даже унаследовать datagrid (как вариант, не уверен что так будет удобнее). Т.к. природа datagrid такова, что все элементы должны содержать одни и те же колонки (т.е. колонки могут добавляться или удаляться, но для всех элементов сразу), то удобнее всего помимо viewmodel-ек элементов иметь еще и общий объект метаданных, в котором будет указан список имен пользовательских свойств. Потом по этом списку генерировать колонки с привязками, ну и словари заполнять во viewmodel тоже.
Итак, еще раз мое предложение: каждая строка datagrid это viewmodel-ка, у нее есть стандартные свойства, которые реализованы как обыкновенные дотнетовские свойства, в самом датагриде есть стандартные колонки с привязками к стандартным свойствам. Как и всегда, ставите datagrid.ItemsSource = itemViewModels; где itemViewModels это List. А вот теперь добавим к этой обычной схеме динамические колонки. В ItemViewModel делаем указанный выше словарь пользовательских свойств. Помимо этого, при получении данных и формировании содержимого List также будем создавать объект метаданных - один на ВСЕ экземпляры ItemViewModel - с именами всех пользовательских свойств. Например, можно сделать такой: class UserPropertyInfo { string name; string displayName; }, где name - это имя для извлечения из словаря, а displayName - отображаемое имя, например, заголовок для колонки в датагриде. И такой список: List. Из приходящих данных мы создаем этот список свойств, ну и собственно список самих ItemViewModel. После этого к стандартным колонкам в датагриде добавляем по одной колонке для каждого UserPropertyInfo с биндингом вроде указанного в ответе. Колонки конечно придется создавать руками в коде, привязки для коллекции колонок наверное сделать не получится.
brainick согласен, что серьезная, но не вижу проблемы, чтобы "для начала". Вы хотите, чтобы для начала было "проектирование SQL-баз для чайников", где автор сам толком не понимает, что делает, просто у него когда-то это работало и он теперь пытается донести до других. Я считаю книгу Дейта незамутненой различными сугубо практическими проблемами, вроде узконаправленной оптимизации запросов, денормализации и пр., но теор. базис она дает хороший. Читается относительно легко даже студентом, который хотя бы на половину пар ходит. Лучше сразу узнать, что такое нормализация и избыточность, чем несколько лет доходить до просветления.
Собственно у нас лекции были ничем не проще, даже сложнее были из-за того, что математика такая же (ФЗ, норм. формы, ключи...), а примеров и объяснений давали мало.
Вот например, Ульмана "Database Systems: The Complete Book" новичку читать точно не нужно - по этой книге свою СУБД разрабатывать можно, не то что базы проектировать)
@eddyx
> Вы предлагаете прочитать бинарник стримами
если C++ это также не обязательная вещь, как я изначально предположил по тегам к вопросу, и основная задача это
> по известному алгоритму разбить бинарную строку разделителями и загрузить результат в файл Excel
то у вас два недолгих пути:
1) берете Excel, открываете VBA и пишете макрос, который распарсит файл и добавит все в текущую книгу, вешаете макрос на кнопку. Минусы - надо работать с VB6, плюс интерфейс делать не очень сподручно.
2) берете VS, ставите ее с office sdk (нужно в установщике выбрать пункт), создаете проект Excel Add-In на шарпе, пишете на C# все что вздумается, загружаете Addin в Excel, пользуетесь. Плюсы - написать можно все что угодно на нормальном языке, минусы - надо ставить студию и вообще подходить основательно.
Если на задачу есть время - лучше второй путь, проще будет расширить и поддерживать (Visual Basic for Applications это конечно уже музейные дела. Работу он свою выполняет, но возможностей у него только на макросы и хватит. Хотя по идее файл прочесть вы им сможете).
Wojciech про Valve тут ни к чему, это другой масштаб. Они полдвижка на асме перепишут, если это даст им выигрыш в качестве продуктов. Конечно, интерфейсы движка можно сделать для разных языков, но если учесть, что у них топовые дорогие движки (unity имхо для более широкого использования), то они резонно считают, что покупатели найдут себе спецов нужного уровня для работы с их двигом.
@frosty7777777
> Будет ли базой данных информация, которая хранится не в компьютере?
Лично я считаю, что физическая организация обработки данных - десятое дело относительно самой модели данных. Представим себе ситуацию, что у вас есть архив табличных данных (очень большой объем распечаток, например, погодных данных), и вы посадили тётеньку-оператора принимать запросы на извлечение данных. Теперь представьте, что тетенька очень хорошо выучила стандарт SQL и запросы ей можно писать на SQL на бумажке, и отдавать результаты она тоже будет на бумаге (допустим, выписывать нужные данные или снимать ксерокопии с архива). Чем не SQL-база с бумажным интерфейсом?))
Однако, в общепринятой практике базой данных НЕ считают то, что обрабатывается вне ЭВМ. Даже на русской вики есть много определений БД, но первым критерием указывается:
>> БД хранится и обрабатывается в вычислительной системе.
так что если ваш вопрос не чисто философский, то внекомпьютерные хранилища базами данных не называют.
xmoonlight кстати, пока что самый дельный совет, многие просто выпиливают некоторый ключевой функционал из сборки триала (чтобы его там в принципе не было, тогда ломай/не ломай - не имеет значения).
Lorem Ipsum ну так если взлом вполне реален (т.е. программой будет пользоваться широкий круг людей), то от дебаггера вас только обфускация спасет. На то платные защиты и существуют)
@koceg
> есть коммит, в котором какие-то изменения нужны, а какие-то - нет
а, ну если так, то да, придется просто создать новый коммит. Вопрос мутно задан, 3 раза прочитал, так до конца и не понял)
pixik ваш поток сравним со скоростью передачи данных в некоторых старых типах оперативной памяти (www.transcend-info.com/Support/FAQ-292), так вам скорее всего любая реализация MQ в чистом виде не подойдет. Однако я бы попробовал скрестить ее, например, с общей памятью (shared memory) в критичных местах. То есть, управляющие сообщения (начать/остановить вычисления/передачу блока данных) посылать средствами Qt, т.к. их будет немного, и класть туда указатели на общую память, т.к. такие объемы данных совершенно нереально упаковывать в сообщения и вообще нет смысла гонять туда/сюда - лучше обращаться из разных потоков в одно место памяти. Разумеется синхронизировать доступ и разграничивать критические секции вам придется самостоятельно. Но другого решения в вашем случае я не вижу.
