Ринат Велиахмедов: Не говоря уж о том, что формирование массива с последующей сортировкой с вероятностью 99% будет эффективнее, чем формирование словаря.
Ринат Велиахмедов: Использование map вместо vector для int увеличивает использование памяти на 500% при 64 битной адресации. И это при условии аллокатора, оптимально использующего память (int-ключ + int-значение + 2 указателя по 8 байт). Т.е вместо 4 гигабайт получается жалких 24 гигабайт для одной пары массивов. И выше уже было сказано, что массивов может быть не два.
Ринат Велиахмедов: Учитывая, что нужно синхронно сортировать массивы по 4-8 гигабайт каждый, то отсутствие временных контейнеров тут весьма уместно. Я вижу только два решения: 1 - массив индексов, 2 - своя функция сортировки. Вы бы лучше решение предложили, а не отднострочный флуд... Давайте, забацайте самое эффективное решение, раз модификация std::sort "и близко не самое эффективное"(с).
lexdevel: Вот прям сейчас у меня есть проект в 2015 студии со статической линковкой. Пришлось сделать статическую компоновку с MFC, Включить /MT и сделать статические сборки curl и boost. Работает без редистов, проверял свежезавиртуаленной семёрке. Т.е. дело точно не в 2015 студии, а проблема либо в используемых библиотеках, либо в настройках.
Ну и, самое главное, убедись, что настроил /MT именно для релизного проекта. Там диалог свойств иногда подтупливает и открывается не на активном проекте, а как ему приспичет.
lexdevel: Ищи проблему в подключаемых библиотеках. Для не MFC проектов достаточно поставить /MT, чтобы redist не требовало. Но, если какая-то из библиотек (*.lib или *.dll) не была скомпонована статически, то будет эта ошибка выпрыгивать.
Я придумал самое эффективное решение. Напиши свою версию функции сортировки, принимающую два массива, вместо одного. Возможно, std::sort скопируй и дорисуй.
dansheb: Компаратор, это class Compare{ bool operator<( int lhs, int rhs); };
std::sort( array.begin(), array.end(), Compare() );
Но я понял ошибку. Всё таки придётся создать массив с индексами первого массива и вызывать сортировку именно этого массива, но сравнения делать по первому массиву, через эти индексы и менять значения сразу в первом и втором массиве (индексы обменяются сами).
nickostyle: Тоже хотелось бы узнать ответ. Подозреваю, что из-за антиалиасинга всегда будут полупрозрачности появляться.
Можно попробовать решение влоб: растеризовать в большем разрешении, а потом масштабировать. Хотя опять полупрозрачности появятся скорее всего.
nickostyle: Точно, шейпы же есть.) Видимо размер кратен шести и не может без сглаживания точно его нарисовать. У меня такая же муть со шрифтами, жутко бесит. Приходится подбирать положение, когда буквы не полупрозрачной обводкой, а целыми пикселями нарисованы.
frees2: bing отлично выполняет поиск картинок по описанию. Причём, по русско-язычному описанию. Хотя иногда "мёртвые" ссылки возвращает, но это не проблема. Хоть одна из выдачи но нормальная будет. У гугла ограничение в 100 вызовов в сутки (3000 в месяц), а у бинга 5000 в месяц. В принципе, если не считать "трудностей перевода", то бинг справляется.
По указанной ссылке выдача 70 килобайт. И картинки 80*80 пикселей получаются.(
Сделал через bing, выдача 4 килобайта в json формате (можно и в xml или atom, но мне удобнее json был).
Как раз его сейчас и изучаю, в принципе всё подходит. Бесплатного лимита в 5000 запросов в месяц сейчас более чем достаточно... Но туплю на примитивнейшем моменте: не могу получить AppId. Судя по докам, должна быть прям кнопка/ссылка "создать id", но что-то нигде не нахожу... Приложение смог создать, но там ClientId и он не подходит. Не пробовали его получить?
Пробовал через azureб но там авторизация через oauth, форма авторизации появляется после выполнения запроса, а не id в качестве аргумента... нипанятна.
возвращает html на 1.28 мегабайта. json был сотни байт и содержал только нужную информацию. А вызовов десятки и сотни подряд, так что речь о десятках и сотнях мегабайт.
Я в курсе, что сейчас уже почти 2016 год.)
Олег Цилюрик: Я неточно выразился. Под рантаймом подразумевал использование вне объекта сериализации. Т.е. любая обработка строк в utf формате превращается в пытку (банально длину строки хрен нормально узнаешь, без использования специальных функций). А записать/прочитать - это я к рантайму ошибочно не причислил.
MiiNiPaa: OK, про std::string я соврал, давно не пользовался им, забыл особенности.
UTF-формат кодирования юникод символов, в котором каждый символ кодируется от одного до нескольких байт (не скажу, сколько максимум, вроде во 6 байт в китайских диалектах). В то же время в юникод строке каждый символ кодируется одним и тем же количеством байт. А в UTF разным. Хоть UTF-8, хоть UTF-32.
kingdomofcrooked: Извиняюсь, я был не прав. 16/32 бита на канал не решают проблему, это косяк алгоритма градиентной заливки, а не нехватка точности. Но dithering с ней справляется. Видимо, проблема в том, что фотошоп не использует вещественные числа в вычислениях. Так что ставьте галочку dithering и проблема не будет заметна.
kingdomofcrooked: Это да, но именно в процессе построения градиентов у него будет больше свободы для интерполяции. После возврата в 8 бит будет примерно то же самое, что при дисеринге.
