Matwey
А, только у меня не так
Matwey
Я наврал всё
Matwey
У меня не одинаковые перегрузки. А один был дополнительный аргумент и два варианта перегрузки: более специализированный, с int, а другой менее специализированный с ....
А дальше при вызове с 0, компилятор по decltype разбирался может ли он сделать более специализированный вариант в данном случае
blow
почему cos() и sin() не работает в borland 3.1?
blow
ну вообщем грит про ошибку линкера (типа этого дает: "Undefined symbol FIWRQQ in module *fileName*.cpp")
Крылатый
@supapro
PRoSToC0der
Добрый день. Подскажите, пожалуйста, почему, например, Qt не использует в своих интерфейсах fixed width integer types (http://en.cppreference.com/w/cpp/types/integer)? То есть, например, конструктор QRect (http://doc.qt.io/qt-5/qrect.html) у них принимает 4 int значения, и хранит их в виде четырёх int, а при сериализации внутри кастует в зависимости от версии либо к qint16, либо к qint32 (https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b91381608c6/src/corelib/tools/qrect.cpp#L1278). Этому вообще есть какие-нибудь причины? Что-то историческое? Стоит ли вообще использовать fixed width integer types по возможности где только можно? У нас в проекте много чего сериализуется, мы дорожим обратной совместимостью и не хотим ломать формат.
я бы даже диапазон ограничивал, но надо под это дело писать специальный класс
типа есть функция:
int BZ2_bzCompressInit ( bz_stream *strm,
int blockSize100k,
int verbosity,
int workFactor );
http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html#bzcompress-init
и параметры blockSize100k и workFactor описать как integer<0, 9> blockSize100k и integer<0, 250> workFactor
Maksim
я бы даже диапазон ограничивал, но надо под это дело писать специальный класс
типа есть функция:
int BZ2_bzCompressInit ( bz_stream *strm,
int blockSize100k,
int verbosity,
int workFactor );
http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html#bzcompress-init
и параметры blockSize100k и workFactor описать как integer<0, 9> blockSize100k и integer<0, 250> workFactor
В итоге, я так понимаю, это всё выливается просто в ассерты, да?
PRoSToC0der
В итоге, я так понимаю, это всё выливается просто в ассерты, да?
а вот тут уже можно подумать для чего это использовать и как это проверять
Maksim
Насколько я понял, в идеале вообще голых типов не должно использоваться. Должно быть что-то типа https://github.com/foonathan/type_safe
Maksim
Но это только в идеальном мире.
PRoSToC0der
если замутить литерал для compile-time числа, то можно прямо во время компиляции проверить константу
если по всему проекту такой ограниченный диапазоном integer использовать, то тоже можно во время компиляции всё проверить
PRoSToC0der
Насколько я понял, в идеале вообще голых типов не должно использоваться. Должно быть что-то типа https://github.com/foonathan/type_safe
ага, хочу в новом проекте такое по всему коду юзать
Maksim
Число приходящее в runtime никак в compile-time не проверишь.
Alexander
ну, если оно из конфига приходит или откуда-то из сериализации, то разрешать создавать только с рантайм проверкой, и она будет нужна один раз
Igor
Насколько я понял, в идеале вообще голых типов не должно использоваться. Должно быть что-то типа https://github.com/foonathan/type_safe
мечтаю о будущем в котором auto velocity = cur_velocity + vec3::z_up * 20m/sec{}; auto distance = velocity * time_delta; не просто компилируется и проверяется на валидность единиц измерения в компилтайме, но и является стандартом и поддерживается во всех либах и фреймворках :(
Maksim
Красота.
PRoSToC0der
а вот тут уже можно подумать для чего это использовать и как это проверять
для того же std::optional можно юзнуть, правда это будет уже какой-нибудь optimized_optional
Alexander
Товарищи, кто-нибудь сталкивался с проблемой: закруглие углов изображения в qt
Олександр
V
Здравствуйте
V
Что лучше передавать base64 image или byte[] image? я про трафик
B
Base64 в 1.7 раз больше чем просто байты
B
В среднем
Valery Korolyov
[lol@lol git]$ dd if=/dev/urandom of=test bs=1 count=1000
1000+0 записей получено
1000+0 записей отправлено
1000 байт (1,0 kB) скопирован, 0,0102914 s, 97,2 kB/s
[lol@lol git]$ base64 test > test2
[lol@lol git]$ du -b test*
1000 test
1354 test2
[lol@lol git]$
Valery Korolyov
У меня base64 из тысячи байт вышел в 1.354 раза длиннее. Воть.
V
минуту
Anton
Base64 всегда больше выходит
V
минуту я файлы соберу
V
myjpgBytes = mytexture2d.EncodeToJPG();
encodedtoBase64 = Convert.ToBase64String(myjpgBytes);
sig._hubProxyBroadcating.Invoke("Broadcast", myjpgBytes);
File.WriteAllText("C:/1/yourtextfile" + i + ".txt", encodedtoBase64);
string result = System.Text.Encoding.UTF8.GetString(myjpgBytes);
File.WriteAllText("C:/2/yourtextfile" + i + ".txt", result);
Ivan
int main()
{
int a = 15;
int* b = &a;
*b++ = 1;
std::cout << (*b);
return 0;
} парни, читаю ассемблерный код, не могу раздуплить https://godbolt.org/g/9fKjvB
V
вот код вобщем файл с байтами выходит
V
68
V
а base 64 50
Anonymous
Что страуструп делает на аве?
Alexander "SonnySlave"
Igor
Igor
куда выводит?
V
помогите
Andrey
А потом разыменовываешь его?
Ivan
Зачем ты двигаешь указатель b на следущий участок памяти?
Это не важно), мне важен порядок операций. Он определён формально или нет
Igor
да тьфу на вас, писать "не вдупляю" не говоря во что, и предлагать запустить код на годбольте :)
Andrey
Это не важно), мне важен порядок операций. Он определён формально или нет
Формально тут, минимум, нарушение strict aliasing.
Valery Korolyov
Это не важно), мне важен порядок операций. Он определён формально или нет
Очевидно, сперва происходит разыменовывание и присваивание, а затем инкремент. Выводится уже содержимое следующей ячейки памяти.
Ivan
Ivan
Просто дизассемблер кланга не такой
Andrey
Только в дебаге.
Andrey
В релизе оптимизатор может разных неожиданных вещей напридумывать, в зависимости от контекста.
PRoSToC0der
Формально тут, минимум, нарушение strict aliasing.
имеешь в виду обращение к int* b через (&a+1) как к int?
Andrey
имеешь в виду обращение к int* b через (&a+1) как к int?
Да, только не через (a + 1) а через ((&a) + 1)
PRoSToC0der
Да, только не через (a + 1) а через ((&a) + 1)
но с другой стороны определённый порядок размещения на стеке тоже не гарантируется
Andrey
Фактически ты обращаешься через указатель на int к памяти которая по мнению компилятора int'ом не является.
Andrey
Стандарт не только не гарантирует порядок на стэке, но даже то, что рядом написанные переменные будут лежать в соседних ячейках памяти.
Igor
Стандарт не только не гарантирует порядок на стэке, но даже то, что рядом написанные переменные будут лежать в соседних ячейках памяти.
смутно припоминаю, что стандарт вообще никакого стека не гарантирует, только вызов деструкторов при выходе за скоуп в порядке обратном объявлению
PRoSToC0der
а для своего типа реально ли сделать коммутативный operator[] также как у указателей?
Aidar
Всегда так будет?
Какая разница что будет, тебе гарантируют такой же результат как если бы было
Andrey
Фактически ты обращаешься через указатель на int к памяти которая по мнению компилятора int'ом не является.
Т.е. для компилятора это либо нарушение strict aliasing если он может доказать, что указатель принадлежит памяти другого типа, либо чтение неинициализированной памяти, если адрес оп мнению компилятора указывает на память, которую программа законно не получала.
Aidar
А уб ничего не гарантирует
Aidar
Он ломает все гарантии наоборот
Aidar
Прога просто невалидна, и читаю мусор
Aidar
Aidar
Не стоит пытаться описать действия компилятора на уб
Aidar
Только если вы не пишете его
Andrey
Можете не брать пожеванное, если зубы крепкие. )
Andrey
Имел ввиду, что "с точки зрения стандарта" а не "для компилятора"
Andrey
Только если вы не пишете его
Это вы точно подметили. Стандарт это одно, а компиляторы это совершенно другая грань.
Ivan
Так, там сначало произошло присвоение, потом сдвиг указателя вперёд и там мусор лежит