starkdm
1) во-первых вас тут никто за дурака не держал. Люди тут разные, есть те, которым этот совет реально может помочь, а телепаты и экстрасенсы сейчас на море, т.к. сезон отпусков.
2) опечатка это опечатка. Исправили - спокойно откомментировали. Как видите, я не единственный кто прочитал ваш код как есть. У меня тоже string съелся когда я ответ писал, взял и отредактировал, бывает.
3) проверять в студии или где-либо еще вам тут никто не обязан. Относительно того, что вы написали изначально я вам дал нормальную рекомендацию - подобную ошибку и должен выдать компилятор.
4) вот ближайший к вашему коду вариант, не выдающий ошибок компиляции: ideone.com/0RrK6x . Как видите, если функция GetFiles определена, все компилируется без проблем.
> P.s. используются c++ cli и надо что бы по кнопке какраз загружался sfml.h с библиотеками и дллками Армянское Радио не зря удивился - sfml.h у вас точно не загрузится, т.к. с хедером работает компилятор, а не ваша программа. Вам нужен ликбез по процессу компиляции и назначению хедер-файлов в нем, т.к. сейчас вы предлагаете, чтобы при запуске мотора в автомобиле появлялся инженер с завода-изготовителя и спрашивал, какой двигатель вам поставить для текущей поездки. Ну т.е. я не уверен что вы хотите написанного))
Сергей Ковалёв
> Вы ради двух серваков настроили кастомные PS DSC
Это сейчас их два, нам очень хочется, чтобы их потребовалось на порядок больше. Достигнем такого размаха или нет - увидим, но готовимся мы уже сейчас. Конечно, после анонса MS нормальной кроссплатформенной работы asp.net многие задачи можно будет решить иначе, но до недавнего момента это было не так.
Видите ли, мы ценим Chef и их аналоги прежде всего за возможность загитить конфиги и не попасть потом на утечку знаний из-за текучки кадров. Вы же, я думаю, знаете что в IT непринято задерживаться больше 2-х лет на одной позиции, а работу и полномочия рано или поздно делегировать нужно. Не знаю как другие с этим борятся, но для нас конфиги такая же часть продукта, как и код веб-сервисов.
И самое главное, многие клиенты захотят иметь наш сервис в on-premises режиме (берегут свои данные), поэтому работа с такими конфигами еще и залог прозрачности изменения конфигурации серверов. Т.е. такие клиенты врядли дадут нам подцепиться по VPN и переконфигурить им там все, даже начальное развертывание серверов планируется делать по прозрачному сценарию, который при необходимости можно будет показать местным IT-шникам. Будут они разбираться в скриптах или нет - уже их дело (хотя, видимо все-таки будут).
Так что полностью согласен насчет 2-х application-серверов и SQL-базы, которые и правда можно поставить за полдня, суть в том, что для нас эти конфиги станут рабочим активом, также как и основной код продукта (сегодня нужен IIS, вскоре уже планируется цепляться к корпоративному LDAP, чтобы смотреть юзеров и группы, потом захотят файлопомойку с привязкой к предметной области (для договоров и прочих справок) - еще понадобятся виртуалки или железные сервера, ну и т.д.).
В общем, если в течение 2-х лет поднимем на DSC более 20-30 серверов в общей сложности - я вам отпишусь)
Сергей Ковалёв ну и заодно расскажите о проблемах с которыми столкнулись, может действительно не стоит вкладываться в это, мы-то еще маленькие, может пора на asp.net 5 мигрировать, да линуха поднимать, пока не поздно)
Сергей Ковалёв Не могу сказать что у меня 100 серваков этим управляется, с двумя IIS-ами, одним SQL и одним TFS под проект - как-то справляемся (бэкапы, рестарты, всякие деплои нестандартные с CI на TFS на проды), а вас есть что-то революционное под винду? С удовольствием посмотрю)
Андрей хм, а как оно повлияет на ситуацию? Оно б могло скорее помочь прикинуть, сколько до объекта сантиметров, если он в фокусе, но если мы игнорируем глубину (вычисляем ее за счет использования нескольких ракурсов, как делает наш мозг), то тогда без разницы.
Роман Кофф Вот кстати очень близко к вам: habrahabr.ru/post/130300 , тут про машинное стереозрение и соответствующие расчеты.
> Карта глубины может быть получена с помощью специальной камеры глубины (например, сенсор Kinect является своего рода такой камерой), а так же может быть построена по стереопаре изображений.
Часть вашей задачи.
Pavel_Develop
не пользуюсь, это антипаттерн и я вполне обхожусь без него (т.е. помещаю логику в модельные классы). Он появляется от чрезмерного желания разделить приложение на много слоев, отчего некоторые слои в конце-концов мало что толкового делают (пресловутые Business Logic layer и Data Layer).
diver23
> вводить денормализацию тегов что бы ускорить выборку
отметьте на будущее: стандартный цикл разработки структуры БД (там, где есть схема) - нормализация "до упора", денормализация по необходимости для ускорения конкретных (!) запросов. Обычно для 80% запросов нормализованная структура вообще проблемы не составляет, и только 20% и менее самых тяжелых или самых частых (например, отрабатывающих на главной странице) требуют введения избыточных данных.
Pavel_Develop
> Я имел ввиду не маппинг БД и ORM, а маппинг между сущностями Document и Order
что-то совсем непонятно стало. Для маппинга саб-классов на таблицы есть несколько стратегий: single-table inheritance, class-table inheritance concrete table inheritance, single table замапает вам несколько классов на одну таблицу. Это конечно если вы пришли к тому, что вам действительно нужно несколько классов.
@JustSokol
QSet is one of Qt's generic container classes. It stores values in an unspecified order and provides very fast lookup of the values. Internally, QSet is implemented as a QHash (doc.qt.io/qt-5/qset.html#details).
Итак, значит QSet сделан на базе QHash. Конечно, на википедию давать ссылку немного несерьезно, но сейчас поздно уже, я себе позволю) : https://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%...
Читаем: Ситуация, когда для различных ключей получается одно и то же хеш-значение, называется коллизией. Такие события не так уж и редки - ... Поэтому механизм разрешения коллизий — важная составляющая любой хеш-таблицы.
И далее перечисляются методы, самые популярные два - вешать на значение хэша список (!) элементов с таким хешем, либо же просто вставлять элементы друг за другом, т.е. искать следующий свободный слот (неважно, что он может потенциально понадобиться другому элементу).
Суть хэш-таблицы - в ускорении поиска, приближении его к O(1) (как, в принципе, и вставок). Точная проверка совпадения обеспечивается дополнительно.
> он сначала по хешу найдет два значения а потом сравнит с каждым и даст ответ
да, разумеется. Там может быть хоть 100 значений на хэш, операция должна выполниться корректно (другое дело - будет выполняться медленнее, чем хочется).
Кстати, внимательно почитайте требования к типу элемента:
- QSet's value data type must be an assignable data type.
- the type must provide operator==()
- must also be a global qHash() function that returns a hash value for an argument of the key's type.
С присвоением понятно, с qHash тоже, обратите внимание на оператор сравнения - никто его не отменял, он по прежнему нужен и должен корректно отрабатывать.
Резюме: проблема поиска хорошего хэша безусловно есть в каждой подобной задаче, однако это вопрос снижения сложности операций поиска/вставки и повышения производительности. После поиска по хэшу всегда будет поиск на точное совпадение (даже если по хэшу найден только один элемент - вдруг это коллизия и у нас не точное совпадение).
Artem да я так его три раза прочел прежде чем ответить, расскажите пожалуйста почему вас так беспокоит случай совпадения конкатенаций. Т.е. есть два вопроса: 1) понимаете ли вы, что уникальный хэш получить невозможно для строк той длины, что у вас есть; 2) непонятно зачем вам уникальный хэш и почему вас так беспокоит его неуникальность в достаточно редком на мой взгляд случае.
Если строки у вас совсем короткие, по 2-3 символа, то тогда совпадать будет почаще, значит пример с именами неудачный.
xfg как правильно заметил Дэн Иванов, до готовой системы разумеется еще далеко, и граблей будет навалом. Я думаю мы бы с вами могли на пару недель сесть и обдумывать одни только проблемы и пути их решения.
Конечно, файлы было бы неплохо разбивать на кластеры, наподобие того как делают обычные ФС, и хэшировать кластеры, а не весь файл, а сами хэши сохранять в метаинфе, и хранить их как i-blockи хранятся в ext, по иерархическому принципу. Тогда файлы можно сильно фрагментировать (по 1 ГБ к примеру), и разбрасывать куски по хранилищам.
Маппинг пространства хешей на ноды можно немного усложнить, и мапать по принципу хэш-таблицы: если на ноду N файл не влазит уже, класть на N+1 (также и искать потом), позже, по достижению критического количества неверных попаданий, перехешировать, увеличивая длину части хэша, по которой определяется номер ноды (вместо первых 3-х байт хеша - первые 4).
Давайте решим, что вам нужно: вы готовы писать свой велосипед и решать все проблемы выше, или вам все-таки нужно готовое решение. Если готовое - вон, Дэн Иванов отлично посоветовал. Амазоновский S3 в конце-концов есть, даже ставить ничего не надо. Или может у вас файлы по 1кб и вам хватит того же Redis?)
@Avery007
> А насколько сильно использование фабрик скажется на производительности?
это обычная функция, т.е. ее вызов должнен быть даже дешевле, чем виртуальный вызов функции в интерфейсе (конечно, если не считать расходы на загрузку DLL в начале работы и прочие дела). А так да, как сказал MiiNiPaa - что туда положите, то там и будет. Смысл в том, что даже если там обычный new, и больше ничего - все равно это важно, т.к. вызов оператора new подразумевает знание РАЗМЕРА объекта (сколько место под поля выделить), а размер объекта в памяти - это по сути часть реализации, т.к. может изменяться при изменении кода реализации. Это вообще отдельная проблема в C++, различные библиотеки применяют различные подходы для ее решения, например Qt использует PImpl, погуглите.
Если вы вызываете new внутри библиотеки, то вызывающему функцию-фабрику НЕ НУЖНО знать о размере объекта, что принципиально важно: вы можете добавить пару полей в ваш ConcreteFooService, и вызывающее приложение перекомпилировать не нужно. Если вы вызывающее приложение делало new, то потребовалась бы его перекомпиляция, т.к. каждый new это выделение КОНКРЕТНОГО фиксированного объема памяти.
Таким образом, в случае использования фабрик такой аспект реализации, как размер объекта, остается в ведении DLL и не "вытекает" наружу, создавая вредные зависимости.
