Баг компилятора при параметре шаблона = void* - страница 13
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пока что сделал только автоматическую прокрутку лога по окончании компиляции на начало первой ошибки (если таковая имеется). Без этого приходилось постоянно вручную крутить список (а он немаленький), выискивая сообщение об ошибке. Тот ещё гемор.
А там же есть Автопрокрутка (по правой кнопке мыши) - убрать галочку
Ilya Malev:
А если говорить о более приземленных задачах - то это число указывает на число созданных в системе объектов и полезно для отладки в любой архитектуре, основанной на динамических списках. Не удивительно, что я не первый, кто додумался как "обмануть" запрет на его получение, и мне даже подсказали более быстрый способ, правда только для 4-ки.
Ну так я всегда утверждал, что явное преобразование указателя в long полезно. А Разработчики не поняли пользы и убрали его. У меня немного другой способ - не буду писать какой, а то и его закроют
Напишите мне в ЛС или на мыло, если Вас не сильно затруднит, сам навязываться на буду. Мне реально это интересно, на форуме не буду показывать.
П.С. хотя если через включение длл то не надо, т.к. минусов у такого решения больше чем плюсов
П.С.С. Если подумать, то лазейку с PrintFormat и StringConcatenate разрабы оставили сознательно, иначе сложно предположить зачем оставили. Не могли не видеть, что оставляют ведь. Значит не было цели перекрыть все методы, и можно не волноваться об этом.
В конце концов это всего лишь число. Возможность его выяснения не создает никакой угрозы безопасности и целостности данных, потому что ни изменить его, ни использовать каким-то "специальным" способом после получения все равно невозможно, и оно даже не является ссылкой на область памяти, а простым стековым счетчиком. Закрывали, по всей видимости, не это число, а второй int конкретно, который вполне мог уже указывать на реальную область памяти и т.п. Но нам как раз для всех озвученных целей он и не нужен.А там же есть Автопрокрутка (по правой кнопке мыши) - убрать галочку
Хм, действительно, теперь работает правильно. Просто я делал ещё под старые билды, там оно работало криво, проматывалась не на самую первую ошибку, а куда-то в середину. Долго терпел, но потом нервы не выдержали ) Оказывается, можно было ещё потерпеть - и не пришлось бы изобретать велосипед )
За это медаль давать нужно. У меня нервы не выдержали уже в конце первой недели, в конце второй нашёл нужную кнопку
За это медаль давать нужно. У меня нервы не выдержали уже в конце первой недели, в конце второй нашёл нужную кнопку
Так раньше было всё в порядке. Сейчас специально проверил на разных билдах, данный баг начался с 1550 билда, и продолжался на протяжении многих билдов. Никакая кнопка вам не могла помочь там )
А если говорить о более приземленных задачах - то это число указывает на число созданных в системе объектов и полезно для отладки в любой архитектуре, основанной на динамических списках. Не удивительно, что я не первый, кто додумался как "обмануть" запрет на его получение, и мне даже подсказали более быстрый способ, правда только для 4-ки.
для меня сейчас приземленная задача это хочу форму с VS в .dll прикрутить к МТ5 изящным способом ))) - хочу обработчики кликов кнопок обернуть в класс и вызывать путем обхода массива указателей на функции обработчиков, причем хочу получить в основном коде советника возможность писать имена ф-ций один в один как в VS , т.е. button2_Click() ....button2_Click()
ЗЫ :задача из области ЕОП )))
по сабжу, последние 3 страницы обсуждаем целесообразность ставить много скобок или нет, имхо, на производительность скомпилированного кода наличие большого количества скобок не влияет, но программист четко определяет последовательность расчетов арифметического/логического выражения, которое в дальнейшем при обновлениях МТ не изменится, как и не изменится при портировании кода на другие языки программирования - т.е. если не лень и очень ответственно относимся к конечному результату, ставим много )))
по сабжу, последние 3 страницы обсуждаем целесообразность ставить много скобок или нет, имхо, на производительность скомпилированного кода наличие большого количества скобок не влияет, но программист четко определяет последовательность расчетов арифметического/логического выражения, которое в дальнейшем при обновлениях МТ не изменится, как и не изменится при портировании кода на другие языки программирования - т.е. если не лень и очень ответственно относимся к конечному результату, ставим много )))
А почему Вы их тогда сами не ставите? Не поленился посмотрел у Вас в профиле:
а должно быть так:
Декларируете одно, а сами делаете - ровно наоборот.
Если даже адепты скобок сами их не ставят - то это лучшее подтверждение их ненужности