Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Не, я конечно давно знаю что если хочешь сортировать объекты с переменной длинной, то сортируй указатели на них. Но.... разве класс string не является сам по себе указателем на данные? Да даже если оно хранит данные напрямую в структуре и Record.s на самом деле переменной длины, почему тогда значение целого не портится? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 21:44 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
При использовании в C++, функция qsort по много раз уничтожает объект (вызывает деструктор у Record и у std::string) и копирует указатель на освобожденную память, поэтому ваш код просто будет падать с Seg Fault. Потому что для классов из C++ (struct вызывающих деструктор) надо использовать std::sort из C++, а не qsort-из C. Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 22:12 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, не подтверждаю. qsort не знает ничего о сортируемом объекте, С++ не дает такой инфы. исправленный пример и вывод Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. zoriginal qwe 4 ertyu 2 dfgcvb 3 a 0 fhuj 1 qsort by int a 0 fhuj 1 ertyu 2 dfgcvb 3 qwe 4 qsort by string a 0 dfgcvb 3 ertyu 2 fhuj 1 qwe 4 4-destructs 1-destructs 2-destructs 3-destructs 0-destructs gcc 4.9.2 отдыхать надо, среда скоро ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 22:53 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
SiemarglВася Уткин, не подтверждаю. qsort не знает ничего о сортируемом объекте, С++ не дает такой инфы. исправленный пример и вывод Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. zoriginal qwe 4 ertyu 2 dfgcvb 3 a 0 fhuj 1 qsort by int a 0 fhuj 1 ertyu 2 dfgcvb 3 qwe 4 qsort by string a 0 dfgcvb 3 ertyu 2 fhuj 1 qwe 4 4-destructs 1-destructs 2-destructs 3-destructs 0-destructs gcc 4.9.2 отдыхать надо, среда скоро А давно ли чисто сишный qsort() на вход стал принимать итераторы из C++, вместо указателей? 1. Сначала переписывайте с arr.begin() на &arr[0] 2. Затем меняйте static_cast<const Record*>(a); на reinterpret_cast<const Record*>(a); 3. Теперь получайте SegFault и удивляйтесь :) 4. Убирайте временно string s из Record и добавляйте в Record деструктор с выводом сообщения 5. Профит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 23:56 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Siemarglgcc 4.9.2 отдыхать надо, среда скорохмммм... У тебя строки не портятся. Так. Подправлю код чтобы было лучше видно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. И вывод очень странный: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Я собираю на 5.3.0 на винде. А если после создания строк добавить for(auto &r:arr) r.s.reserve(32); (оно там закоментировано сейчас). То все становится замечательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 00:00 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Начиная с GCC 5.1.0 уже падает с ошибкой памяти: https://wandbox.org/permlink/SDDOPMgBqGjgLfT7 На clang везде где компилируется с 3.5.0 по Head 7.0 - работает нормально: https://wandbox.org/permlink/qNn1lnocaiHEab4W Ну и на винде судя по всему работает, но неправильно - портит символы. Вот они грязные хаки к чему приводят ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 00:14 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася регайся. Чорт тебя подери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 00:47 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, нет там грязных хаков. надо брвть норм версию компилятора, а не говнобету 5.1, и разбираться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 00:49 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
maytonВася регайся. Чорт тебя подери Пока без багов писать не начнёте не зарегюсь SiemarglВася Уткин, нет там грязных хаков. надо брвть норм версию компилятора, а не говнобету 5.1, и разбираться Siemargl Код: plaintext 1. 2. 3. Вопрос, что надо передать в qsort: результат функции begin() или data()? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf Page 480 21.2.2 Header <cstdlib> synopsis // 28.8, C standard library algorithms void qsort( void* base, size_t nmemb, size_t size, c-compare-pred * compar); void qsort( void* base, size_t nmemb, size_t size, compare-pred * compar); http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf Page 1049 28.8 C library algorithms void qsort( void* base, size_t nmemb, size_t size, c-compare-pred * compar); void qsort( void* base, size_t nmemb, size_t size, compare-pred * compar); http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf Page 872 26.3.7.1 Class template array overview // iterators: constexpr iterator begin() noexcept; constexpr const_iterator begin() const noexcept; constexpr iterator end() noexcept; constexpr const_iterator end() const noexcept; constexpr T * data() noexcept; constexpr const T * data() const noexcept; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 01:44 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
White OwlА если после создания строк добавить for(auto &r:arr) r.s.reserve(32); (оно там закоментировано сейчас). То все становится замечательно. Очевидно же, что это все из-за small string optimization в std::string начиная с gcc 5.1, т.к. сишный qsort() использует memcpy() вместо operator=() и конструктора. В общем грязные хаки такие как передавать итератор вместо указателя или использовать сишный qsort() для классов с конструкторами и операторами копирования ни к чему хорошему не приводят. https://isocpp.org/blog/2015/04/gcc-5.1-released GCC 5.1 released A new implementation of std::string is enabled by default, using the small string optimization instead of copy-on-write reference counting. Что будет если запустить такой код? https://wandbox.org/permlink/9pfxYTio5N2mK6yH Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 14:14 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, плохо. падает прозрачность языка в целом это негативно сказывается на производительности да и на понимаемости. см топик и 21223495 =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 14:26 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Siemarglв целом это негативно сказывается на производительности А можно по конкретней, как small string optimization плохо сказывается на производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 14:30 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася УткинSiemarglв целом это негативно сказывается на производительности А можно по конкретней, как small string optimization плохо сказывается на производительности? вот же и пример - сортировать "в лоб" нельзя, копирование будет медленнее (особенно массивов строк) но я имел в виду больше - сокрытие деталей "под капотом" мешает пониманию - что же на самом деле происходит, ну и конечно как писать оптимальный код, если непонятны накладные расходы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 17:05 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
SiemarglВася Уткинпропущено... А можно по конкретней, как small string optimization плохо сказывается на производительности? вот же и пример - сортировать "в лоб" нельзя, копирование будет медленнее (особенно массивов строк) но я имел в виду больше - сокрытие деталей "под капотом" мешает пониманию - что же на самом деле происходит, ну и конечно как писать оптимальный код, если непонятны накладные расходы Насчет понимания кода под копотом - согласен. Я понимал, что дело в memcpy() вместо operator=(), т.е. qsort не предназначен для C++-struct/class, но сначала подумал на деструктор временной переменной используемой для обмена местами двух элементов, а присмотревшись понял, что дело в small string optimization, а не в деструкторе. А почему сортировка будет медленней? На GCC 4.9.2 (без smo) std::string занимает 8 байт, а на GCC 5.1.0 (с smo) std::string занимает 32 байта. Но CPU читает данные из памяти сразу кэш-линиями по 64 байта: - В gcc 4.9.2 всегда надо прочитать как минимум 2 кэш-линии и автоматический префетч кэша не поможет, т.к. каждый динамически аллоцируемый участок не расположен строго один за другим. - А в gcc 5.1.0 во многих случаях достаточно прочитать 1 кэш линию и плюс автоматический префетч загрузит все ближайшие элементы массива в кэш, т.к. они расположены последовательно. И ладно, допустим, что smo - это шляпа. Но правильно ли использовать qsort() для C++-struct/class? Самое главное - в каждой конкретной задаче разработчик может захотеть сделать свои оптимизации в конструкторе и operator(), которые в его задаче точно нужны, и использование qsort() сломает код, а std::sort() не сломает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 18:59 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася УткинВопрос, что надо передать в qsort: результат функции begin() или data()? С совсем формальной точки зрения - array<>::data(). Но учитывая что речь идет про array<>, а его итерторы это простые указатели. Так что в данном конкретном случае begin() и data() фактически одно и то-же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 19:03 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Читал топик, ломал голову что могло сглючить из-за memcpy() Придумал один вариант и он подтвердился Вася Уткин Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2018, 19:48 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
White OwlВася УткинВопрос, что надо передать в qsort: результат функции begin() или data()? С совсем формальной точки зрения - array<>::data(). Но учитывая что речь идет про array<>, а его итерторы это простые указатели. Так что в данном конкретном случае begin() и data() фактически одно и то-же. Фактически это: auto it = arr.begin(); Record *ptr = *reinterpret_cast<Record **>(&it); Пока что да - указатель, но когда то и std::string был просто указателем на данные ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2018, 02:24 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася УткинПри использовании в C++, функция qsort по много раз уничтожает объект (вызывает деструктор у Record и у std::string) и копирует указатель на освобожденную память, поэтому ваш код просто будет падать с Seg Fault. Потому что для классов из C++ (struct вызывающих деструктор) надо использовать std::sort из C++, а не qsort-из C. Код: plaintext 1. 2. 3. 4. 5. 6. Ничего не должно тут падать. Но падает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2018, 09:29 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
White Owl, А вот нафига же тебе там void* ? Когда ну всё уже сделано в С++ чтобы все указатели были типизированы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2018, 09:30 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
MasterZivWhite Owl, А вот нафига же тебе там void* ? Когда ну всё уже сделано в С++ чтобы все указатели были типизированы.Мне??? Это вообще-то требование библиотечной функции std::qsort() . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2018, 19:10 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Dima TЧитал топик, ломал голову что могло сглючить из-за memcpy() Придумал один вариант и он подтвердился Вася Уткин Код: plaintext 1. 2. 3. 4. 5. Я когда то очень давно в эпоху беззаботной юности и большого количества свободного времени , игрался в велосипедостроение на эту тему, что бы съкономить на вызовах выделения памяти для коротких строк. Там должен быть union в типизационной обертке char* operator() или const char* operator() если нужно передавать в функцию требующую void* то конечно же тип нужно явыным образом привести под неявный вызов operator(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2018, 21:43 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
White OwlНе, я конечно давно знаю что если хочешь сортировать объекты с переменной длинной, то сортируй указатели на них. Но.... разве класс string не является сам по себе указателем на данные? Да даже если оно хранит данные напрямую в структуре и Record.s на самом деле переменной длины, почему тогда значение целого не портится? Пару раз прочитал, не очень понятно. Почему при сортировке с использованием стандартных функций С и С++ мы можем ожидать в качестве побочного эффекта изменение сортируемых объектов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2018, 23:49 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
SashaMercuryWhite OwlНе, я конечно давно знаю что если хочешь сортировать объекты с переменной длинной, то сортируй указатели на них. Но.... разве класс string не является сам по себе указателем на данные? Да даже если оно хранит данные напрямую в структуре и Record.s на самом деле переменной длины, почему тогда значение целого не портится? Пару раз прочитал, не очень понятно. Почему при сортировке с использованием стандартных функций С и С++ мы можем ожидать в качестве побочного эффекта изменение сортируемых объектов? Ах да, надо бы разъяснить. Строка переместилась, но она содержала указатель на себя, который остался указывать на старое место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 00:17 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
SashaMercuryWhite OwlНе, я конечно давно знаю что если хочешь сортировать объекты с переменной длинной, то сортируй указатели на них. Но.... разве класс string не является сам по себе указателем на данные? Да даже если оно хранит данные напрямую в структуре и Record.s на самом деле переменной длины, почему тогда значение целого не портится? Пару раз прочитал, не очень понятно. Почему при сортировке с использованием стандартных функций С и С++ мы можем ожидать в качестве побочного эффекта изменение сортируемых объектов? Так написано же: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 07:53 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
SashaMercuryПару раз прочитал, не очень понятно. Почему при сортировке с использованием стандартных функций С и С++ мы можем ожидать в качестве побочного эффекта изменение сортируемых объектов? Наоборот: объекты не меняются, но должны, т.к. внутри string буфер и указатель на этот буфер. Выше пример кода который сглючит 21224926 и 21226275 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 08:31 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Dima TSashaMercuryПару раз прочитал, не очень понятно. Почему при сортировке с использованием стандартных функций С и С++ мы можем ожидать в качестве побочного эффекта изменение сортируемых объектов? Наоборот: объекты не меняются, но должны, т.к. внутри string буфер и указатель на этот буфер. Выше пример кода который сглючит 21224926 и 21226275 Ничего там ломаться не должно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 12:14 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
д0kХ Код: plaintext 1. 2. 3. 4. 5. 6. Так ИМХО будет оптимальнее, если стековую строку дефайнить на не менее чем на 2 машинных слова. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Не проверял . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 15:26 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
д0kХ, if (или switch) могут влиять на процессорные оптимизации, поэтому указатель желательно хранить уже вычисленным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:22 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Если уж делать позиционно независимые строки, то вместо указателя можно хранить смещение к нему относительно this ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:25 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyЕсли уж делать позиционно независимые строки, то вместо указателя можно хранить смещение к нему относительно this Вот меня удивляет, почему в gcc так не сделали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:40 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
д0kХНичего там ломаться не должно: Код: plaintext 1. 2. 3. 4. 5. 6. Да, так не сломается, но так работает быстрее Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:43 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyЕсли уж делать позиционно независимые строки, то вместо указателя можно хранить смещение к нему относительно this Не поможет, т.к. для больших строк выделение памяти через malloc(), т.е. за пределами объекта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:46 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Dima TНе поможет, т.к. для больших строк выделение памяти через malloc(), т.е. за пределами объекта. Так смещение тоже может указывать за пределы объекта ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:57 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася УткинВот меня удивляет, почему в gcc так не сделали. Потому что такие строки все равно никому не нужны. Как выше написали все равно такое использование строк - UB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 16:59 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyд0kХ, if (или switch) могут влиять на процессорные оптимизации, поэтому указатель желательно хранить уже вычисленным. Он вычислен начало массива лежащего в стеке, преобразуется в указатель на строку через ссылку на нулевой элемент. либо из самого массива берется указатель. В зависимости от длины строки возвращается либо то либо другое. Что бы не хранить размер ( сэкономить sizeof(int) на каждом элементе массива строк в последенм примере в последнем байте массива строки фиксированной длины хранится либо 0х00 как в последеднем байте любой строки. либо 0хFF если первое слово в массие является указателем на строку. Если не то и не другое , значит кто то покоцал память . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 17:11 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Dima Tд0kХНичего там ломаться не должно: Код: plaintext 1. 2. 3. 4. 5. 6. Да, так не сломается, но так работает быстрее Код: plaintext 1. 2. 3. 4. Быстрее оно до тех пор, пока вы не присумируете туда время 100500 вызовов new и delete для строк меньше 16 байт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 17:18 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
д0kХAnatoly Moskovskyд0kХ, if (или switch) могут влиять на процессорные оптимизации, поэтому указатель желательно хранить уже вычисленным. Он вычислен . if/switch - это и есть вычисления для предсказателя переходов, причем с учетом ошибок предсказания - это статистически очень долгие операции. Весь вопрос в том, где лучше оставить if/switch: - либо в operator char*() , как у вас - либо в operator=(), как я приводил пример и как видимо у gcc 5.1 (раз у них ломается) Что реже вызывается, там и надо оставлять. Видимо в GCC посчитали, что объект меняется реже, чем читается (или меняются только отдельные ячейки строки). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 17:26 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася УткинВесь вопрос в том, где лучше оставить if/switch: - либо в operator char*() , как у вас - либо в operator=(), как я приводил пример и как видимо у gcc 5.1 (раз у них ломается) Что реже вызывается, там и надо оставлять. Видимо в GCC посчитали, что объект меняется реже, чем читается (или меняются только отдельные ячейки строки). В присвоении по любому этот if есть )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 17:43 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася Уткинд0kХпропущено... Он вычислен . if/switch - это и есть вычисления для предсказателя переходов, причем с учетом ошибок предсказания - это статистически очень долгие операции. Весь вопрос в том, где лучше оставить if/switch: - либо в operator char*() , как у вас - либо в operator=(), как я приводил пример и как видимо у gcc 5.1 (раз у них ломается) Что реже вызывается, там и надо оставлять. Видимо в GCC посчитали, что объект меняется реже, чем читается (или меняются только отдельные ячейки строки). Вычислен это как минумум одно лишнее машинное слово в классе. И это где то 50 % размера строки. Сейчас оперативную память наверное никто не считает. Но мне очень кажется, что десяток тактов процессра дешевле одного машинного слова метаданных в ОЗУ . ВСЕ ИМХО Как думают создатели GCC мне не ведомо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 17:53 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
В случае со switch и расчетом на лету в кеше процессора поместится гораздо больше элементов массива строк. чем с предрасчитанным и хранящимся в отдельном поле класса указателем. по хорошему тестить надо. В топик вызывается Майтон :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 18:14 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
д0kХВася Уткинпропущено... if/switch - это и есть вычисления для предсказателя переходов, причем с учетом ошибок предсказания - это статистически очень долгие операции. Весь вопрос в том, где лучше оставить if/switch: - либо в operator char*() , как у вас - либо в operator=(), как я приводил пример и как видимо у gcc 5.1 (раз у них ломается) Что реже вызывается, там и надо оставлять. Видимо в GCC посчитали, что объект меняется реже, чем читается (или меняются только отдельные ячейки строки). Вычислен это как минумум одно лишнее машинное слово в классе. И это где то 50 % размера строки. Сейчас оперативную память наверное никто не считает. Но мне очень кажется, что десяток тактов процессра дешевле одного машинного слова метаданных в ОЗУ . ВСЕ ИМХО Как думают создатели GCC мне не ведомо. Чем новее процессор, тем в нем больше суперскалярных ALU-ports, и тем больше ALU будут простаивать при ошибке предсказания перехода. А кэш и память увеличиваются (за исключением L1), так что в перспективе думаю выгоднее больше памяти затратить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 18:15 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Вася Уткинд0kХпропущено... Вычислен это как минумум одно лишнее машинное слово в классе. И это где то 50 % размера строки. Сейчас оперативную память наверное никто не считает. Но мне очень кажется, что десяток тактов процессра дешевле одного машинного слова метаданных в ОЗУ . ВСЕ ИМХО Как думают создатели GCC мне не ведомо. Чем новее процессор, тем в нем больше суперскалярных ALU-ports, и тем больше ALU будут простаивать при ошибке предсказания перехода. А кэш и память увеличиваются (за исключением L1), так что в перспективе думаю выгоднее больше памяти затратить. Понятное дело . Я лет 15-20 назад, когда это писал решал конкретную практическую задачу минимизации вызовов аллокации - деаллокации памяти для коротких строк. но некоторый небольшой % строк в массивах могли быть длинными. Если у автора топика есть разумное ограничение на длину строки, то задача решится достаоточно просто, без забивания саморезов микроскопом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2018, 18:34 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Siemarglнет там грязных хаков. Да. Есть всего лишь UB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2018, 13:11 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Ну вот Вася. А я вить предупреждал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2018, 13:29 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
maytonНу вот Вася. А я вить предупреждал. Скоро у меня будет целая секта с блекджеком и последователями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2018, 13:44 |
|
||
|
sizeof( strcuct {string} )?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyЕсли уж делать позиционно независимые строки, то вместо указателя можно хранить смещение к нему относительно this Это уже база данных. Там в блоке данных, хранящемся на диске записи хранятся как попало и пракитчески любой длины и в любом количестве . Но в блоке есть массив смещений записей от начала блока. Глобально запись адресуется номером ( смещением) блока от начала датафайла и индексом массиве блока. Эта сущьсность в БД называется rowid . Зная rowid любую запись можно достать с диска за одну операцию чтения 2-е коственных адресации . по этому принципу прострен индексный поиск в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2018, 22:06 |
|
||
|
|

start [/forum/topic.php?all=1&fid=57&tid=2017950]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 168ms |

| 0 / 0 |
