OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 21 Ноябрь, 2019 19:05

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 257 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13
Автор Сообщение
СообщениеДобавлено: Вторник, 09 Июль, 2019 09:14 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Странная штука, меня тоже больше раздражает continue.
Даже когда сам сознательно напишу.... руки чешутся избавиться от него.
Но по правде говоря я уже перестал понимать почему испытываю этот негатив.

Может быть потому что видел слишком много плохого кода с ним.
Он как предупреждение: "осторожно! возможно этот код писал идиот"

Я пытаюсь бороться с этим чувством по одной простой причине: Кто-то читает мой код и точно так же не без оснований считает что идиот я.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 09:37 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Я даже пример приведу, чтобы было над чем поржать:

Вот недавно я написал:

Код:
Function Build(Pattern) Export
   Lexer = Lexer(Pattern);
   Regex = New Array;
   CharSet = NextChar(Lexer);
   Balance = 0;
   Node = NewNode(Regex); // нулевой узел
   Node = NewNode(Regex); // первый узел
   While CharSet <> "" Do
      If CharSet = "\" Then   
         CharSet = CharSet(Lexer, NextChar(Lexer));
      ElsIf CharSet = "." Then
         CharSet = Lexer.AnyChar;
      ElsIf CharSet = "[" Then
         Set = New Map;   
         Complement = False;
         CharSet = NextChar(Lexer);
         If CharSet = "^" Then
            Complement = True;
            CharSet = NextChar(Lexer);
         ElsIf CharSet = "]" Then
            Set[CharSet] = Complement;
            CharSet = NextChar(Lexer);
         EndIf;
         While CharSet <> "]" Do
            If CharSet = "\" Then
               CharSet = CharSet(Lexer, NextChar(Lexer));
            EndIf;
            If CharSet = "" Then
               Raise "expected ']'";
            EndIf;
            If Complement Then
               Lexer.Complement = Not Lexer.Complement;
            EndIf;
            Set[CharSet] = Lexer.Complement;
            Lexer.Complement = False;
            CharSet = NextChar(Lexer);
         EndDo;
         CharSet = Set;
      ElsIf CharSet = "(" Then
         Count = 0;
         While CharSet = "(" Do
            Count = Count + 1;
            CharSet = NextChar(Lexer);
         EndDo;
         Balance = Balance + Count;
         Node["++"] = Count;
         Node["next"] = Regex.Count();
         Node = NewNode(Regex);
         Continue;
      ElsIf CharSet = ")" Then
         Count = 0;
         While CharSet = ")" Do
            Count = Count + 1;
            CharSet = NextChar(Lexer);
         EndDo;
         Balance = Balance - Count;
         Node["next"] = Regex.Count();
         Node["--"] = Count;
         Node = NewNode(Regex);
         Continue;
      ElsIf CharSet = "_" Then
         Lexer.IgnoreCase = Not Lexer.IgnoreCase;
         CharSet = NextChar(Lexer);
         Continue;
      ElsIf CharSet = "$" Then
         Node[""]= Regex.Count();
         Node = NewNode(Regex);
         Break;
      ElsIf CharSet = "*" Or CharSet = "+" Or CharSet = "?" Then
         Raise StrTemplate("unexpected character '%1' in position '%2'", CharSet, Lexer.Pos);
      EndIf;
      NextChar = NextChar(Lexer);
      If NextChar = "*" Then
         AddArrows(Lexer, Node, CharSet, Regex.UBound());
         Node["next"] = Regex.Count();
         CharSet = NextChar(Lexer);
      ElsIf NextChar = "+" Then
         AddArrows(Lexer, Node, CharSet, Regex.Count());
         Node = NewNode(Regex);
         AddArrows(Lexer, Node, CharSet, Regex.UBound());
         Node["next"] = Regex.Count();
         CharSet = NextChar(Lexer);
      ElsIf NextChar = "?" Then
         AddArrows(Lexer, Node, CharSet, Regex.Count());
         Node["next"] = Regex.Count();
         CharSet = NextChar(Lexer);
      Else
         AddArrows(Lexer, Node, CharSet, Regex.Count());
         CharSet = NextChar;
      EndIf;
      Node = NewNode(Regex);
      Lexer.Complement = False;
   EndDo;
   If Balance <> 0 Then
      Raise "unbalanced brackets";
   EndIf;
   Node["end"] = True; // разрешенное конечное состояние
   Return Regex;
EndFunction


Выглядит как говно. Со стороны наверно нихрена непонятно. И я бы увидев такой код, наверняка решил бы что автор просто дурак.
Однако написал то его я. Совершенно сознательно и понимая что почему я делаю.
Continue тут вставлялись чтобы пропустить второй блок цикла. Ментально я мыслил второй блок как процедуру.
Но писал сразу вот так. На это есть причина - этот код у меня целиком на экране и я могу над ним думать целиком. Могу быстро менять модель и быстро убеждаться что оно не работает. Суть кода - компиляция регулярки в граф в один проход. Я не могу в этой задаче удержать все нюансы в голове, т.к. голова маленькая. Потому компенсирую недостаток ума возможностью видеть весь код сразу. Работаю как скульптор, а не математик.
Переписать структурно можно, но непонятно что это даст.
Код будет структурным, но это будет тот же плохой код.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 10:10 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 959
Откуда: Киев
Цитата:
Код будет структурным, но это будет тот же плохой код.
Одна из проблем программистов - любителей операторов неструктурных переходов заключается в том, что они не понимают, что задача структурного программирования вовсе не в том, чтобы сначала наговнокодить неструктурно, а затем мучительно переписывать это "структурно" с получением такого же говнокода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 10:15 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
ilovb писал(а):
ps Вот употребляю слово "шизофрения" к месту и не к месту. Людей тут шизиками обзываю. И при этом ведь вообще без понятия в чем болезнь заключается...
Шизо -- от того же греческого корня, что и схизма. Френ -- ум.

Шизофрения = распад интеллекта как целостной функции.

Простое слабоумие -- это гипофрения. Среди признаков -- любовь нюхать свои газы и безудержный 3.14159здёж.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 10:16 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
Comdiv писал(а):
Цитата:
Код будет структурным, но это будет тот же плохой код.
Одна из проблем программистов - любителей операторов неструктурных переходов заключается в том, что они не понимают, что задача структурного программирования вовсе не в том, чтобы сначала наговнокодить неструктурно, а затем мучительно переписывать это "структурно" с получением такого же говнокода.
Спасибо. Коллекционирую для педагогических целей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 10:31 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Comdiv писал(а):
Цитата:
Код будет структурным, но это будет тот же плохой код.
Одна из проблем программистов - любителей операторов неструктурных переходов заключается в том, что они не понимают, что задача структурного программирования вовсе не в том, чтобы сначала наговнокодить неструктурно, а затем мучительно переписывать это "структурно" с получением такого же говнокода.


Ну забрали допустим у них игрушки. Это прибавит им ума? Сомневаюсь

Ну и про переписывать "структурно".... Ничего они не переписывают и не мучаются вообще такими вопросами )


Ну и вот этот мой код. Он плох не потому что он не структурный. Я бы и структурно ровно то же самое написал.
Проблема с ним в том, что вменяемо скомпилить можно только в 3 прохода. А мне интересно было именно в один (код не по работе, имею право).
В 3 прохода можно посмотреть код Томпсона. Вот там шедевр алгоритмики.

Но хохма в том, что кто-то читает мой код и не зная контекста думает так как вы написали.


Последний раз редактировалось ilovb Вторник, 09 Июль, 2019 13:25, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 10:35 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Info21 писал(а):
ilovb писал(а):
ps Вот употребляю слово "шизофрения" к месту и не к месту. Людей тут шизиками обзываю. И при этом ведь вообще без понятия в чем болезнь заключается...
Шизо -- от того же греческого корня, что и схизма. Френ -- ум.

Шизофрения = распад интеллекта как целостной функции.

Простое слабоумие -- это гипофрения. Среди признаков -- любовь нюхать свои газы и безудержный 3.14159здёж.


Мда. Спасибо, буду знать.
У меня точно какая-то из форм слабоумия. Потому что болтливость иногда зашкаливает.
В общем то пожалуй единственный минус.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 17:55 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 959
Откуда: Киев
ilovb писал(а):
Ну и про переписывать "структурно".... Ничего они не переписывают и не мучаются вообще такими вопросами )
Естественно, не переписывают. Сначала они придумывают корявый алгоритм написания структурного кода, затем приходят к выводу, что такое написание - это какой-то позор для фанатиков, после чего со спокойной душой пишут "естественный" код.
Что интересно, если таким сторонникам неструктурного кода дать возможность писать в околофункциональном стиле, они зачастую с большим удовольствием пишут структурный код. Ведь из какого-нибудь forEach по коллекции не выпрыгнуть break'ом, так как тело цикла - это безымянная функция. Из объемлющей функции тоже не выпрыгнуть без использования exception.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 18:37 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Ой, функциональный подход имхо вообще отдельная песня.
Там в принципе с порога нужно перестроить мышление, что думать за тебя будет компилятор во многом.
Надо привыкать к ленивости, мемоизации и вот этому всему.
Я даже не возьмусь судить как это вообще соотносится со структурным программированием.

Если бы рекурсия в императивных языках ничего не стоила, то я бы вообще кучу кода писал по другому.
Если бы вызов процедуры ничего не стоил, то я опять же писал бы по другому.
Но по факту мой рабочий инструмент (медленный интерпретатор) обладает определенными свойствами,
с которыми надо считаться. Я много раз превращал хороший структурный код в дерьмо, просто потому что
30 минут - это в 2 раза меньше чем 1 час. Такой эффект дает отказ от структурности кода в реальном языке.
А пол часа как бы дохрена.
И вот лежит это дерьмо и делает свою работу, а я перестал придавать этому значение.
Посмотрел на это, прикинул затраты на поддержку и махнул рукой. И так сойдет.

В общем я вообще уже не верю в красивый идеальный код. Он не работает.
Это как выбор между хрустальным дворцом и домиком из говна и палок.
Выбор очевиден )

Цитата:
Естественно, не переписывают. Сначала они придумывают корявый алгоритм написания структурного кода, затем приходят к выводу, что такое написание - это какой-то позор для фанатиков, после чего со спокойной душой пишут "естественный" код.

На самом деле их поведение еще смешнее. Но это не важно имхо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 19:45 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 959
Откуда: Киев
ilovb писал(а):
Ой, функциональный подход имхо вообще отдельная песня.
Не обязательно функциональный, достаточно околофункционального.
ilovb писал(а):
Я даже не возьмусь судить как это вообще соотносится со структурным программированием.
А соотносится потому, что при композиции функций между их телами так просто не попрыгаешь.

Цитата:
Я много раз превращал хороший структурный код в дерьмо, просто потому что 30 минут - это в 2 раза меньше чем 1 час. Такой эффект дает отказ от структурности кода в реальном языке.
Я писал код для измерения накладных расходов на структурный и неструктурный поиск http://comdivbyzero.blogspot.com/2017/0 ... earch.html - нет никаких сверхестественных расходов в "реальном" языке. Если приходится так корячить код ради оптимизации в каких-то прикладных задачах, то исполнитель языка плохой. Плохих решений в индустрии хватает, и одни отстойные решения тянут за собой другие отстойные решения. Это принято считать "нормой" и "реальностью".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 21:05 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Ну так исполнитель плохой, да. Но я к несчастью ничего поделать не могу )
Кручусь с тем что есть.

Код:
Я писал код для измерения накладных расходов на структурный и неструктурный поиск

Я не читал все, но обратил внимание только на gcc и clang. Как бы не самые дерьмовые компиляторы )
Ну т.е. мне вот например не вполне понятно что тут измеряется. Насколько хорошо написаны компиляторы?
Не пробовали тот же эксперимент провести на компиляторе попроще?
Скажем почти любой скриптовый язык. Или даже BB.
Все таки компиляторов на свете сильно больше, и они в основном сильно хуже gcc.

ps Но я может быть просто что-то не понял, т.к. еще не прочитал все.

add: а, хотя вижу что там еще tcc есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Июль, 2019 23:33 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 959
Откуда: Киев
ilovb писал(а):
add: а, хотя вижу что там еще tcc есть.
И компиляция с -O0 у gcc и clang, при котором оптимизируют они не лучше Blackbox.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Июль, 2019 22:06 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Ох, вот так перечитываешь что сам писал несколько лет назад....
Ну что за дебил.

По сути Тышов, любитель goto, самым адекватным и был тогда.
Прости, мужик. Я был не прав.

Цитата:
Способ, как творил Создатель,
Что считал Он боле кстати —
Знать не может председатель
Комитета о печати.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Июль, 2019 19:22 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 372
Валерий Лаптев писал(а):
На мой взгляд, continue - вредный оператор. Я запрещаю его писать студентам.
break - нормальный.

Обнаружилось любопытное наблюдение по поводу -- бОльшая часть студентов лишь с break могут реализовать корректный код:
https://en.wikipedia.org/wiki/Control_flow
Цитата:
Some academics took a purist approach to the Böhm-Jacopini result and argued that even instructions like break and return from the middle of loops are bad practice as they are not needed in the Böhm-Jacopini proof, and thus they advocated that all loops should have a single exit point. This purist approach is embodied in the language Pascal (designed in 1968–1969), which up to the mid-1990s was the preferred tool for teaching introductory programming in academia.[2] The direct application of the Böhm-Jacopini theorem may result in additional local variables being introduced in the structured chart, and may also result in some code duplication.[3] Pascal is affected by both of these problems and according to empirical studies cited by Eric S. Roberts, student programmers had difficulty formulating correct solutions in Pascal for several simple problems, including writing a function for searching an element in an array. A 1980 study by Henry Shapiro cited by Roberts found that using only the Pascal-provided control structures, the correct solution was given by only 20% of the subjects, while no subject wrote incorrect code for this problem if allowed to write a return from the middle of a loop.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Июль, 2019 19:28 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 372
Подробнее в оригинале:
Roberts, E. [1995] “Loop Exits and Structured Programming: Reopening the Debate,” ACM SIGCSE Bulletin, (27)1: 268–272.

Если кратко, то основная проблематика -- вокруг эффекта "loop-and-a-half" по Дейкстре (может быть здесь на форуме разбираемого в прошлом):
Цитата:
The fact that some loop structures seem to have a natural
exit in the middle has long been recognized. In his 1974
comments on the goto controversy [Knuth74], Don Knuth
outlined his own perspective, as follows:
Цитата:
The iteration statements most often proposed as
alternatives to goto statements have been “while B do
S” and “repeat S until B”. However, in practice the
iterations I encounter very often have the form
Код:
A:  S;
    if B then goto Z fi;
    T;
    goto A
Z:

where S and T both represent reasonably long sequences
of code. If S is empty, we have a while loop, and if T
is empty we have a repeat loop, but in the general
case it is a nuisance to avoid the goto statements.
A typical example of such an iteration occurs when S
is the code to acquire or generate a new piece of data, B
is the test for end of data, and T is the processing of that
data.

Loops of this sort, in which some processing must precede
the test, come up quite often in programming and constitute
what Dijkstra has called the loop-and-a-half problem. The
canonical example of the loop-and-a-half problem is
precisely the one that Knuth describes: reading a set of
input values until some sentinel value appears. If the basic
strategy is expressed in pseudocode, the problem has the
following solution:
Код:
loop
  read in a value;
  if value = Sentinel then exit;
  process the value
endloop;

In this example, the loop/exit/endloop statement is an
extension to the Pascal repertoire and represents a loop that
is terminated only by the execution of the exit statement in
the interior of the loop body. The loop/exit/endloop
extension makes it possible to express the algorithm so that
the input value is read in from the user, tested against the
sentinel, and then processed as necessary.
The loop/exit/endloop approach, however, offends the
sensibilities of many computer science instructors, who
have learned through their experience with Pascal to
“unwind” the loop so that the test appears at the top of the
while loop, as follows:
Код:
read in a value;
while value != Sentinel do begin
  process the value;
  read in a value
end;

Unfortunately, this approach has two serious drawbacks.
First, it requires two copies of the statements required to
read the input value. Duplication of code presents a serious
maintenance problem, because subsequent edits to one set
of statements may not always be made to the other. The
second drawback is that the order of operations in the loop
is not the one that most people expect. In any English
explanation of the solution strategy, the first step is to read
in a number, and the second is to process it by adding it to
the total. The traditional Pascal approach reverses the order
of the statements within the loop and turns a read/process
strategy into a process/read strategy. As the rest of this
section indicates, there is strong evidence to suggest that
the read/process strategy is more intuitive, in the sense that
it corresponds more closely to the cognitive structures
programmers use to solve such problems.
The problem of code duplication is in some sense
objective. The statements that read in an input value do in
fact appear twice in the program, and it is easy to imagine
that an edit in one copy might not be made symmetrically
in the other. The second problem, however, is inherently
more subjective because it hinges on the question of which
loop order is more “intuitive.” What is intuitive for some
may not be intuitive for others, and it may be that a
preference for one strategy over another represents nothing
more than an individual bias. For that reason, it is
important to rely on empirical measurement of the success
that students have in using the different strategies.

В самом деле, претензии не беспочвенны. Вопросом дублирования операций можно пренебречь, а вот структура шага цикла, действительно, инвертирована (ведь суть то итерационного процесса как такового -- сначала read, затем process).

Там же насчёт "стратегии" циклов:
Цитата:
It is also possible to use standard Pascal texts as
evidence that the read/process strategy in fact corresponds
to student intuition. An examination of at the approach
used to solve the read-until-sentinel problem in the five
best-selling Pascal textbooks [Cooper92, Dale92,
Koffman91, Leestma87, Savitch91] reveals that:

• In each of the textbooks, the problem is solved by
unwinding the loop so that the read phase of the
operation occurs twice: once prior to the loop and once
at the end of the loop body.
• In every text except Leestma and Nyhoff, the authors
derive their solution by first presenting the read/process
strategy and subsequently modifying it to fit the
process/read form required by Pascal’s control
structures.

To me, the approach these authors take suggests that they
themselves accept that students find the read/process
strategy more intuitive. To encourage students to write
programs that fit Pascal’s restrictions, these texts teach
them—often at great length—to abandon their initial
strategy in favor of one that reverses the order of the
operations within the loop. My own classroom experience
certainly supports this conclusion. By introducing loop
exits and using the read/process strategy, I find that I can
save almost an entire day’s lecture.
The concern, of course, about introducing an internal
loop exit form is that students will end up abusing it, since
it is certainly possible to do so. Our experience at Stanford,
however, suggests that this problem does not in fact arise.
Students tend to write code based on the models they are
given, using internal loop exits only in the disciplined way
outlined in the class examples. In the last three years, over
2500 students have completed CS1 at Stanford, and the
teaching assistants have reported no problems with overuse
of the break construct. This finding is consistent with the
results of a study by Sheppard, which demonstrated that
internal loop exits do not in fact compromise program
readability [Sheppard79].

И там же в нагрузку методология предполагает и ранний return для функций из циклов (прежде всего, для for).

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

С другой стороны, популярная борьба с "loop-and-a-half" в виде использования функций с "побочными эффектами", чтобы действия по "добыче данных" упрятать в условие цикла, и чтобы всё было "по-структурному" (в т.ч. и в случаях применения побочных эффектов для условий в IF), в целом не соответствует "структурщине" -- подобные функции ведь тогда не есть "предикаты" (не могут быть "защитными выражениями").


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Июль, 2019 19:31 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 372
ilovb писал(а):
Программера во всю используют прерывания/продолжения циклов и в принципе легко обосновывают почему.
И я сам в какой-то момент забил. Мне понятно, им понятно. Проблемы то нет. Ошибки мы делаем ведрами, но совсем не в циклах.

В целом, таки да. Есть исследование, под Microsoft Research, насчёт выявления идиом циклов:
Mining Semantic Loop Idioms

Был проанализирован огромный корпус кода публичных проектов, в основном на Net. Большинство циклов в рядовой рутине не являются условно сложными, популярны прежде всего for/foreach (видимо, по причинам выше в теме), множество выходов из цикла в реальности встречается мало.
Однако учитывалось непосредственно использование операторов циклов. Не мало типовых потребностей удовлетворяются через стандартное или предопределённое API. Есть ещё и LINQ, который, оказалось, на самом деле редко используется в проектах.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Июль, 2019 19:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 372
ilovb писал(а):
А по факту я внезапно осознал, что идеалом для меня был бы Oberon 07 + goto.
Это решение совершенно всех проблем и к языку в плане структур управления ничего добавлять больше не надо.
Не нужны ни бряки ни контины, ни циклы дейкстры, ни циклы пауки.
goto - это то самое make it simple.
Я осознал что именно хотел донести до нас Роберту, когда неожиданно для всех добавил goto в Lua.
Это же идеальная минималистичная фича языка для опытного программиста.

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

Выше в теме был упомянут Кнут (в цитате) и его классика:
Structured Programming with go to Statements

У него как раз goto нужен, прежде всего, чтобы прыгать вовнутрь циклов (и внутри), но по-своему "культурно" и даже с "инвариантами". Однако, он же (ещё в те года) предупреждал, что произвольные прыжки могут пагубно сказываться для компиляторов/процессоров в плане предсказания доступа к памяти. И, в целом, у него форма алгоритмов с goto есть средство для абстрактного исполнителя как некая идеализированная версия алгоритма (или какой должна быть оптимизация), с наименьшей оценочной математической аппроксимацией или для ликвидации избыточных структур.
И, в принципе то, статья больше о том, как избавиться от goto (и, к слову, в качестве общего анализа, если goto рассматривать только для "идеализации", то вроде бы, "контины" для циклов не нужны, а концепция break-а, причём не только для циклов, всё же неоднозначно как-то с ним дела...).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 257 ]  На страницу Пред.  1 ... 9, 10, 11, 12, 13

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB