Re[9]: Синтаксический оверхед - Новая порция
От: raskin Россия  
Дата: 27.06.05 08:37
Оценка:
faulx wrote:
> Здравствуйте, Трурль, Вы писали:
>
> F>>Всегда в этих названиях путаюсь. Что как минимум полугруппа, я
> догадался, но "моноид" — этого я уже не помню. Ну тогда вопрос, как
> знатоку: часто ли в математических книгах операцию в моноиде обозначают
> символом `+'?
> Т>Ни разу не видел.
>
> Я так и думал. Итак, строки с операцией конкатенации образуют моноид, а
> операцию в моноиде не принято обозначать как `+'. Спрашивается, почему
> для строк должно быть сделано исключение?

Наиболее принято, я бы сказал, её обозначать символами не из ASCII...
Поэтому то, что * чуть более (не идеально) корректно, превосходится
традициями...
Posted via RSDN NNTP Server 1.9
Re[8]: Синтаксический оверхед - Новая порция
От: faulx  
Дата: 27.06.05 08:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В высшей алгебре вообще достаточно вольно обращаются со знаками операций


C>Очень часто групповую/моноидную/... операцию пишут как знак плюс в

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

Вот и мне думается, что операцию конкатенации надо обозначать отдельным символом, а не плюсом. Плюс уже занят сложением, а конкатенация на сложение не похожа.
Re[5]: Синтаксический оверхед - Новая порция
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.06.05 08:47
Оценка: +2
Здравствуйте, faulx, Вы писали:

F>К сожалению, не могу согласиться. Вызов, например, функции open — это тоже выражение, которое возвращает дескриптор файла. Ничто не мешает "воображаемому оператору create" возвращать новый объект.

F>Кстати, теоретически, delete может возвращать значение. Если написать свой распределитель памяти, то при неудачном освобождении (передали не тот указатель) можно сообщить об ошибке, бросив исключение. Исключение — это, в каком-то смысле, тоже возвращаемое значение.
Не могу с вами согласится. Исключение не является ни в каком смысле возвращаемым значением. Например, как бы мы ни переписывали delete, мы не сможем использовать его в выражении:
SomeType something = delete pMyObj;

F>Думаю, большинство современных программистов на C++ мучаются с тем, что операция вывода в поток, оказывается, может означать битовый сдвиг.
Попробуйте спросить это большинство современных программистов на C++. Найдите мне хотя бы одного, испытавшего мучения по этому поводу.
F>Т.е. присутствует ассоциативность и нейтральный элемент. Коммутативности и обратного элемента нет. Знатоки алгебры, как называется такая структура? В любом случае это больше похоже на умножение, чем на сложение.
Еще раз намекаю на то, что программирование не сводится к алгебре. В математическом контексте я совершенно с вами соглашусь. В нематематическом контексте никаких ожиданий от пересечения вертикальной черты с горизонтальной здравомыслящие люди не имеют. Покажите мне хотя бы одного человека, который ожидал увидеть * для конкатенации строк. Покажите мне любой другой перегружаемый оператор, который бы с первого взгляда ассоциировался с конкатенацией.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Синтаксический оверхед - Новая порция
От: Cyberax Марс  
Дата: 27.06.05 08:57
Оценка:
faulx wrote:

> C>Очень часто групповую/моноидную/... операцию пишут как знак плюс в

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

Так нету в ASCII более подходящих символов. Есть более-менее подходящий
'&', но он уже занят под логику.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Синтаксический оверхед - Новая порция
От: Amidlokos Россия  
Дата: 27.06.05 09:06
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Черт, а ведь и правда! Действительно, куда естественней было бы писать:

А>
А>old obj;
А>


К слову, после Perl, в котором цикл прерывается словечком last, я лично уже ничему не удивлюсь
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
WARNING: expression "to_be || !to_be" is always true
Re[10]: Синтаксический оверхед - Новая порция
От: Аноним  
Дата: 27.06.05 09:11
Оценка:
>> Вот и мне думается, что операцию конкатенации надо обозначать
>> отдельным символом, а не плюсом. Плюс уже занят сложением, а
>> конкатенация на сложение не похожа.

C>Так нету в ASCII более подходящих символов.


В Юникоде есть куча. Например вот:


Re[10]: Синтаксический оверхед - Новая порция
От: Amidlokos Россия  
Дата: 27.06.05 09:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>faulx wrote:


C>Так нету в ASCII более подходящих символов. Есть более-менее подходящий

C>'&', но он уже занят под логику.

Ну, в некоторых языках под это дело точку застолбили... PHP, Perl.

$a = "Make ";
$b = "love" . " not ";
$a .= $b . "war";


Тоже не очень, но уже решение.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
WARNING: expression "to_be || !to_be" is always true
Re[6]: Синтаксический оверхед - Новая порция
От: faulx  
Дата: 27.06.05 09:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

F>>Кстати, теоретически, delete может возвращать значение. Если написать свой распределитель памяти, то при неудачном освобождении (передали не тот указатель) можно сообщить об ошибке, бросив исключение. Исключение — это, в каком-то смысле, тоже возвращаемое значение.

S>Не могу с вами согласится. Исключение не является ни в каком смысле возвращаемым значением. Например, как бы мы ни переписывали delete, мы не сможем использовать его в выражении:
S>
S>SomeType something = delete pMyObj;
S>


Вы трактуете "возвращаемое значение" в конкретном смысле возвращаемого значения какой-либо функции, а я имел в виду нечто более общее — возможность получить тем или иным способом информацию о том, что было результатом выполнения операции delete. Что-то вроде:

bool my_delete(void *p)
{
  try
  {
    delete p;
  }
  catch (...)
  {
    return false;
  }
  return true;
}


Кстати, то, что delete не имеет возвращаемого значения — это всего лишь волевое решение. Могло бы что-нибудь и возвращаться, и проверяли бы это значение только самые дотошные программисты, из тех, кто проверяет возвращаемое значение printf и close.

F>>Думаю, большинство современных программистов на C++ мучаются с тем, что операция вывода в поток, оказывается, может означать битовый сдвиг.

S>Попробуйте спросить это большинство современных программистов на C++. Найдите мне хотя бы одного, испытавшего мучения по этому поводу.

Надеюсь, было понятно, что я имел в виду, что в случае операции << в C++ в настоящее время еще неизвестно, какое из значений этой операции первичнее (в восприятии программистов) — сдвиг или вывод в поток. Думается, в качестве операции вывода она используется чаще. Да и изучают, вероятно, сначало именно перегруженное значение.

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


Неужели они не удивяться, если символ `+' будет означать вычитание?

S>Покажите мне хотя бы одного человека, который ожидал увидеть * для конкатенации строк.


Если он ничего не ждет от `+', то тем более не ждет и от `*'. Однако, по вашей же логике, это его и не удивит. Впрочем, я не предлагал использовать `*' для конкатенации, я всего лишь сказал (на правах шутки), что это было бы естественнее, чем `+', хотя лучше использовать отдельный оператор.

S>Покажите мне любой другой перегружаемый оператор, который бы с первого взгляда ассоциировался с конкатенацией.


Уже указывалось, что в VB используется символ `&'. Тут надо спрашивать англоговорящих граждан. Для нас `&' — это всего лишь еще одна закорючка, но "у них" эту закорючку используют уже давно и она имеет укоренившийся смысл за пределами программирования. В Haskell используется `++', также как и для конкатенации списков, потому что строка там — это список . В OcaML используют `^'. В каком-то еще языке (кажется, в PHP, но, может, и нет) конкатенацию обозначают символом `,' (запятая). Потом еще где-то видел `|'. Итого:

a + b
a ++ b
a & b
a ^ b
a , b
a | b


Мне лично нравится второй, третий и последний варианты. Второй мне привычнее, но третий, вероятно, лучше во-первых, по приведенным выше соображениям (на правах гипотезы), а во-вторых, он единственный и вариантов (если не считать запятой), в котором оператор выглядит несимметрично, что подчеркивает несимметричность операции конкатенации. С другой стороны, в C++ этот символ уже занят операцией AND. И `++' в бинарную операцию не переопределишь. Пожалуй, в C++ выбор гораздо меньше. С другой стороны, привыкли же к <<. Может, и к `&' привыкли бы. Кстати, еще претензия : почему в C++ нельзя опредить произвольный оператор, как в Haskell, а только предопределенный набор?
Re[7]: Синтаксический оверхед - Новая порция
От: Трурль  
Дата: 27.06.05 09:54
Оценка:
Здравствуйте, faulx, Вы писали:
О, идея!

a then b
Re[11]: Синтаксический оверхед - Новая порция
От: Cyberax Марс  
Дата: 27.06.05 09:56
Оценка:
Amidlokos wrote:

> C>Так нету в ASCII более подходящих символов. Есть более-менее подходящий

> C>'&', но он уже занят под логику.
> Ну, в некоторых языках под это дело точку застолбили... PHP, Perl.
>
>$a = "Make ";
>$b = "love" . " not ";
>$a .= $b . "war";
>
> Тоже не очень, но уже решение.

Точка в С++ уже используется для доступа к членам объекта и не может
перегружаться. Больше подошла бы запятая, тем более, что ее можно
перегрузить
a=a,b,c;

Такое можно сделать хоть сейчас.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Определение циклов
От: Privalov  
Дата: 27.06.05 10:00
Оценка:
Здравствуйте, Трурль, Вы писали:

P>>Этот цикл пишется так:

P>>
P>>      DO 1024 I = 1, 7
P>>      CALL measure
P>> 1024 CONTINUE
P>>

Т>Это другой цикл. А вдруг I используется в measure?

Во-первых, из приведенного фрагмента этого не видно (нет I, помещенной в COMMON-блок). А во-вторых Фортран не накладывает, AFAIR, никаких ограничений на изменение переменной цикла где-то в теле цикла. А если начальное значение I отлично от 1, вычислим его перед входом в цикл и положим в целую переменную.
Re[7]: Синтаксический оверхед - Новая порция
От: raskin Россия  
Дата: 27.06.05 10:12
Оценка:
faulx wrote:

>[мечтания об идеальном обозначении]


> Кстати, еще претензия : почему в C++ нельзя опредить произвольный

> оператор, как в Haskell, а только предопределенный набор?

Потому как парсить легче... И правила расстановки скобок определены раз
и навсегда.. Хотя с точки зрения "сложного, мощного языка" может и надо
было оставить полный хаос в этой области.. И
а=а++ + ++а

показалось бы цветочками!
Posted via RSDN NNTP Server 1.9
Re[7]: Синтаксический оверхед - Новая порция
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.06.05 10:12
Оценка: +1
Здравствуйте, faulx, Вы писали:

F>Вы трактуете "возвращаемое значение" в конкретном смысле возвращаемого значения какой-либо функции, а я имел в виду нечто более общее — возможность получить тем или иным способом информацию о том, что было результатом выполнения операции delete.

Я прекрасно понял, что вы имеете в виду. Но мы-то говорим о совершенно конкретном операторе и выборе термина для него. Стейтмент
delete a
не имеет никакого возвращаемого значения. Да, он может бросить исключение, или модифицировать глобальную переменную — это неважно. Главное, что этот стейтмент не является выражением. Это чисто императивная конструкция. Попробуйте представить, что С++ написан на русском языке и сравните:
Экскаватор * мойЭкскаватор = новый Экскаватор();
...
удалить мойЭкскаватор ;

с
Экскаватор * мойЭкскаватор = создать Экскаватор();
...
удалить мойЭкскаватор ;

Теперь понятно, почему прилагательное лучше подходит?
Кстати, в другом контексте подойдет именно глагол:
Экскаватор * мойЭкскаватор = ФабрикаЭкскаваторов.Создать();


F>Что-то вроде:


F>Кстати, то, что delete не имеет возвращаемого значения — это всего лишь волевое решение. Могло бы что-нибудь и возвращаться, и проверяли бы это значение только самые дотошные программисты, из тех, кто проверяет возвращаемое значение printf и close.

Если бы возвращал, то и называться мог по другому

F>Неужели они не удивяться, если символ `+' будет означать вычитание?

Что может означать "вычитание" в контексте строк?
S>>Покажите мне хотя бы одного человека, который ожидал увидеть * для конкатенации строк.


F>Мне лично нравится второй, третий и последний варианты. Второй мне привычнее, но третий, вероятно, лучше во-первых, по приведенным выше соображениям (на правах гипотезы), а во-вторых, он единственный и вариантов (если не считать запятой), в котором оператор выглядит несимметрично, что подчеркивает несимметричность операции конкатенации. С другой стороны, в C++ этот символ уже занят операцией AND. И `++' в бинарную операцию не переопределишь. Пожалуй, в C++ выбор гораздо меньше. С другой стороны, привыкли же к <<. Может, и к `&' привыкли бы.

Может быть. По факту, привыкли к плюсу.
F>Кстати, еще претензия : почему в C++ нельзя опредить произвольный оператор, как в Haskell, а только предопределенный набор?
Об этом хорошо написано у Страуструпа в Design and Evolution.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Синтаксический оверхед
От: jazzer Россия Skype: enerjazzer
Дата: 27.06.05 10:31
Оценка: 1 (1)
Здравствуйте, moudrick, Вы писали:

M>Здравствуйте, jazzer, Вы писали:


J>>Здравствуйте, moudrick, Вы писали:


M>>>С++, кстати, тоже начинался с академической разработки. А практики его потом подхватили.

M>>>Ссылку навскидку не нашел, извините.

J>>И не найдешь.

J>>Потому что он создавался именно для облегчения программирования на С (как и С по отношению к асму, кстати).
J>>Цель сугубо практическая.
J>>И обкатывался язык не на теоремах, а в руках действующих программистов на С.

J>>Почитай D&E.

M>Моя настольная книга.
M>AT&T (где начинал разрабатываться C++), да будет Вам известно — исследовательская лаборатория, стало быть там академическая среда, не так ли?

Мне это отлично известно, более того, не имеющие книги могут увидеть соответствующие слова на сайте Бьярне.

Только вот закавыка в том, что это — научно-исследовательская лаборатория ДЛЯ НУЖД AT&T.
Все крупные предприятия имеют свои НТО (научно-технические отделы), и НТО работают не ради чистой науки, а исключительно по заказу предприятия для нужд и во имя прибылей этого предприятия.
Так что это ни капли не академическая среда, в которой доказывают теорему Ферма, это обычная инженерная среда, в которой люди ищут решения конкретных стоящих в данный момент перед предприятием проблем.

Опять же, с его сайта:

Why did AT&T support the development of C++?

When I first developed C++, AT&T built systems of greater complexity and with greater reliability requirements than most organizations. Consequently, we had to influence the market and help set standards that meet our needs — or else we wouldn't have the tools to build our systems. Left to itself "the industry" will create languages and tools for dealing with "average" problems. Similarly, teachers tend to focus on languages and tools that serve students and researchers well — even if they don't scale to the most demanding tasks.
At the time when I developed C++ — and before that when Ken Thompson and Dennis Ritchie developed Unix and C — AT&T was probably the worlds largest civilian user of (and consumer of) software tools. Then, we probably used a wider range of systems — from the tiniest embedded processors to the largest supercomputers and data-processing systems. That put a premium on systems that were applicable in many technical cultures and on many platforms. C and C++ were designed with such demands in mind.

Thus generality is essential, and proprietary features are seen as limiting the choice of platforms and vendors. As a consequence AT&T was and is a major supporter of formal standards (for example, ISO C and ISO C++).

Actually, AT&T made enough money on Cfront, my original C++ compiler, to pay for the development of C++ several times over.

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: Синтаксический оверхед - Новая порция
От: Кодт Россия  
Дата: 27.06.05 10:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Точка в С++ уже используется для доступа к членам объекта и не может перегружаться. Больше подошла бы запятая, тем более, что ее можно перегрузить


Можно, но нельзя.
У запятой есть две общепринятые семантики: во-первых, синтаксис разделения списка параметров, а во-вторых, последовательное выполнение.
Поэтому
series = make_series(), x, y, z;

ещё более-менее приемлемо, а вот с конкатенацией уже будут изумления.
Кроме всего прочего, встроенный operator, определён для любых типов — поэтому в случае ошибочного использования компилятор не мяукнет.
А operator+ не определён для голых строк (указатель+указатель). Хотя и это не бесспорно: он определён для пары (указатель+число), поэтому
"abcde" + 'f'

будет истолковано превратно.
Лучше перегрузить что-нибудь неуказательно-арифметическое. Например, %.
Перекуём баги на фичи!
Re[8]: Синтаксический оверхед - Новая порция
От: faulx  
Дата: 27.06.05 11:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я прекрасно понял, что вы имеете в виду. Но мы-то говорим о совершенно конкретном операторе и выборе термина для него.


Скорее о выборе названий для парной операции создания/удаления объектов.

S>Стейтмент

S>delete a
S>не имеет никакого возвращаемого значения.

Это всего лишь волевое решение. Мог бы и иметь. Никакой беды бы не произошло.

S>Да, он может бросить исключение, или модифицировать глобальную переменную — это неважно. Главное, что этот стейтмент не является выражением. Это чисто императивная конструкция.


А new что, не императивная? Вполне себе императивная. Как fopen().

S>Попробуйте представить, что С++ написан на русском языке и сравните:

S>
S>Экскаватор * мойЭкскаватор = новый Экскаватор();
S>...
S>удалить мойЭкскаватор ;
S>

S>с
S>
S>Экскаватор * мойЭкскаватор = создать Экскаватор();
S>...
S>удалить мойЭкскаватор ;
S>

S>Теперь понятно, почему прилагательное лучше подходит?

Нет. Второй пример лучше. Почему для открытия файла, для создания окна, объекта ядра (мутекс, событие) и проч. прекрасно подходит глагол, а для создания объекта — только прилагательное?

S>Кстати, в другом контексте подойдет именно глагол:

S>
S>Экскаватор * мойЭкскаватор = ФабрикаЭкскаваторов.Создать();
S>


В чем различие контекстов? И там и там создается объект. Кстати, new, если его переопределить, может и не создавать _новый_ объект, а вернуть что-нибудь закэшированнное.

F>>Кстати, то, что delete не имеет возвращаемого значения — это всего лишь волевое решение. Могло бы что-нибудь и возвращаться, и проверяли бы это значение только самые дотошные программисты, из тех, кто проверяет возвращаемое значение printf и close.

S>Если бы возвращал, то и называться мог по другому

Не вижу, как из значения или написания слова "delete" следует отсутствие возвращаемого значения.

F>>Неужели они не удивяться, если символ `+' будет означать вычитание?

S>Что может означать "вычитание" в контексте строк?

Почему строк? Я понял вас так, что вы говорили о "нематематическом контексте", к которому, как я понял, относится программирование. Вот ваши слова:

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


Впрочем, возможно, я вас не так понял. Тем не менее:

Напомню, что коммутативность сложения проходят в школе очень рано, практически одновременно с самим сложением.

F>>Кстати, еще претензия : почему в C++ нельзя опредить произвольный оператор, как в Haskell, а только предопределенный набор?

S>Об этом хорошо написано у Страуструпа в Design and Evolution.

Я бросил читать Страуструпа еще в прошлом веке. Впрочем, я верю, что там есть убедительное обоснование, почему этого никак нельзя было сделать. Тем не менее, как пользователь языков программирования, я вижу: в Haskell и ML произвольный оператор определить можно, и никакой трагедии из этого не делают.
Re[9]: Синтаксический оверхед - Новая порция
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.06.05 11:34
Оценка:
Здравствуйте, faulx, Вы писали:

F>Это всего лишь волевое решение. Мог бы и иметь. Никакой беды бы не произошло.

Тогда бы он, возможно, назывался по другому.
F>Нет. Второй пример лучше.
Ок. Фраза "Отправь по почте создать документ" ухо не режет? В сравнении с "Отправь по почте новый документ"?
F>Почему для открытия файла, для создания окна, объекта ядра (мутекс, событие) и проч. прекрасно подходит глагол, а для создания объекта — только прилагательное?
Гм. А кто сказал, что он прекрасно подходит? Чем создается берклеевский сокет? Учти, что все эти чудесные глаголы жили во времена процедурного программирования. Когда мы открываем файл в стиле nix или winapi, ни о каком создании речь не идет. В OOP мы просим дать нам новый файловый поток.
F>В чем различие контекстов? И там и там создается объект.
Ну и что? выражение new Type() читается "новый экземпляр типа Type". В то время как вызов фабрики является командой "создай новый объект".
F>Кстати, new, если его переопределить, может и не создавать _новый_ объект, а вернуть что-нибудь закэшированнное.
Вот именно. Он возвращает новый объект. Не обязательно создавая eго.
F>Не вижу, как из значения или написания слова "delete" следует отсутствие возвращаемого значения.
F>Впрочем, возможно, я вас не так понял. Тем не менее:
F> Делается неверное умозаключение. Я очень удивлюсь, если сложение будет обозначаться чем-то, кроме +. Однако, из этого не следует, что все "+" — это сложение. Как правило, мозг программиста не настолько забит математикой, чтобы он фанатично требовал от плюса, не обведенного защитным кружочком, коммутативности во всех ситуациях.
Ни разу не видел программиста, ожидавшего от "World!" + "Hello," того же результата, что и "Hello," + "World!". Имхо, проблема является целиком надуманной.
Есть только одна известная мне причина избегать обозначения + для конкатенации — слабая типизация. В VB не стали делать + не от хорошей жизни. Между прочим, там "Hello," + "World!" имеет в точности то же значение, что и в С++. Разница между + и & проявляется при обработке чисел. "5" + "2" вернет "7", тогда как "5" & "2" — "52". В плюсах типизация сильная, неявного приведения строки к числу нет, потому и бояться нечего.
F>Я бросил читать Страуструпа еще в прошлом веке.
Напрасно. Если есть желание понять, что и почему в С++, то имеет смысл почитать первоисточники, а не задавать риторические вопросы в темноту .
F>Тем не менее, как пользователь языков программирования, я вижу: в Haskell и ML произвольный оператор определить можно, и никакой трагедии из этого не делают.
Зато в Haskell и ML нельзя сделать много чего из С++. Нельзя вот так просто брать и переносить что-то из одного языка в другой.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Синтаксический оверхед - Новая порция
От: Трурль  
Дата: 27.06.05 11:40
Оценка:
Здравствуйте, faulx, Вы писали:

F>Нет. Второй пример лучше. Почему для открытия файла, для создания окна, объекта ядра (мутекс, событие) и проч. прекрасно подходит глагол, а для создания объекта — только прилагательное?


Мне кажется, что и для открытия файла, создания окна и т.п. больше подходят прилагательные. А глагол лучще бы смотрелся в контексте
Экскаватор * мойЭкскаватор; 
создать(мойЭкскаватор);

Кстати,

 f:=Files.New();
 f:=Files.Old(fileName);
 t:=Types.This(mod,typeName);
Re[23]: Яркий пример
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 27.06.05 11:41
Оценка:
Здравствуйте, Пацак, Вы писали:

П>Сериозно чтоль?

П>
П>PROCEDURE Test*();
П>VAR  i: INTEGER; END
П>    {тело процедуры начинается здесь}
П>......
П>......
П>    {тело процедуры заканчивается здесь}
П>END Test;
П>

П>И где здесь необходимость использования BEGIN? Нема таковой, окромя продиктованной желанием величественной виртовской левой пятки.

Гениальная идея. Только, тогда придется кроме VAR ... END еще сделать TYPE ... END, и еще CONST ... END. Потом впомнить, что процедуры могут быть вложеными и из вложенной процедуры видны локальные константы, переменные, типы и другие вложенные процедуры процедуры-агрегата, вот на этом месте-то и тормознуться...(где писать ее?)

У меня есть другая идея. Лично я бы вместо слова BEGIN выбрал бы слово CODE — ведь оно обозначает именно начало исполнимого кода, а перед ним была декларация констант, типов, переменных — что не есть исполнимый код.
  PROCEDURE...
    (* декларации констант, типов, переменных и вложенных процедур *)
    CONST ... (* константы *)

    TYPE ... (* типы *) 
   
    VAR ...  (* локальные переменные *)

    PROCEDURE... (* вложенная процедура *)
    ...
    END

  CODE (* вместо слова BEGIN ---> слово CODE *)
    исполнимый код
  END...

Аналогично для тела инициализации модуля. Вот тогда слово BEGIN исчезло бы вовсе.

СГ>>Сам по себе блок BEGIN END отсутсвуют напрочь.


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


Блоки # тело. Вот блоки:
  код...
  BEGIN
    код...
    BEGIN
      код...
    END
    код...
  END
  код...
Re[9]: register
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 27.06.05 12:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>- что компиляторы С умеют выдавать warning на практически все ошибочные ситуации, которые можно только придумать.


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

Вот совсем недавно закончил курсы повышения квалификации "Проектирование систем на DSP процессорах". Так вот в Code Composer Studio от Texas Instruments такая неприятность случилась:

Было
int encode(int sample, struct State &state)
{
  ...
}

я поменял местами аргументы (для красоты — типа в ООП стиле, сначала объект, потом аргументы)
int Encode(struct State &encoder, int sample)
{
  ...
}

Другие слушатели курсов воспользовались моим кодом (свой писать лень было), но у них почему-то программа не правильно работала. Позвали меня спросить почему у меня работает правильно, а у них на выходе какая-то ерунда. Посмотрел, увидел вызов Encode(sample, &encoder) поменял на Encode(&encoder, sample) заработало. А ведь компилировалось не то что без ошибок, а даже без варнингов! И даже выполнялось (не правильно, но выполнялось же)!!!

S>- что на языке С не нужно переупорядочивать программу для того, чтобы компилятор смог сгенерировать оптимальный код


Для этого только надо перед переменной написать слово register... Кстати о размещении наиболее используемых переменных в начале списка переменных — так это про Дельфи. Как там на счет оберонных компиляторов с этим дело обстоит я не знаю.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.