Алгоритмы, методы решений, сравнение их производительности - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Хочу заметить что в отличии от всех кто здесь у Петра скорее всего самое огромное терпение - и готовность к монотонному коду. По другому я не могу объяснить как ему удалось написать столько всего
Склонностью к монотонному коду это «индийский» стиль?
Или что имелось ввиду?
)
У меня только один вопрос, а почему не применять массив int или еще лучше не воспользоваться листингом, если этих магиков будет достаточно много ?
Зачем для этого использовать строку ? чтобы Можно было ввести еще и буквы ? а можно еще считать в 16-тиричной системе! а еще круче - сразу перейти на 128 ричную..
Склонностью к монотонному коду это «индийский» стиль?
Или что имелось ввиду?
)
В точку!!! не хотел говорить сам
Склонностью к монотонному коду это «индийский» стиль?
Или что имелось ввиду?
)
Русский стиль с бесконечным стремлением все переписать тоже не особой айс - особенно в больших проектах
Там есть только два варианта у стринга либо он изначально имеет максимальны размер (в запасе), либо также память выделяеться и в вашем случаее при процессе сложение она выделяеться каждый раз.... Т.е .тоже самое что и изменение размера массива у инта. 1в1 ну возможно что инт выделяет память дольше на 10% чем стринга выделяет память на 1 символ, при сравнении большего количества символов - полагаю победа за интом
Интересно было бы проверить ваше утверждение на практике. Если постоянное изменение размера массива int с переписыванием данных туда-сюда будет также быстро как и в работе со строкой, то я конечно предпочту int.
Но сильно сомневаюсь, что скорость будет такой же. Интуиция.
Интересно было бы проверить ваше утверждение на практике. Если постоянное изменение размера массива int с переписыванием данных туда-сюда будет также быстро как и в работе со строкой, то я конечно предпочту int.
ну проверяйте - код там простой.... также советую код ставить в цикл с повтором в 100 000 раз, так более наглядно будет и меньше будем зависить о посторонних факторов.
Я думал изначально эта тмеа и будет повещена подобным сравнениям
Хочу заметить что в отличии от всех кто здесь у Петра скорее всего самое огромное терпение - и готовность к монотонному коду. По другому я не могу объяснить как ему удалось написать столько всего
В точку!!! не хотел говорить сам
Опять прав fxsaber - невидимость постов и тем персонажей из своего «Черного списка» для каждого пользователя на этом форуме уже необходимость. для сохранения здорового социума. И индивида...
Иначе как глумление над профессией эта ветка не воспринимается.
(
Смелое утверждение, чем-то можете подтвердить?
Ок, Петр разрабатывает ГУИ - в написании ГУИ как ни где помогает ООП упростить и облегчить код. Однако мы пишем без этого - и вот тут такой способ быстрым никак не назавешь однако усердность берет свое и воля мы видем некий ГУИ) .... конечно я тут не сравниваю тех людей у которых по 30к строк жесткого ООП с задефанеными макросами классов в стиле #define micrcalss(CALSS, PARENTS) class CLASS : public PARENTS ......