Goto использовать можно!НО, как считают программисты после использоватья этого оператора код становится менее читабельным. От этого оператора уже отказались в 90-е года.Но всетаки он присутствует в языках высокого уровня. И наиболее часто используется в assembler, он там как jmp. Вывод: этот оператор лучше всего не использовать если хочешь казаться современным
бред мне в уши... Загляните в ядро линукса, там этих goto пруд пруди, и все они юзаются только с одной благородной целью, и делают код намного удобней чем что либо другое
В примере с матрицами можно было бы заюзать класс матрицы, вместо int[,]. Объекты этого класса могли бы проверять сами себя и бросаться исключениями. Конечно же, всё зависит от задачи. Ага, и этот код очень легко читать и понимать.
писалось в стиле Аля-Си.... а там скорее int *mass; mass =new int[n][k]; ... типа чето делаю не относясь к задаче алгола delete[] mass; чем классная лабуда с конструкторами деструкторами и исключениями лучше... попробуйте обьяснить человеку пишущему на ассмблере но не знающеего Си чему соответствуют исключения и что это далеко не Goto ... боюсь он со смехом вам диззассемблирует! 8)) а по поводы простоты .... можно взять человека с улицы и обьяснить ему код с классами и в стиле Аля-Си, результат о том какой код он поймет предсказуем!
Если ты внимательно смотрел, то должен был заметить что в основном он используется для обработки ошибок, что вполне допустительно для С. В таких языках как С++, Java, C#, есть исключения которые избавляют программера использовать метки для обработки ошибок. В случае кода Algol'a, можно было бы поступить более изящней, как написал nerezus и Qwazar. Случай же с глубокой вложенностью циклов не более чем классический и часто можно встретить в "goto холиварах", а вот на практике встречается не так часто ибо можно переписать без использования последнего.
Code: public TcpClient Connect(IPEndPoint host) { TcpClient client = new TcpClient(); int maxTryCount = 5; while(true) { try { client.Connect(host); return client; } catch (SocketException) { if(0 == --maxTryCount) { throw; } } } } Вот вроде рабочий вариант без goto. Не проверял на синтаксис, но работать должно )
Да, это рабочий вариант. Но проще ли он ? Любой алгоритм можно реализовать без goto. Вопрос в том, будет ли он проще для восприятия.
Почему-то никто не отреагировал на критику такого подхода. На всякий случай повторю: 1)Падение производительности 2)Необходимость передачи в функцию большого числа параметров. 3)Код начинает изобиловать кучей малопонятных функций, с неопределенной семантикой. Конечно это крайние случаи. Но и я в первом постинге и пишу про карйние случаи. В 90% случаев конечно я тоже выношу участки кода в отдельные функции. Но остаются еще 10% где это не рационально. И там я применяю тот подход который сделает код быстрее и понятнее, а не разбиваю лоб об стену, но пишу "правильный" код.
Кода меньше. А можно просто твой вариант заменить, исправив гото на цикл и break. как минимум - не сложнее. На сколько процентов? Я думаю, что на 0% Не большего, чем у тебя Субъективно, причем большинство так думает именно о goto.
да, для сишарпа это конечно проблема =) когда я тестировал c++ vs c#, шарп выйграл по причине инлайнинга функций. пришлось задавать _forceinline. так что я бы не сказал, что здесь можно ощутить проблемы. до 6-7 параметров человек вполне переварит. на худой конец передавай объект класса. Кто мешает здраво именовать функции, на худой конец комменты никто не отменял.
По пунктам: 1) Время работы программиста куда дороже времени работы системы, а удобство понимания кода сильно на это время влияет. Мало того, многие классики начиная с Фаулера, и заканчивая более современными авторами рекомендуют не оптимизировать код до того как его прогнали профайлером, т.к. при мелочной оптимизации может оказаться, что ты оптимизируешь отнюдь не критичный участок, а читабельность кода в целом падает (а значит и время дебага, добавления новой функциональности растёт в разы). Т.е. на первом этапе оптимизация должна быть алгоритмической, а после профайлера, можно задумываться над push/pop и т.д., да и то только на самых часто вызываемых/тормозящих участках. 2) Это не страшно, главное давать осмысленные названия. Ну и не перегружать тела функций. Да и более 5 параметров практически никогда не бывает. К тому же, всегда часть кода можно вынести в отдельный класс. 3) Названия функций должны говорить сами за себя. А не func1, func2, func3
Касаемо падения производительности - спорно. Далеко не всегда возможен инлайн, и на вызов метода в любом случае тратится время. А касаемо осмысленных названий, так в том то и дело , что это куски алгоритма и у них нет отдельной и понятной семантики.