1. C++ / Говнокод #11383

    +24

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    do
        {
    		count++;
    		Xt=X;
    		if (ii==1)
    		{
    			X= dichotomia(a,b, E);
    			fprintf(bnf, "%lf;\n", Xt);
    		}
    		else
    		{
    			if (ii==2)
    			{
    				X=newton(X, E);
    				fprintf(bnf, "%lf;\n", Xt);
    			} 
    			else
    			{
    				if (ii==3)
    				{
    					X=sekuschich(X, b);
    					fprintf(bnf, "%lf;\n", Xt);
    				}
    				else
    				{
    					if (ii==4)
    					{
    						ii==1;
    						ii==2;
    						ii==3;
    					}
    				}
    			}
    		}
    		printf("X=%lf\n", X);
    		if(Func(X)*Func(a)>0)a=X;
    		else b=X;
    	}
    	while(fabs(X-Xt)>=E);

    В общем лаба на численые методы поиска корней.
    После того как я предоставил няшный, полностью удовлетворяющий условиям, после проверки меня попросили "сделать как у парней", и вот участок их высера

    p.s. форматирование сохранить не удалось, да и там совсем бы ничего понятно бы не было

    Запостил: maksim_ovcharik, 09 Июля 2012

    Комментарии (185) RSS

    • > после проверки меня попросили "сделать как у парней"
      Печально. Вот так у нас и готовят будущие кадры...
      Ответить
      • это еще полбеды, к заданиям тз составлено очень грамотно и четко, но некоторые варианты функций которые даны для решения (их видимо уже подбирал преподаватель) не имеют корней в действительной части.

        и парни которые написали этот код очевидно даже не разбирались в сути методов и в тз, так как ошибок там очень много и их программа работает не правильно.
        Ответить
        • > не имеют корней в действительной части
          У нас тоже такая фигня была. Причем "5 курсов до тебя решали, все нормально было, а ты не можешь, иди переделывай". Но я препода тогда таки смог убедить, что косяк в задании...
          Ответить
          • >5 курсов до тебя решали
            Ох, как я Вас понимаю.
            Так и не доказал, но зачет все же получил.
            Ответить
            • Неделя тупых преподов на ГК?
              Ответить
            • При чем мой вариант не работал ни у кого, даже у тех кто сдал. Зато у меня работали все остальные варианты. Неделя глубокого дебага, потом две недели меня не слушали, а я слышал в ответ что такое первый раз и за 15 лет ничего такого не было.
              Ответить
              • в мапле/матлабе/etc решить уравнение/построить график и показать, что действительных корней нет?
                Ответить
                • Поиск корня на отрезке, где функция не меняет знак -- моветон.
                  Любой метод поиска действительного корня прежде всего требует локализовать знакопеременный отрезок.

                  График -- один из способов локализации.
                  Тем не менее, в существование лабыря, который даёт задачи со знакопостоянным отрезком, на котором ещё нужно что-то локализовывать -- не верю.
                  Ответить
                  • > Тем не менее, в существование лабыря, который даёт задачи со знакопостоянным отрезком, на котором ещё нужно что-то локализовывать -- не верю.
                    Это как вампиры - вы в них не верите, но они существуют.
                    Ответить
                    • Сосут лучше, чем пылесосы кирби, надеюсь?
                      Ответить
                    • > Это как вампиры - вы в них не верите, но они существуют.
                      видели?
                      Ответить
                • Кстати да, делал расчеты и в матлабе и в маткаде. Не помогло.
                  Только это не поиск корней уравнения был, а какой-то итерационный матан с дифурами, уже не помню.
                  Ответить
          • > сколько лет работаю, всегда студенты жёлтый аспирин получали, а вы мне белый принесли
            Ответить
    • секусчич
      ну и "где тут %username%, с++"?
      Ответить
      • "Он си-плюс-плюс не отличал от cи-диеза"
        Ответить
      • Если на минутку представить, что это хотя бы приблизительно работает, можно сделать вывод, что C++ спрятан в той части, которую нам не показали. Например, так:

        struct II
        {
        int ii_;

        II() {}
        II(int ii): ii_(ii) {}

        bool operator == (int n) const
        {
        if (ii_ < n)
        return false;

        if (n==1)
        {
        X= dichotomia(a,b, E);
        fprintf(bnf, "%lf;\n", Xt);
        }
        else if (n==2)
        {
        X=newton(X, E);
        fprintf(bnf, "%lf;\n", Xt);
        }
        else if (n==3)
        {
        X=sekuschich(X, b);
        fprintf(bnf, "%lf;\n", Xt);
        }

        return (ii_ < 4) && (ii_ == n);
        }
        } ii;

        std::cin >> ii.ii_;
        Ответить
        • мои глаза...
          Ответить
          • http://pastebin.com/j1i6hTNH

            Так лучше? :)
            Ответить
            • > лучше
              если это шутка, то неудачная
              Ответить
              • Ну а что? Должно работать. Если 1,2,3 - решаем одним способом. Если 4 - всеми тремя.

                Я, правда, не проверял, мне лень...
                Ответить
                • [ProblemFactoryMode=on]
                  RootFinder rootFinder = ProblemFactory.getFinderByIndex(ii);
                  Equation equation = Equation.compile(userInput);
                  Collection<EquationRoot> roots = rootFinder.findRoots(equation);
                  [/ProblemFactoryMode]
                  Ответить
                  • Я же пытался дописать имеющийся код до рабочего состояния, а не написать свой.
                    Ответить
                    • Потому и [ProblemFactoryMode], это решение не "как у парней".
                      Ответить
                      • Кстати, про "как у парней".
                        Возможно, лабырь не понимал программы, которую написал студент и попросил переписать её "вот в таком китайском виде".
                        Если бы это была задача именно на управление ресурсами на упрощение сопровождения и т.д., то написание "правильного и симпатичного кода" стояло бы на первом месте.
                        А если это конкретно задача для семинаров по выч.матам, то здесь и приоритет другой. И так же как до 16 лет права не выдают, даже если всё подросток может, так же и в университете до 4го курса не будут разрешать писать "как тебе удобно", а будут требовать "как удобно семинаристу".
                        Ответить
                        • но если убрать все отступы а потом рандомно поставить несколько штук (именно такой был первоначальный вид), то код будет абсолютно не понятен, думаю даже написавшему его человеку. А потом программа этого парня работала не верно, в корни не верно.
                          Ответить
                • > Ну а что?
                  ты правда думаешь, что логику стоит засовывать в bool operator == (int) const?
                  или это гипотетическое предположение, как этот класс пристроить к вышеуказанному коду? но они несовместимы
                  > Если 1,2,3 - решаем одним способом. Если 4 - всеми тремя
                  это можно описать гораздо более элегантным способом
                  например, массив функций, из которого вызовется либо i-я функция, либо в цикле пробежится по всем
                  Ответить
                  • > или это гипотетическое предположение,
                    > как этот класс пристроить к вышеуказанному коду?

                    Именно!

                    Ясен хрен, что это всё бред и можно проще и вменяемее. Но переписывать на работе чью-то лабу по-человечески мне неинтересно. Придумать, как заставить работать извращённый говнокод, не меняя его, а только добавляя свой вместо пропущенных участков - совсем другое дело. :)

                    А в чём именно я несовместимость проглядел, кстати?
                    Ответить
                    • if (ii==1)
                      {
                          X= dichotomia(a,b, E);

                      двойной вызов функции dichotomia
                      Ответить
                      • А вот и нет. Этот иф вернёт false. Как и все остальные за ним.
                        Ответить
                        • я просто оставлю это здесь
                          http://ideone.com/W6rNA
                          Ответить
                          • Согласен, очепятался. В строчке 52 надо вместо (ii_ < 4) написать (ii_ == 4).
                            Ответить
                    • > Придумать, как заставить работать извращённый говнокод

                      Мсье знает толк!
                      Ответить
                  • > ты правда думаешь, что логику стоит засовывать в bool operator == (int) const?
                    Решение нужно было засунуть в оператор double.
                    Equation eq(...);
                    double result = eq;
                    Ответить
                    • точняк
                      причем в зависимости от количества приведений к double выдавать 1..N корень:
                      double root1 = eq;
                      double root2 = eq;
                      if (eq > 3.)  // если третий корень больше 3.0
                          double root4 = eq;
                      Ответить
                      • охренеть, сопрограммы на операторе приведения типа... CC отдыхает.
                        Ответить
                        • Так всё зависит от того идёт это привидение типа или контракта.
                          Скажем, привидение типа указателя -- это было бы странновато, потому что все они на деле одинаковые только контракты разные и знать о контрактах может только система, которой мы заранее сообщаем.

                          А если это привидение объектов, то здесь может быть сколь угодно сложная логика.
                          Например приведение матрицы в число и числа в матрицу может быть весьма нетривиальным в зависимости о задачи.
                          Ответить
                          • >числа в матрицу
                            ......( 0 0 0 )
                            1 = ( 0 1 0 )
                            ......( 0 0 0 )
                            Ответить
                            • N -> N*E, где E - единичная матрица (то есть у которой на главной диагонали единицы).
                              Ответить
                              • Это как перегрузить оператор - (минус) для массивов.
                                Возникает неоднозначность - кто знает, какую туда логику автор засунул?
                                Ответить
                                • N*E - это первое, что приходит в голову любому, кто хоть как-то знаком с линейной алгеброй.
                                  Ответить
                            • На моей памяти три вида преобразования встречались:
                              число в матрицу и обратно по метрике,
                              число в матрицу и обратно как максимальное собственное число,
                              число в матрицу и обратно как определитель.

                              Строго говоря любое отображение -- это и есть преобразование типа, а отображение может быть очень сложным. С тем же уравнением. Если задача каким-то образом требует отображения, например, полиномов в "наибольший действительный корень", то это отображение логично разместить в операторе приведения уравнения к double или float.
                              Ответить
                              • очень логично ага
                                вместо метода с говорящим названием делать подло в операторе приведения к типу
                                Ответить
                                • Оператор привидения к типу более, чем говорящий: хочу из A в B.
                                  Что, простите, тут скрывает действие? Что может быть не ясно?
                                  Ответить
                                  • действительно, что может быть не ясно для человека, который видит, что объект предоставляет контракт "обработай меня как число" и потом не понимает, почему всё так медленно ворочается
                                    if (matrix > 1.)
                                    std::cout << "sqrt of matrix value " << (double)matrix << " is " << std::sqrt<double>(matrix) << std::endl;
                                    ведь на форуме сказали, что с++ быстрее дельфи, опять соврали!
                                    Ответить
                                    • Если человек не читает документацию к тому, чем пользуется, о нём и разговаривать нечего.
                                      Ответить
                                  • > число в матрицу и обратно по метрике,
                                    > число в матрицу и обратно как максимальное собственное число,
                                    > число в матрицу и обратно как определитель.

                                    > Что, простите, тут скрывает действие? Что может быть не ясно?

                                    вот и я о том же, за каким х в приведении типа скрывать какое то действие, чтобы обязательно было что то не ясно?
                                    для собственного числа и определителя для класса матрицы обязаны быть методы eigen_value и det, а не тайные приведения к double
                                    Ответить
                                    • За привидением типа скрывается... Привидение типа!
                                      Что не ясно?

                                      >обязаны быть методы eigen_value
                                      Вовсе не обязаны. Это существенно зависит от задачи.
                                      И вообще никто никому ничего не обязан, если на то нет хотя бы приличного императива.
                                      Ответить
                                      • Не ободряю interested
                                        Крестоблядство какое-то предлагает
                                        Ответить
                                        • > Крестоблядство какое-то предлагает
                                          Тарас, ты как нельзя прав...
                                          Ответить
                                      • Даже приведение double -> int - зло.
                                        Кто его знает что произойдёт?

                                        1. В-лоб - т.е. переносим биты без изменений.
                                        2. Округление в меньшую сторону.
                                        3. Округление в большую сторону.
                                        4. Округление до 0.
                                        5. Округление до ближайшего целого.

                                        Даже такое простое преобразование настолько многогранно, стоит ли злоупотреблять возможностью перегрузки и реализовывать в операторах приведения логику.

                                        Всё-таки если пишете myObject.toInt() то хотите в итоге получить числовое представление числа, а не что-то другое. Если числового представления нет или оно не однозначно - не нужно делать метод toInt().

                                        А операторы приведения типов это как раз аналоги методов toType().
                                        Ответить
                                        • > Даже приведение double -> int - зло.

                                          Я бы так сказал:
                                          > Неявное приведение даже double -> int - зло.

                                          Больше скажу, наоборот - тоже.

                                          Ответить
                                        • как это кто его знает?
                                          стандарт знает, никакого округления, только отсечение дробной части
                                          проблемы только если результат не способен хранить в себе в точности полученное обрезанное значение
                                          4.9 Floating-integral conversions
                                          1. An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type.
                                          Ответить
                                          • Дык стандарт стандартом, конечно.

                                            Я показал насколько неоднозначна ситуация с простым приведением.

                                            А человек тут хочет приведение из числа в матрицу сделать и обратно.

                                            Свой стандарт будет писать?
                                            Ответить
                                          • То есть, стандарт вы читаете, а доки к чужому коду нет? ;)
                                            Ответить
                                            • К каждой чужой строчке документ читать - хуй сломается.
                                              Ответить
                                              • Прочитай только то, что необходимо.
                                                Ну... или можешь в какую-нибудь менее интеллектуальную профессию перекинуться ;) Глядишь, всё на своих местах останется.
                                                Ответить
                                            • > стандарт и доки

                                              по моему, преобразование double -> integer очень интуитивно и даже не требует документации
                                              double boa_length, parrot_length;
                                              unsigned parrots_in_boa = boa_length/parrot_length;


                                              а преобразование матрица - не матрица обычно крайне неинтуитивно
                                              double jj = mm; // operator double here - eigen value of matrix mm!
                                              int kk = mm; // operator int here - column on minimax value of matrix mm!
                                              std::string ss = mm; // operator std::string here - string representation of 13-th row!
                                              math::vector vv = mm; // operator math::vector here - gets matrix diagonal

                                              теперь попробуйте вышеприведенный код с матрицами понять без комментариев
                                              Ответить
                                              • Я читаю документацию.
                                                Приучен с детства.
                                                Вопрос закрыт.
                                                Ответить
                                                • Не закрыт. Прикол в том, что такие вещи как приведение матрицы к числу нужно запихивать в метод с говорящим названием, т.е. делать т.н. самодокументирующийся код.

                                                  Писать доки, комментарии на 3 экрана к каждой функции только из-за желания перегрузить оператор?

                                                  Глупости.
                                                  Ответить
                                                  • Никакого секретного ингредиента нет
                                                    Код сам себя задокументировал: я привожу матрицу в число.
                                                    Вопрос закрыт.
                                                    Ответить
                                                    • Открываю вопрос обратно.
                                                      Представь, что я сделаю метод OpenQuestion, который на самом деле банит всех участников темы, и напишу в документации "этот метод банит всех участников темы". Чё, нормально?
                                                      Ответить
                                                      • Да ладно тебе, Тарас, оставь самородка в покое.
                                                        Ответить
                                                      • Тарас, у тебя в примере метод делает нечто, не соответствующее названию. А преобразование матрицы в число делает именно преобразование матрицы в число. В документации можно написать как именно это происходит.

                                                        Если у тебя есть класс PriorityQueue, то это ни о чём не говорит, кроме того, что это PriorityQueue. А с какой сложностью это выполнено, как это реализовано конкретно, нужно либо в исходный код лезть, либо читать доки.

                                                        >Открываю вопрос обратно.
                                                        Open failure.
                                                        Ответить
                                                        • Нет, он вычисляет дискриминант и возвращает его.
                                                          Ответить
                                                          • Тарас, ты уже заговариваешься.
                                                            Ответить
                                                            • Нет.
                                                              Называть вычисление детерминанта приведением к числу - это и есть заговариваться.
                                                              Ответить
                                                              • показать все, что скрытоТарас, даже если я пишу с очепятками, понять меня можно.
                                                                Я нигде не писал, что нужно располагать вычисление детерминанта в приведении к числу.
                                                                Ответить
                                                                • > нигде
                                                                  > число в матрицу и обратно как определитель.
                                                                  > логично разместить в операторе приведения
                                                                  http://govnokod.ru/11383#comment146305
                                                                  определитель != детерминант?
                                                                  Ответить
                                                                  • И?
                                                                    Здесь ничего не сказано о том, где следует размещать логику вычисления детерминанта.

                                                                    Не надо додумывать, надо читать, что написано. Не ясно -- задайте вопрос..
                                                                    Ответить
                                                                    • too boring
                                                                      Ответить
                                                                    • Да похер, это всё равно, что структуре Point приписать оператор приведения к числу, возвращающий сумму координат. Ну или произведение. Смотря какая фантазия у автора.
                                                                      Ответить
                                                                      • Ну в Питоне можно перегрузить взятие модуля от объекта (функция abs()).
                                                                        Если для точки (которая, как известно, вектор) определить эту перегрузку чтобы она возвращала евклидову длину вектора, то это тоже будет неправильно?
                                                                        Для справки: есть и перегрузки для приведения к int и float.
                                                                        Ответить
                                                                        • В этом есть логика, потому что в математике |a| означает и модуль числа, и длину вектора, и модуль комплексного числа (равный длине двумерного вектора его компонент).
                                                                          Ответить
                                                                    • INTERESTED ШРЁДИНГЕРА
                                                                      Ответить
                                                                      • Закрываю вопрос.
                                                                        Отрываю вопрос.
                                                                        Закрываю вопрос.
                                                                        ...
                                                                        Ответить
                                        • Когда я был студентом и впервые с этой кухней столкнулся, меня тоже мутило. Причём я тогда только познакомился с ООП, и мне было как-то совсем тошно и тяжело.

                                          Прошло время и я понял, что никакого секрета нет.
                                          Ответить
                              • > это отображение логично разместить в операторе приведения уравнения к double или float

                                За такую логику нужно гвоздь в голову забивать. Класс матрицы/уравнения не должен содержать в себе алгоритмов решения - алгоритмов обычно много и гораздо удобней отделять их от задачи, которую они призваны решить. Это позволить легко выбирать алгоритм в рантайме, например. А приведение к типу вместо явного вызова решаюшей процедуры - грязный хак, который могут придумать разве что самоуверенные студенты "по приколу", чтобы продемонстрировать самим себе, что они могут переопределять приведение типа в таком гибком и хардкорном C++.
                                Ответить
                                • Так, Вольт, это серьёзно
                                  Не надо приписывать мне то, чего я не говорил.

                                  Если вам требуется найти решение, то поиск решения передвигать в привидение типа действительно глупо. Но!
                                  Если вам нужно отображение, то это и есть приведение типа, получение из A -> B.
                                  Можно, конечно, применять "говорящие методы" .toString() .toInt() .toDouble() .toSomethingIHaveInMind().
                                  Однако, в C++ есть действительно удобное средство для таких операций.
                                  А вот, скажем, в Java нет. Пользуемся "говорящими методами".
                                  Ответить
                                  • >> определитель
                                    >> максимальное собственное число
                                    Нахождение этих величин - весьма нетривиальная задача, запихивать решение которой в класс матрицы - очень глупо.

                                    > любое отображение -- это и есть преобразование типа
                                    Отображение связано с преобразованием типа лишь косвенно. Можно легко найти примеры функций, на входе и на выходе которых один и тот же тип (id x = x).

                                    По сути любой алгоритм является отображением (функцией), поэтому не понятно, с какой стати вы проводите различие между поиском решения и отображением.
                                    Ответить
                                    • >с какой стати вы проводите различие между поиском решения и отображением.

                                      Привидение типа -- ясный контракт получения из A в B.
                                      Если вы хотите показать, что это контракт именно решения, а не отображения, пишите метод в алгебру.
                                      Согласен, что привидение типа специфическое отображение из алгебры в алгебру, и потому оно и может быть сложным, и потому для него используются специальные конструкции, поясняющие, что происходит.
                                      Ответить
                                      • > Привидение типа -- ясный контракт получения из A в B

                                        Нихера он не ясный. Даже способ приведения строки к числу отличается практически во всех динамических языках с нестрогой типизацией. А уж приведение матрицы к числу у меня, к примеру, вызывает когнитивный диссонанс.
                                        Ответить
                                        • Если не поняли в первом чтении, то они снова читают во втором.

                                          Контракт прозрачен: положи А, получи B.
                                          Положи 10р. --> получи билет.

                                          Если вам нужно узнать как же это происходит, то это другой вопрос. Читаем документацию. И, скорее всего, подобные вещи ясны из контекста самого кода. Если вы используете библиотеку, которая делает преобразования СТО, то, почти наверняка, преобразование из числа в матрицу -- это создание диагональной матрицы по метрике Минковского.
                                          Ответить
                                          • Про преобразование числа в матрицу всё понятно, да и не преобразование это вовсе, а просто конструирование матрицы с числом в качестве аргумента конструктора.

                                            А вот в обратную сторону неинтуитивная жопка получается.
                                            Ответить
                                            • > жопка
                                              ты это специально сказал, ведь, да?

                                              матрицы в число через приведение типов - теперь понятно, почему пациент так отстаивал принудительное double a = static_cast<double>(b); везде, где можно
                                              Ответить
                                            • >конструирование матрицы с числом в качестве аргумента конструктора
                                              Это уже конкретный конструкторский приём. А сама абстракция -- отображение. Я точно также могу сказать, что преобразование матрицы в double -- просто конструирование числа с матрицей в качестве аргумента.

                                              >А вот в обратную сторону неинтуитивная жопка получается
                                              Мне приходилось работать с библиотекой для газодинамики с дефлограцией, где было преобразование матрицы в double, возвращавшее оценку наибольшего собственного числа.
                                              И это было написано в доках к библиотеке.
                                              Ответить
                                              • Так хочется отображений - юзаем функторы, они будут в тему. Касты не нужны.
                                                Ответить
                                                • Функтор удобнее читать, как нечто более сложное. Когда нужно не просто "положить 10р.", а ещё предъявить удостоверение личности.
                                                  Когда не просто A -> B, но и какой-то медиатор нужен.

                                                  А каст -- это точно из А в B.
                                                  Ответить
                                                  • Это тред обсуждения призраков? Давайте про тех, которые гремят цепями.
                                                    Ответить
                              • Операторы приведения матрицы к числу и обратно не нужны. Для преобразования матрицы в число нужно писать методы с говорящими названиями, к примеру, det(), eigen(), metric(). Для преобразования обратно - фабричные методы fromDet(), fromEigen(), fromMetric(), хотя, лично я, сильно сомневаюсь, что кому-то нужно будет конструировать матрицу такими надуманными способами.

                                Если вам нужно использовать все 3 способа в одном модуле, а они помещены в оператор преобразования типа - каким хуем вы будете выбирать тот вид преобразования, который нужно провернуть в данном случае?
                                Ответить
                                • >Если вам нужно использовать все 3 способа в одном модуле
                                  Ещё раз повторю.
                                  Если вам нужно предоставить контракт именно получения детерминанта, то и стройте контракт детерминанта.
                                  Если вы хотите предоставить контракт преобразования матрицы в число, то вы предоставляете именно этот контракт, который бесшовно выражает в С++ преобразованием типа.

                                  >Если вам нужно использовать все 3 способа в одном модуле
                                  Я буду использовать такую библиотеку, которая предоставляет три различных контракта.
                                  Ответить
                                  • Оператор приведения матрицы к числу не нужен вообще. И в нормальных языках вообще нельзя сделать оператор неявного приведения.

                                    АХАХАХ посоны прикиньте - оператор привидения! Чувак такой за пультом сидит и привидение на радиоуправлении летает!
                                    Ответить
                                    • А кто говорит об операторе неявного приведения?
                                      Вызови static_cast и будет тебе явно.
                                      Ответить
                                      • > Вызови static_cast и будет тебе явно.
                                        Простите, но вы хуй.
                                        Ответить
                                        • Если уже сказать нечего, можно было и промолчать. Хотя бы не так явно сквозило отсутствие воспитания.
                                          Ответить
                                          • Это последний аргумент, приводимый тем, кто на протяжении 50 постов продолжает писать бред и троллить оппонентов мифическим "преобразованием матрицы в число".
                                            Ответить
                                            • Я никого не "троллю", это раз.
                                              Преобразование матрицы в число вовсе не мифическое, это два.
                                              Эти 50 постов продолжаются потому, что каждый раз, когда я говорю, что тарелка красная, мне доказывают, что она круглая. Я постоянно пишу, что прекрасно понимаю, что она круглая. И, всё-таки, она красная.
                                              Это три.
                                              Ответить
                                  • > Если вы хотите предоставить контракт преобразования матрицы в число
                                    Ни одному вменяемому человеку не придет в голову "преобразовывать матрицу в число". Способов такого преобразования много. У каждого способа есть название и соответствующий контракт, которым и нужно пользоваться.

                                    > Я буду использовать такую библиотеку, которая предоставляет три различных контракта.
                                    Я тоже. И это будут методы, а не операторы приведения типов (т.к. 3 оператора приведения для одних и тех же типов описать невозможно).
                                    Ответить
                                    • >Ни одному вменяемому человеку не придет в голову "преобразовывать матрицу в число"
                                      Во-первых, придёт, и не одному.
                                      Во-вторых, это не всегда соответствие какому-то контракту иному. Например тоже приближение максимальным собственным числом. То что, значение близко к характеристическому числу, не значит, что оно равно. Логика можно быть замысловатая, но использующая eigen_value().
                                      Не говоря уже о том, что можно себе представить инверсию управления на этом операторе. Это, конечно, фантастика, я такого не видел. Но представить можно.
                                      Ответить
                                      • > Во-первых, придёт, и не одному.
                                        Proof or GTFO. Причем такой пруф, чтобы автор говорил именно о "преобразовании матрицы в число", а не "вычислял определитель" или "вычислял наибольшее собственное значение".

                                        > Логика можно быть замысловатая
                                        У этой логики есть название? Есть. Значит это уже не абстрактное "преобразование матрицы в число", а какое-нибудь "преобразование Пупкина" или "алгоритм Зихтельберга".

                                        > Но представить можно.
                                        Можно. А еще можно ходить по раскаленным углям и протыкать себя саблями. Но нужно ли это?
                                        Ответить
                                        • >Proof or GTFO. Причем такой пруф
                                          Если бы я мог дать кусочек кода и тем паче ссылку, я бы это сделал.
                                          Здесь речь не идёт о какой-то супер-пупер open-source библиотеке.

                                          О чём конкретно шла речь, я писал выше. Трёх реальных случаях из моей жизни.

                                          > Но нужно ли это?
                                          В каждом конкретном случае каждый метод делается с определённой целью и вряд ли абстрактной.
                                          Преобразование матрицы в число, с которым я сталкивался, сделано исключительно для удобного общения одной части библиотеки с другой.

                                          Конкретно, сделано было с целью возможности подсунуть состояние, представленное матрицей, в методы приблизительной оценки.
                                          Ответить
                                          • Ладно, а вы неявное преобразование хотябы запретите в таком случае?
                                            Ответить
                                            • Зависит от ситуации.
                                              И удобства эксплуатации. Внутри моего куска кода, под моим именем нет неявных конструкторов. Но в случае с выхлопом "наружу", мнение окружающих важно.
                                              Ответить
                                          • > Трёх реальных случаях из моей жизни.
                                            Эти случаи назывались "поиск определителя", "вычисление метрики" и "вычисление наибольшего собственного значения"? Так какого ж ... вы пишете, что это абстрактное "преобразование матрицы в число". Я более чем уверен, что назывались они не toNumber(), и что в комментариях к этим методам вы писали их корректные названия, а не "Преобразование в число. Подробности в документации"...

                                            > В каждом конкретном случае каждый метод делается с определённой целью и вряд ли абстрактной.
                                            Полностью согласен. Но у вас, простите, по классу матрицы на каждую библиотеку? Матрица у которой оператор приведения возвращает наибольшее собственное значение, матрица, у которой оператор приведения возвращает определитель... Вот такое вот ооп...
                                            Ответить
                                            • Наследники класса BaseMatrix с виртуальными методами, точняк.
                                              double d = (double)(MatrixWhichCastsToDoubleAsDeter minant)M;
                                              Ответить
                                              • double determinant = (double)(MatrixWhichCastsToDoubleAsDeter minant)matrixWhichCastsToDoubleAsDetermi nant;

                                                fxd
                                                Ответить
                                                • Не, это дна и та же матрица, которую принудительно кастуют к одному из потомков.
                                                  Ответить
                                              • > Наследники класса BaseMatrix с виртуальными методами
                                                Ну тогда шаблоны для "приведения":
                                                template <double (*F)(const Matrix &m)> class MatrixWith : public Matrix {
                                                ...
                                                    operator double() { return F(*this); }
                                                }
                                                MatrixWith<determinant> m;
                                                Ответить
                                            • Господин bormand,
                                              Эти случаи никак не назывались. Речь шла о том, что внутри логики преобразования одного в другое может быть запрятана более сложная логика. Включавшая в себя вычисление определителя или оценку собственного числа.

                                              Так придумали наши американские друзья. Это сначала было несколько непривычно, но потом всё стало понятно.

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

                                              Относительно детерминанта, что-то для порядка вычисления. Тоже для удобства навешено на оператор приведения, на случай, если логика изменится.
                                              Ответить
                                              • int(vector) = vector.size() по такой логике?
                                                Ответить
                                                • > int(vector) = vector.size() по такой логике?
                                                  Привет, Perl! Там так и есть.
                                                  Ответить
                                                • Наверное, да.
                                                  То есть, внутри преобразования используются иные методы, чтобы "удовлетворительно", с точки зрения поставленной задачи, преобразовать одно в другое.

                                                  Я, в проекте, с которым работаю, использую преобразование уравнения в приближение к локальному минимуму.
                                                  Ответить
                                                  • > Я, в проекте, с которым работаю, использую преобразование уравнения в приближение к локальному минимуму.

                                                    Ну зачем, зачем принимать решения, которые снижают понятность проекта ради копеечной выгоды... Ну неужели там тысячи поисков этого локального минимума, и писать eq.localMin() уже невмоготу...

                                                    Самое плохое тут - теряется универсальность решения. Допустим, в соседнем проекте мне надо было бы искать локальные максимумы этого уравнения - я бы добавил в этот класс еще один метод, и использовал бы эту библиотеку в двух проектах... А здесь как? Копипастить ее в другой проект и переделывать оператор? Ну не понимаю я таких "оптимизаций"...
                                                    Ответить
                                                    • Здесь не оптимизация.
                                                      Это вот как раз та самая идея, подсмотренная у программистов Crysler, когда я ещё учился.

                                                      Есть у меня набор уравнений и есть некая функция.
                                                      Функция принимает массив double и выплёвывает оптимальный double.
                                                      Я преобразую уравнения в double, используя некий "эмпирический" алгоритм из компонент оценки минимума. Зашарашиваю в эту супер-пупер функцию, которая выплёвывает мне оптимальный double. Нахожу несколько уравнений с близкими double, потом повторяю, пока не получится самое удачное к близкому.
                                                      Вот тот минимум и даёт мне "хорошую" характеристику системы.
                                                      Ответить
                                                      • > Я преобразую уравнения в double, используя некий "эмпирический" алгоритм из компонент оценки минимума.

                                                        Ну а почему это должно быть оператором (double) а не методом approximate()?
                                                        Ответить
                                                        • Ни почему.
                                                          Это действительно мог быть и метод с "говорящим названием" .findEmpiricDoubleApproximation();

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

                                                          То есть, это на мой взгляд оно самое: абстрактное отображение. Ведь я могу туда что угодно запихнуть. Минум. Максимум. Коэффициен ряда. Главное, чтобы double был, чтобы его в массив свалить.
                                                          Ответить
                                                        • Даже более того!
                                                          Я не хочу, чтобы человек, который потом будет пользоваться этим или подключать куда-нибудь, хоть что-то предполагал о том, как это происходит. А то ещё начнёт где-нибудь переиспользовать эти числа по иному назначению.
                                                          -- Ага, раз минимум, буду его пользовать. А потом в новой версии пересоберётся это дело с новым алгоритмом -- и чепец.
                                                          Ответить
                                                          • > Я не хочу, чтобы человек, который потом будет пользоваться этим или подключать куда-нибудь, хоть что-то предполагал о том, как это происходит.
                                                            Прочитав название метода empiricApproximation() он поймет только то, что это каким-то образом вычисляет приближение, и не более того. Что вам и нужно. В документации к методу можно описать, что возвращаемое значение зависит от реализации, и может измениться в любой момент. Я не вижу улучшения инкапсуляции от использования оператора (double).

                                                            > И я никак не вижу, что это улучшит прям читаемость кода.
                                                            Да ну бросьте:
                                                            Неявное преобразование - трудно заметить.
                                                            Явный статик_каст - заметен, но не показывает цели этой операции, да и длиннее чем empiricApproximation().
                                                            Ответить
                                                            • Действительно, разница ускользающая.
                                                              Всё же, мне кажется, что здесь есть ещё своеобразный "психологический" момент.

                                                              Когда я пишу метод, то это больше напоминает какое-то свойство алгебры, выраженное в терминах другой.

                                                              А конверсия показывает, что тут происходит нечто более сложное.

                                                              Свойств, выраженных методами, может быть много: approximation1(), approximation2(), ... А конверсия одна.
                                                              Конверсия, вообще говоря, говорит о том, что в этом месте используется какая-то тесная связь между алгебрами, вероятно, какая-то внутренняя информация и об источнике, и о приёмнике, вообще говоря.

                                                              Я полагаю, что подобные вещи, вроде сброса состояния в число, для каких-то сторонних оценок, ближе именно к конверсии, а не к получению свойства в терминах числа.

                                                              Конверсия типа обладает, своего рода, "внутренне присущими" свойствами, которые присутствуют и на уровне проектирования, на уровне алгебр, когда кода ещё нет. По этой причине конверсия кажется прямым переходом от проекта к коду.

                                                              Много слов... И смысл при этом, действительно, размыт. Я понимаю.
                                                              Тут нужно думать о изоморфизме между отношениями на уровне моей задачи и отношениями между структурами уже в языке программирования.
                                                              Ответить
                                                              • > А конверсия показывает, что тут происходит нечто более сложное.
                                                                А мне вот, наоборот, кажется, что конверсия должна быть простой и интуитивной.

                                                                > Я полагаю, что подобные вещи, вроде сброса состояния в число, для каких-то сторонних оценок, ближе именно к конверсии, а не к получению свойства в терминах числа.
                                                                Да нет. Это именно свойство уравнения - некая оценка, полученная на основе его изучения. Преобразованиями тут и не пахло. Все-таки математик, имхо, напишет "вычисляем меру" или "получаем эвристическую оценку", но никак не "преобразуем это уравнение в число".
                                                                Ответить
                                                                • Не знаю.
                                                                  Может быть это вопрос уже конкретно стиля. Я не утверждаю, что прям вот так нужно делать. Но мне кажется это более логичным, а вот вам нет.

                                                                  Если бы это была "мера", то это действительно был бы метод. Тому можно много привести доводов.

                                                                  А вот такой "финт" уже вызывает сомнения. Фактически я использую его для "склейки" каких-то разных участков кода. То есть, это такой "проектный шов", "бесшовно переходящий в кастинг".


                                                                  Я бы уже закрыл этот вопрос. Вроде бы понятно, что все всё поняли. Я хотел указать, что задачи бывают, когда нужно бывает один тип сбросить в другой, чтобы как-то пооперировать с ним в другой алгебре, и, не исключено, что даже как-то "ожидаемо" его восстановить. И в некотором случае даже преобразование в double сложного типа может казаться людям логичным.

                                                                  Да. Подобная многословность, к сожалению, приводит к усложнению сопровождения. Но тут уж... Закон сохранения халявы: или применять много разных методов даже для близких ситуаций, но тогда придётся постоянно оглядываться; или вам это не нужно, но зато всё много более предсказуемо.
                                                                  Ответить
                                                                  • > Я хотел указать, что задачи бывают, когда нужно бывает один тип сбросить в другой, чтобы как-то пооперировать с ним в другой алгебре, и, не исключено, что даже как-то "ожидаемо" его восстановить

                                                                    С этим я полностью согласен, постом ниже я как раз привел несколько примеров, в которых такая конверсия имеет смысл.

                                                                    > Я бы уже закрыл этот вопрос.
                                                                    Ок.
                                                                    Ответить
                                                              • > Свойств, выраженных методами, может быть много: approximation1(), approximation2(), ... А конверсия одна.

                                                                Правильная мысль...

                                                                К примеру между двумя представлениями уравнений есть изоморфизм - здесь оператор преобразования типа очень даже к месту.

                                                                К месту оно было бы, возможно, и при преобразовании вектор-столбца в вектор-строку. (Хотя тут спорно).

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

                                                                Но вот между уравнением, и его решением, тем более приближенным, лежит метод его решения. Что как-бы намекает нам на то, что здесь нужно использовать метод, а не преобразование типа.
                                                                Ответить
                                                  • > Я, в проекте, с которым работаю, использую преобразование уравнения в приближение к локальному минимуму.
                                                    Продолжение:
                                                    Допустим, я хочу указывать точность этого самого приближения... куда мне ее передать? Вот умел бы статик каст принимать параметры, и передавать их оператору...
                                                    static_cast<double>(eq, 0.001);
                                                    Ответить
                                                    • Мне кажется каст-вычислитель имеет место на жизнь, если объект позиционируется как функция, т.е. объект-вычислитель.

                                                      Например:

                                                      double determinant = DeterminantCalculator( matrix );

                                                      DeterminantCalculator - конструктор. принимающий матрицу, а получаемый объект может быть преобразован в double.

                                                      С другой стороны сразу видно что это не разу не объект а простая функция.

                                                      double calculateDeterminant( Matrix m );

                                                      Что логично сделать методом класса Matrix.

                                                      А преобразование тут не причём. Его можно встроить в объект-вычислитель-определителя, но не в объект-матрица.
                                                      Ответить
                                                      • > calculateDeterminant
                                                        > логично сделать методом класса Matrix

                                                        Логично, наверное, включить в класс некую стандартную реализацию этого метода. Но от внешних "решателей" всё равно не уйти. Дело в том, что выбор хорошего алгоритма вычисления определителя в реальной жизни зависит от свойств матрицы. И тут уж либо городить для каждого типа матрицы свой класс, что не всегда возможно, либо выносить задачу вычисления наружу.
                                                        Ответить
                                                        • Здесь вопрос компромисса между накладными расходами и удобочитаемостью и привычностью использования.
                                                          Детерминант -- свойство квадратной матрицы. Как бы мы его не вычисляли, результат зависит от матрицы, а не от метода. Для человека логично ожидать, что это будет именно свойство матрицы.

                                                          Можно инжектировать оптимальный вычислитель в матрицу при конструировании или при перехвате вызова getDeterminant().

                                                          Удобно? Несомненно!
                                                          Клиент не заботится о том, что нужно вызвать какую-то там специальную функцию на матрицу. Клиент естественным образом обращается к свойству матрицы, при этом всегда, или почти всегда, получая оптимизированные вычисления.
                                                          Но на это требуются серьёзные накладные расходы на подобную кухню менеджмента.

                                                          Закон сохранения халявы: чем удобнее, тем больше накладных расходов. Ищем приемлемый компромисс.

                                                          Иногда вычисления настолько громоздкие, что подобные накладные расходы -- капля в море.
                                                          Ответить
                                                          • > Как бы мы его не вычисляли, результат зависит от матрицы, а не от метода

                                                            В идеальном мире. В реальном мире для больших матриц, значения которых заданы в виде чисел с плавающей точкой, это неверно.
                                                            Тот, кто задаёт матрицу, может знать о ней больше машины (например, что она трёхдиагональная и т.п.). Некоторые довольно эффективные алгоритмы требуют симметричности матрицы, и т.п.
                                                            Ответить
                                                            • В чём заключается ваше замечание -- не ясно. Поясните.

                                                              Я вижу следующее:
                                                              >Можно инжектировать оптимальный вычислитель в матрицу при конструировании или при перехвате вызова getDeterminant().

                                                              Если клиент знает о матрице больше, то он будет внедрять вычислитель в матрицу руками. Скажем, в процессе вычислений матрица всегда остаётся трёхдиагональной.

                                                              Если клиент не знает какого вида будет матрица в процессе вычисления, то можно подключить "умный оптимизатор", который будет выбирать подходящий метод, анализируя матрицу до передачи управления в getDeterminant().
                                                              Ответить
                                                              • "Я вижу следующее" (tm):
                                                                >> Как бы мы его не вычисляли, результат зависит от матрицы, а не от метода

                                                                В реальном мире детерминант внезапно становится не F[Matrix], а F[Matrix][Algorithm], т.е. зависит ещё и от метода, которым мы его считаем, и часто лишь можем указать границы, в которых он лежит.

                                                                Инжектить вычислитель при конструировании, конечно, можно, но я бы так не стал делать. Может, пользователю, работающему с матрицей, вовсе этот детерминант не интересен. Нужнен будет - пусть сам выбереть вычислитель. Явное лучше неявного. Умный оптимизатор скорее всего не подойдёт, слишком уж дорого выйдет его работа.

                                                                В общем, если бы я проектировал API для работы с линейной алгебной, Matrix бы отвечал только за доступ к элементам и базовые операции (сложение, умножение и т.п.). Сделал бы подклассы Matrix для специализации разреженных, ленточных, симметричных, ... матриц. Поиск собственных векторов/чисел/детерминанта/... были бы внешними операциями.

                                                                Повторюсь, так бы сделал я. Вариант со специализацией алгоритмов внутри подклассов Matrix в теории тоже приемлем.
                                                                Ответить
                                                                • Вопрос к знатокам: возможно ли в C++ определить операции сложения и умножения для набора подклассов класса Matrix как мультиметоды, например, с помощью шаблонных операторов +, * с набором специализаций?
                                                                  Ответить
                                                                  • > определить операции сложения и умножения для набора подклассов класса Matrix как мультиметоды
                                                                    операторы можно определить как в классе, так и вне - как инлайновый бинарный оператор
                                                                    т.к. нам явно понадобятся дефолтные операции, то очевидно, в базовом классе (скажем, gen) будут операторы, умеющие складывать и т.д. с другим базовым классом
                                                                    для класса потомка T1, если нужно отдельно оговорить иное поведение на сложение с другим типом (в т.ч. базовым) T2, придется описать внешние бинарные операторы парой (T1, T2) и (T2, T1)
                                                                    http://ideone.com/qVyn1
                                                                    - одного (T1, T2) не хватит (если не будет (T2, T1), то компилятор сперва найдет (gen, T1), приведет к (gen, gen) и успокоится)
                                                                    http://ideone.com/sp2TO

                                                                    ну и, думаю, очевидно, что никакого полиморфизма тут работать не будет
                                                                    Ответить
                                                                    • Ага, спасибо, всё примерно так, как я и думал. Без полиморфизма, конечно, не очень красиво.

                                                                      Помню, в универе пытался моделировать на жабе базовые математические концепции, ввёл различные типы чисел (натуральные, целые, рациональные, ...) и пытался написать для них операции сложения / вычитания / умножения / деления, которые бы имели вменяемое с точки зрения математики поведение. Желательно, чтобы всё это было типобезопасно. В общем, ситуация практически аналогичная.

                                                                      Так вот, вышло всё это полным провалом. Сейчас я почти уверен, что это невозможно реализовать на Java расширяемо без унылых instanceof и кастов, ибо точный тип + неизвестен в compile time. Разве что вводить собственную систему диспетчеризации по типам. Но задача в целом нетривиальная.

                                                                      Это было одной из причин, почему я заинтересовался Lisp.
                                                                      Ответить
                                                                      • ну страуструп заявлял, что лично он был за мультиметоды в с++ еще в 90-е
                                                                        но инертность производителей компиляторов и несовместимость их реализаций rtti так и не позволили продавить эту функциональность в стандарт
                                                                        Ответить
                                                                • >В общем, если бы я проектировал API
                                                                  А никто вам и не предписывает устраивать API определённым образом.
                                                                  Как вы с коллегами и клиентами (людьми имеется в виду, которые ваш код будут использовать) договоритесь, так и делайте.

                                                                  Вы упоминали, что нужно городить много подклассов матриц или выносить "наружу".
                                                                  Я представил бесшовный переход от анализа в проект, где вычисление детерминанта по прежнему принадлежит матрице, как оно было бы в реальной жизни, а все вычислительные нюансы спрятаны в сложности структуры. Конечно, по сути из матрицы вынесен метод вычисления, но так, что пользователю этот процесс может по прежнему казаться прозрачным.
                                                                  Ответить
                                                                  • > как вы с коллегами и клиентами договоритесь

                                                                    Возьмём популярный нынче OpenSource. Чтобы решить свою задачу, вы разрабатываете библиотеку, и понимаете, что она может быть полезна потенциально многим людям. С кем и что вы собираетесь обсуждать? Скорее всего, люди захотят использовать этот код совсем не тем способом, каким вы его используете, и их требования могут серьёзно отличаться от ваших.

                                                                    Вам, как разработчику библиотеки, остаётся лишь детально продумать возможные варианты использования и приложить максимум усилий на выделение и ключевый несвязанных сущностей и предоставление возможности их комбинировать, желательно, лишь допустимыми способами.

                                                                    Именно эти качества я и считаю наиболее важными в публичном API: наличие ярко выраженных сущностей с понятными и удобными правилами их комбинаций.

                                                                    Повторюсь, против вашего подхода (наличие у матрицы свойства determinant) я особых возражений не имею, это может быть удобно в рамках некоторых задач. Но моей бы первой мыслью была "А по какому алгоритму происходит вычисление детерминанта?".
                                                                    Ответить
                                                                    • Интересно, скоро ли будет переполнение из-за уровня вложенности комментариев?
                                                                      Ответить
            • > Так лучше?
              http://www.youtube.com/watch?v=xtOkNZK-m4A#t=0m49s
              Ответить
      • Apirpciateon for this information is over 9000-thank you!
        Ответить
    • А за самый внутренний if компилятор ничего не скажет? Чего-нибудь типа a statement has no side effect?
      Ответить
      • В то время как нормальные языки избавляются от побочных эффектов, крестоблядские крестокомпиляторы ругаются на команды, не содержащие побочных эффектов.
        Ответить
        • Результат не используется, побочных действий нет, нахрена такой код вообще нужен? ;)
          Ответить
        • > от побочных эффектов
          > нормальные языки
          т.е. функциональные?
          Ответить
          • Функциональные языки не избавляются от побочных эффектов, они их отделяют от чистого кода.
            А о каких таких языках говорит @TarasB я не знаю.
            Ответить
            • > они их отделяют от чистого кода
              Кто отделяет? Из известных только Haskell и отделяет, Erlang, OCaml, Lisp, Scala, ... - колбась побочные эффекты где вздумается.
              Ответить
              • Так ведь из списка только Haskell чисто ф-циональный. Lisp, Erlang, Scala, Ocaml - мультипарадигменные.
                Ответить
                • Я не спорю, стоит отделять чисто функциональные языки (Haskell и его варианты типа всяких Clean) и языки, поддерживающие функциональный стиль (Lisp, Erlang, OCaml...). Часто последние также называют "функциональными" (видимо, потому, что функциональный стиль в них является идеологически основным).

                  Java, к примеру, поддерживает и форсирует ООП-стиль, но не является чистым ООП-языком, ибо примитивы. Тем не менее, Java называют объектно-ориентированным языком. Аналогичная ситуация с "функциональными" языками, что вызывает много недоразумений.

                  Не критики ради, просто решил заострить внимание на несовершенстве терминологии.
                  Ответить
            • > Функциональные языки не избавляются от побочных эффектов
              http://ru.wikipedia.org/wiki/Побочный_эффект_(программирование)
              
              http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.A7.D0.B8.D1.81.D1.82.D1.8B.D0.B5_.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D0.B8

              это же и есть чистый код. или я что-то упускаю?
              Ответить
        • > нормальные языки избавляются от побочных эффектов
          PASCAL АНОМАЛЕН
          http://ideone.com/Rz7vE
          Ответить
          • правильно, выражение в паскале не является предложением.
            Ответить
        • В то время когда космические корабли бороздят просторы большого театра...(c)
          Ответить
        • Я кстати вспомнил, откуда сообщение. Это jslint так ругается на неиспользуемый код. Ну да не важно. Смысл наверное в том, что в языках где явно нужно показывать функции, что она возвращает, предполагается, что программисту легче заметить, что выражение никак не повлияет на программу если у него нет побочных эффектов (т.как неиспользование возвращаемого значения - обычная практика, например, во многих имеративных языках присваивание возвращает присвоеное значение, которое нигде потом не используется, и если бы было по предупреждению за каждое такое выражение, программисты бы замучались искать предупреждения, которые имеют смысл.
          Ответить
      • gcc ругался на ii == 1 и т.п.
        Ответить
      • А с каких пор авторы лаб обращают внимание на ругательства компилятора, если "оно запускается"?
        Ответить
        • Какой нах ворнинг?? Скомпилируй и заткнись!
          Ответить
          • [Дефолтные опции]
            Компилятор: а вот тут в строке 15, возможно вы имели в виду...
            Программист: Какой нах ворнинг?? Скомпилируй и заткнись!

            [-Werror]
            Компилятор: Что за нах ты написал в 15й строке!? Заткнись и иди перепиливать.
            Программист: okay...
            Ответить
            • fixed:

              [/W4]
              Компилятор: а вот тут в строке 16, мне кажется немного подозрительным...
              Программист: да всё ок, тебе показалось, закоммичу на /W3 и пойду пить пиво
              Тарас: КРЕСТОБЛЯДСКИЙ КРЕСТОКОМПИЛЯТОР!!!
              Ответить
              • fixed:

                [В любой ситуации]
                Тарас: КРЕСТОБЛЯДСКИЙ КРЕСТОКОМПИЛЯТОР!!!
                Ответить
              • А ещё ведь специальные анализаторы кода есть...
                Ответить
              • Нет, со мной так, кроме шуток:
                [/W4]
                Я: вот на этой вот строчке компилятор выводит такое вод предупреждение, мне пришлось написать вот такой костыль, чтобы его не было, а как правильно?
                Крестобляди: Ты чё, дурак что ли, warn off написать не можешь?
                Самый умный крестовик: Ну попробуй добавить вот такую строчку, чтобы указать компилятору, что ты в курсе и учти, что тебе придётся не делать некоторые другие вещи.
                Адеры: Допиши эту прагму, тогда ты сможешь делать то, что тебе надо, но будет запрещено делать некоторые другие вещи, на которые это предупреждение косвенно намекает.
                Ответить
                • крестовик: http://ru.wikipedia.org/wiki/крестовики
                  Ответить
                • это какие же некоторые другие вещи тебя вынуждают не делать при предупреждении unused parameter
                  Ответить
                  • Можно, например, запретить его использовать. O_o
                    Ответить
                  • Бывают и другие предупреждения.
                    Ответить
                • Любой код может быть либо хорошим либо плохим.
                  Варнинги указывают, что код возможно плохой.

                  Если варнинг указывает на хороший код - виноват анализатор.
                  Если варнинг указывает на плохой код - виноват программист.

                  Но самое главное, что нужно не извращаться, а писать короткий, понятный и ясный код, который прост в сопровождении. В таком коде варнингов не будет.

                  А все эти while (100500 операторов для "эффективности") <пусто>; - извращения.

                  Эффективность добавляют в конце и не за счёт пары тактов, а за счёт замены алгоритма со сложностью O( n^2 ) на O( log n ).
                  Ответить
                  • > while (100500 операторов для "эффективности") <пусто>; - извращения.

                    Это не извращения, это C-style :)
                    Ответить
                    • Лишь бы за живое не задеть программистов с нетрадиционной ориентацией.
                      Ответить
                    • Это кулхацкер стайл.
                      Ответить
                    • >Это не извращения, это C-style :)
                      Не говори никому. Не надо.
                      Ответить
                      • "Experienced C programmers would prefer..."
                        void strcpy(char *s, char *t)
                        {
                            while (*s++ = *t++)
                                ;
                        }
                        (c) "The C Programming Language"
                        Ответить
                        • Лучше макрос написать, а то вызов функции такой медленный...
                          Ответить
                        • Да, это такой детектор на «кто и что читал».
                          Гражданин Fai — любитель(средняя весовая) вбросить.
                          А вот внезапно закрыть срачь(тот самый случай когда троллят троллей), можно
                          было немного тоньше. Ну да ладно.
                          Ответить

    Добавить комментарий