Определить количество максимальных элементов в массиве.

Дан одномерный массив. Определить количество максимальных элементов в массиве.

0

Сообщение от easybudda Я-то думал, что если t <= max, то чему там count равно уже не проверяется... Или ещё какой-то тонкости не улавливаю?

Выражения в условных операторах вычисляются слева направо. При этом не обязательно вычисляется все выражение целиком.
В случае выражения expr1 && expr2 && ... && exprn, вычисление закончится "преждевременно" если одно из подвыражений окажется ложным, а следственно и все выражение целиком.
В случае выражения expr1 || expr2 || ... || exprn, вычисление закончится "преждевременно" если одно из подвыражений окажется истинным, а следственно и все выражение целиком.

У тела первого условного оператора в коде alex_x_x'a при первом вызове оператора() нет шансов не выполнится.

Сообщение от easybudda А чем, кстати, по умолчанию поля типа int в классе инициализируются?

Если они явно не были инициализированы, то чем повезет . Это относится ко всем примитивным типам.

1

Сообщение от easybudda А чем, кстати, по умолчанию поля типа int в классе инициализируются?

Если в списке инициализации их нет, то они вообще не инициализируются. В отличие от объектов.

Добавлено через 55 секунд

0

Сообщение от easybudda Странно, но работает. Я-то думал, что если t <= max, то чему там count равно уже не проверяется... Или ещё какой-то тонкости не улавливаю? Вот кстати ещё одно очень простое любительское решение C++ 1 2 3 4 5 6 7 8 9 10 11 #include <iostream> #include <algorithm>   int main(){     const int size(10);     int arr[size] = { 1, 3, 5, 3, 2, 5, 4, 3, 1, 2 };     int me = *std::max_element(arr, arr + size);     std::cout << "Max element: " << me << " meets " << std::count(arr, arr + size, me) << " times" << std::endl;         return 0; } Может тоже было, но на вскидку не нашёл в этой теме. Вот ей-богу надоело уже! Оставьте при себе своё мнение о профессионализме участников форума, а то ведь в правилах есть пункт "неуважительное отношение". С совсем небольшой натяжкой вполне применим. Надо оно Вам? Добавлено через 4 минуты А чем, кстати, по умолчанию поля типа int в классе инициализируются? Случайно не INT_MIN (ну или как там в С++ правильно минимальное значение обозначается)? А то есть подозрение, что минимальный элемент вот как-раз из-за этого нюанса и не найдётся, и не посчитается...

Вы берете примитивные ситуации и радуетесь, что работает. Я вас разочарую! Представьте себе, что у вас объект класса содержит указатель на char. А при сравнении элементов используется стандартная функция strcmpТогда использование перегруженного оператора сравнения может привести к непредсказуемым последствием.
Вы мне заявите, что пользователь при определении конструктора по умолчанию должен был инициализировать этот указатель значением NULL. Но что изменится? Произойдет аварийное завершение функции, так как будет обращение к нулевому адресу!
Вы мне снова можете возразить, что пусть пользователь об этом сам позаботится в реализации оператора <. Хорошо. Пользователь позаботился и включил в реализацию этого оператора исключение.

bool operator < ( const T &, const T & ) throw( std::exception );

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

То есть на сампом деле имеет место, что, образно говоря, вы за его спиной, то есть без его санкции используете объекты, которые пользователь не хотел бы чтобы они использовались.

Другой пример. Я встречал его в бухгалтерии. Там можно было создавать документ с пустыми полями. То есть ни дата, ни номер документа будут неизвестны, пока бухгалтер не заполнит поля документа и не сохранит его в базе. Однако если каким-то случайным образом в базе данных обнаруживался пустой документ, то система его регистрировала в журнале ошибок. То есть при каждой операции, если, вдруг, обнаруживался пустой документ, сразу же регистрировалась такая ситуация, так как этого не должно было быть, потому что этого, как говорят, не могло быть.
Теперь представим использование вашего алгоритма. Выполняется сравнение, и система обнаруживает, что откуда-то появился пустой документ, например, пустая накладная. Система заносит об этом в свой жернал регистрации соответсвующее сообщение, чтобы пользователи потом разобрались, что произошло. И так каждый раз, когда вы будете вызывать этот алгоритм, журнал регистрации будет пополняться сообщениями об ошибке! Мало того, что это может привести к переполнению жернала регистрации ошибок, пользователи вообще могут не понять, из-за чего это сообщение беретсая. А берется оно из-за того, что алгоритм самовольно начинает сравнивать не инициализированный объект с уже имеющимся!

Это вообще плохой дизайн, когда программа делает то, о чем ее не просит пользователь! То есть, как в данном алгоритме, начинает сравнивать не инициализированные объекты.

Добавлено через 1 минуту

Сообщение от CyBOSSeR Выражения в условных операторах вычисляются слева направо. При этом не обязательно вычисляется все выражение целиком. В случае выражения expr1 && expr2 && ... && exprn, вычисление закончится "преждевременно" если одно из подвыражений окажется ложным, а следственно и все выражение целиком. В случае выражения expr1 || expr2 || ... || exprn, вычисление закончится "преждевременно" если одно из подвыражений окажется истинным, а следственно и все выражение целиком. У тела первого условного оператора в коде alex_x_x'a при первом вызове оператора() нет шансов не выполнится. Если они явно не были инициализированы, то чем повезет . Это относится ко всем примитивным типам.

Проблема в том, что вы забываете, что эти операторы могут быть перегружены! По крайней мере стандарт этого не запрещает!

0

Сообщение от Сыроежка Вы берете примитивные ситуации и радуетесь, что работает. Я вас разочарую! Представьте себе, что у вас объект класса содержит указатель на char. А при сравнении элементов используется стандартная функция strcmpТогда использование перегруженного оператора сравнения может привести к непредсказуемым последствием. Вы мне заявите, что пользователь при определении конструктора по умолчанию должен был инициализировать этот указатель значением NULL. Но что изменится? Произойдет аварийное завершение функции, так как будет обращение к нулевому адресу! Вы мне снова можете возразить, что пусть пользователь об этом сам позаботится в реализации оператора <. Хорошо. Пользователь позаботился и включил в реализацию этого оператора исключение. bool operator < ( const T &, const T & ) throw( std::exception ); Вполне грамотный код. Если его объект содержит какие-то не инициализированные данные, то произойдет исключение. Итак, он запускает алгоритм и получает исключение! "Откуда?!!!", - удивится пользователь. Ведь он на вход давал вполне корректные данные. То есть на сампом деле имеет место, что, образно говоря, вы за его спиной, то есть без его санкции используете объекты, которые пользователь не хотел бы чтобы они использовались. Другой пример. Я встречал его в бухгалтерии. Там можно было создавать документ с пустыми полями. То есть ни дата, ни номер документа будут неизвестны, пока бухгалтер не заполнит поля документа и не сохранит его в базе. Однако если каким-то случайным образом в базе данных обнаруживался пустой документ, то система его регистрировала в журнале ошибок. То есть при каждой операции, если, вдруг, обнаруживался пустой документ, сразу же регистрировалась такая ситуация, так как этого не должно было быть, потому что этого, как говорят, не могло быть. Теперь представим использование вашего алгоритма. Выполняется сравнение, и система обнаруживает, что откуда-то появился пустой документ, например, пустая накладная. Система заносит об этом в свой жернал регистрации соответсвующее сообщение, чтобы пользователи потом разобрались, что произошло. И так каждый раз, когда вы будете вызывать этот алгоритм, журнал регистрации будет пополняться сообщениями об ошибке! Мало того, что это может привести к переполнению жернала регистрации ошибок, пользователи вообще могут не понять, из-за чего это сообщение беретсая. А берется оно из-за того, что алгоритм самовольно начинает сравнивать не инициализированный объект с уже имеющимся! Это вообще плохой дизайн, когда программа делает то, о чем ее не просит пользователь! То есть, как в данном алгоритме, начинает сравнивать не инициализированные объекты.

Много букв и все не по делу. Как это относится к сказанному easybudda? О чем Вы вообще?

Сообщение от Сыроежка Проблема в том, что вы забываете, что эти операторы могут быть перегружены! По крайней мере стандарт этого не запрещает!

Приведите пример когда перегрузка оператора || приведет к тому что тело условного оператора не выполнится:
Вот только исключениями бросаться не надо.

Сообщение от Сыроежка bool operator < ( const T &, const T & ) throw( std::exception );

Непустые спецификации исключений уже давно преданы анафеме, статья Герба Саттера по этому поводу.

0

Сообщение от CyBOSSeR Много букв и все не по делу. Как это относится к сказанному easybudda? О чем Вы вообще? Приведите пример когда перегрузка оператора || приведет к тому что тело условного оператора не выполнится: C++ 1 2 3 4 SomeType t; int count = 0; if (t > max || 0 == count)   std::cout << "it works!" << std::endl; Непустые спецификации исключений уже давно преданы анафеме, статья Герба Саттера по этому поводу.

Я не занимаюсь, как бы помягче сказать, неадекватными людьми ! Это вы не по адресу обратились. Если вы не поняли, о чем я написал, и на какой вопрос я ответил, это ваши проблемы.
Что касается перегрузки операторов, то вы и здесь не поняли, о чем идет речь! Речь идет о том, что когда вызывается перегруженный оператор, то условие того, что правое выражение не будет выполняться, о чем в том сообщении говорилось, не верно! Вызывается оператор-функция, и все ее аргументы будут вычисляться!

[текст удалён]

0

Сообщение от Сыроежка Если вы не поняли, о чем я написал, и на какой вопрос я ответил, это ваши проблемы.

Если Вы не в состоянии донести информацию до слушателя, то это исключительно Ваша проблема. Или Вы просто говорите, чтобы сказать?

Сообщение от Сыроежка Что касается перегрузки операторов, то вы и здесь не поняли, о чем идет речь! Речь идет о том, что когда вызывается перегруженный оператор, то условие того, что правое выражение не будет выполняться, о чем в том сообщении говорилось, не верно!

Тот факт, что переопределение логического оператора грубо говоря отменяет sequence point, а следственно и "ленивое" вычисление условного оператора, никакого отношения к вопросу на который был дан ответ не имеет.

Сыроежка, думаю, Вам ничего в этой жизни как разработчику не грозит. Вы не умеете говорить, не умеете слушать, Вы игнорируете вопросы. Врядли адекватный человек будет работать в команде с такой надменной личностью как Вы. Самомнение аля "Я Дартаньян, все п**арасы" службу Вам не сослужит. Будьте проще.

3

Сыроежка, почти каждая тема с Вашим участием разрастается до 5+ страниц, и я Вас предупреждаю: это не раздел холивары. Я Вам предлагаю покинуть данную тему, пока не были применены санкции.

1

SSTREGG, простите, но так как тема перешла на личности, и возвращаться в лоно адекватного обсуждения, не смотря на увещевания администрации, не собирается - ЗАКРЫТО.

1

Да и санкции применены после многократных предупреждений.

0