Ошибки, баги, вопросы - страница 2830

A100:
Ошибка при компиляции

а так:

нормально. А какая разница?

Потому, что в первом случае f переопределена до вызова f(int), а во втором после

class A {
        int f( int ) { return 0; }
        void g() { int f = f( 1 ); int x=f(1);} //(1) Error: '1' - some operator expecte
};
Renat Fatkhullin:
Меню отсортировали по частоте использования.

Через месяц все привыкнут.

по феньшуй в середину тогда уж самые частые) .... конечно привыкнут)

Vladimir Simakov:

Потому, что в первом случае f переопределена до вызова f(int), а во втором после

Вы опять не в теме - разницы нет никакой. В обоих случаях: или ошибки не должно быть - или должна быть (как в C++). Вот пример (3), когда f переопределена после, как и в случае (2), однако в отличии от (2) - ошибка при компиляции

class B {
public:
        B( int ) {}
};
class A {
        int f( int ) { return 0; }
        void g()    { B f(f( 1 )); } //(3) Error: '1' - some operator expected
};
A100:

Вы опять не в теме - разницы нет никакой. В обоих случаях: или ошибки не должно быть - или должна быть (как в C++). Вот пример (3), когда f переопределена после, как и в случае (2), однако в отличии от (2) - ошибка при компиляции

извиняюсь, не ваш уровень. но более строгая и не разумная инкапсуляция на мой взгляд. не си  и не питон.

Объединим все в одном примере:
class B {
public:
        B( int ) {}
};
class A {
        int f( int ) { return 0; }
        void g1()    { B f = f( 1 );  } //(1) нормально
        void g2()    { B f(  f( 1 )); } //(2) Error: '1' - some operator expected
};
Теперь вообще ВСЕ одинаково, а вопрос тот же: Какая разница между (1) и (2) ?
[Удален]
A100:
Объединим все в одном примере: Теперь вообще ВСЕ одинаково, а вопрос тот же: Какая разница между (1) и (2) ?

Я вооще не понимаю о чём вы говорите, но разница ОЧЕВИДНАЯ ))) Присваивание -> аргумент. Может я и не прав )))

Сергей Таболин:

Я вооще не понимаю о чём вы говорите, но разница ОЧЕВИДНАЯ ))) Присваивание -> аргумент. Может я и не прав )))

Если для Вас разница очевидна, то объясните почему в одном случае ошибка при компиляции, а в другом - нет. Или Вы разницу только по внешнему виду можете определить, а не по смыслу!? Тогда это уровень журнала Мурзилка - "найдите 10 отличий"

[Удален]
A100:

Если для Вас разница очевидна, то объясните почему в одном случае ошибка при компиляции, а в другом - нет. Или Вы разницу только по внешнему виду можете определить, а не по смыслу!? Тогда это уровень журнала Мурзилка - "найдите 10 отличий"

Именно так )))))))

И можно ещё один вопрос от профана? Зачем вот всё это нужно? В чём сакраментальный смысл? Вот Вы специально выискиваете такие "баги"? Или без какой-то из этих конструкций - вся жизнь насмарку?

Сергей Таболин:

И можно ещё один вопрос от профана? Зачем вот всё это нужно? В чём сакраментальный смысл? Вот Вы специально выискиваете такие "баги"? Или без какой-то из этих конструкций - вся жизнь насмарку?

За такие вопросы (в этой ветке) пора бы уже банить

Раз уж тут про ошибки. Есть какое-то решение на тему DLL и ручной остановки тестера?

В смысле, если тестер/оптимизацию остановить в процессе, то чтоб по-новой, приходится убивать ручками metatester64 (а в случае фермы - там  дополнительная порция ада), потому что процесс оставляет  DLL загруженной, а для запуска нового теста он в сэндбокс копирует DLL по-новой, но, очевидно, винда не дает перезаписать открытую DLL и ошибка записи.

Ну и если тут разработчики пробегают, отчего бы не добавить в код тестера 4 линии, чтобы он попытался handle библиотеки получить,  и если она загружена - выгрузить, прежде чем копировать по-новой? Бардак же ;)