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

N>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек".

А комбинаторика — это что такое?

Здравствуйте, <Аноним>, Вы писали:

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

N>>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек".

А>А комбинаторика — это что такое?

Это то, что важнее и намного нужнее, чем регистронезависимый с++.

Здравствуйте, Аноним, Вы писали:

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

DS>>Здравствуйте, Аноним, Вы писали:

А>>>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>>>#define a A
А>>>#define b B
А>>>#define c C

DS>>Есть вариант чуть лучше:
DS>>

DS>>#define i j
DS>>// I whish You happy debugging
DS>>

А>ага, и вписать это в precompiled headers в какой-нибудь крупный проект — пусть твои последователи разбираются.

А>100% что никто ничего менять не будет, просто будут про это "помнить"
А>

Есть предложение:

#ifdef _DEBUG
#define i j
#else
#define j i
#endif

Здравствуйте, Аноним, Вы писали:

N>>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек".
А>А комбинаторика — это что такое?

Это в юмор. В смысле, весь топик с самого начала...

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

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

AE>>а про +=, ++, *= и проч он не мечтает? я уже молчу про результат операции

E>Это он не заценил. Кстати, у них ведь есть аналоги ++ и --: функции inc() и, если не ошибаюсь, dec()...

E>А насчёт += и т.п.: не все ЦПП программеры их везде используют вместо i = i + ...; (есть примеры). Иногда эти операторы такие глюки делают, что не сразу врубисся, так вот!

Это не операторы глюки делают. А кое-кто другой.

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

Y>скорее всего он *оттуда* пришел

пусть возвращается откуда пришел, там ведь стока преимуществ перед с++:

Автор: AlexEagle
Дата: 18.02.05

Здравствуйте, Аноним, Вы писали:

А>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>#define a A
А>#define b B
А>#define c C

Есть вариант чуть лучше:

#define i j
// I whish You happy debugging

Здравствуйте, Аноним, Вы писали:

А>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>#define a A
А>#define b B
А>#define c C

А>.....


А>Чтобы можно было так писать PRINTF("haha");
Единственное применение — задолбать того кто после тебя будет ЭТО править

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

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

T>>Между прочим на олимпиадах много народу пишет именно на паскале.

AE>Ну правильно, дети вначале на трехколесном учатся ездить а потом на мацацикле

Не совсем. На Паскале/Дельфи труднее сделать плохозаметную ошибку, а цена ошибки на олимпиаде (особенно на ACM'овских) весьма высока.

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

N>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!

А>>#define aa AA

А если еще учесть, что нужно в том числе

#define Aa a
#define aA a

#define PrINtF printf

То останется только один вопрос: где взять такой винт, на который поместится такой .h-ник

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>(в преддверии к переносу в "юмор")
ГВ>Да, ещё нужно заменить { } на begin/end. Э.. вернее, на BEGIN/Begin и END/End

ГВ>Кстати, когда-то так делали отдельные любители. Только для С.

я когда только с паскаля переходил, меня тоже такие мысли посещали

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

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

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


M>>>>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы)
V>>>А в чем разница?

T>>Не функции а процедуры (которые войд) -- они значение не возвращают.
T>>Поэтому при написании while ( dec(i) ) — начнется ругань -- типа тип выражения д.б. boolean.

M>Да? Тогда все даже хуже, чем я думал...
M>Компайцлер magic — хорошо. Нет накладных расходов.
M>Но... значение то в регистре можно вернуть для дальнейшего использования в большом выражении.

M>Да и тогда полного счастья все равно не будет.
M>Ибо для использования в выражении в С есть префиксная форма и постфиксная.

И тем не менее я не знаю кода написанного на c++, который нельзя былобы написать на Делфи. Только с бОльшими трудозатратами.
Поправьте если я неправ.

З.Ы. Не перерастет ли это в очередную священную войну?

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

S>Здравствуйте, llirik, Вы писали:
L>>выглядят как функции, определены в System, так что практически встроены в язык. В связи с последним допустимо, думаю, считать операторами.
S>Более точно этот раздел называется functions requiring compiler magic

Ну, inc/dec — это всего лишь intrinsic functions, такого добра и в С/С++ хватает (например, чтение-запись портов inp(), outp(), да и strlen() может быть запросто).
А вот по-настоящему compiler magic — это паскалевские процедуры writeln, readln и особенно exit.

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

E>Есть предложение:
E>

E>#ifdef _DEBUG
E>#define i j
E>#else
E>#define j i
E>#endif
E>

Но гораздо коварней будет вот так:

 #ifndef _DEBUG
 #define i j
 #endif

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

E>Есть предложение:

E>#ifdef _DEBUG
E>#define i j
E>#else
E>#define j i
E>#endif

Лучше так:

#ifdef _DEBUG
    #undef _DEBUG
#else
    #define _DEBUG
#endif

Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

#define a A
#define b B
#define c C

.....


Чтобы можно было так писать PRINTF("haha");

Здравствуйте, Аноним, Вы писали:

А>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>#define a A
А>#define b B
А>#define c C

А>.....

Этот "ашничек" не поможет написать PRINTF("haha") — PRINTF — undeclared identifier.

Здравствуйте, <Аноним>, Вы писали:

А>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>#define a A
А>#define b B
А>#define c C

А>.....


А>Чтобы можно было так писать PRINTF("haha");

А ты попробуй напиши

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Здравствуйте, Аноним, Вы писали:

А>>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>>#define a A
А>>#define b B
А>>#define c C

А>>.....

АШ>Этот "ашничек" не поможет написать PRINTF("haha") — PRINTF — undeclared identifier.

Последняя строка не
#define z Z
Далее идет
#define aa AA
и.т.д

в том числе и
#define printf PRINTF

Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Анатолий Широков, Вы писали:

АШ>>Здравствуйте, Аноним, Вы писали:

А>>>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>>>#define a A
А>>>#define b B
А>>>#define c C

А>>>.....

АШ>>Этот "ашничек" не поможет написать PRINTF("haha") — PRINTF — undeclared identifier.

А>Последняя строка не
А>#define z Z
А>Далее идет
А>#define aa AA
А>и.т.д

А>в том числе и
А>#define printf PRINTF

Здравствуйте, Аноним, Вы писали:

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

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

AE>Здравствуйте, Аноним, Вы писали:

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

скорее всего он *оттуда* пришел

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

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

AE>>Здравствуйте, Аноним, Вы писали:

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

Y>скорее всего он *оттуда* пришел

(в преддверии к переносу в "юмор")
Да, ещё нужно заменить { } на begin/end. Э.. вернее, на BEGIN/Begin и END/End

Кстати, когда-то так делали отдельные любители. Только для С.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Да, ещё нужно заменить { } на begin/end. Э.. вернее, на BEGIN/Begin и END/End
ГВ>Кстати, когда-то так делали отдельные любители. Только для С.

Ха-ха, ирония судьбы: знакомый программер на Delphi мечтает чтоб вместо begin/end были { и }, а то типа печатать долго...

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

E>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Да, ещё нужно заменить { } на begin/end. Э.. вернее, на BEGIN/Begin и END/End
ГВ>>Кстати, когда-то так делали отдельные любители. Только для С.

E>Ха-ха, ирония судьбы: знакомый программер на Delphi мечтает чтоб вместо begin/end были { и }, а то типа печатать долго...

а про +=, ++, *= и проч он не мечтает? я уже молчу про результат операции

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

AE>а про +=, ++, *= и проч он не мечтает? я уже молчу про результат операции

Это он не заценил. Кстати, у них ведь есть аналоги ++ и --: функции inc() и, если не ошибаюсь, dec()...

А насчёт += и т.п.: не все ЦПП программеры их везде используют вместо i = i + ...; (есть примеры). Иногда эти операторы такие глюки делают, что не сразу врубисся, так вот!

Ну вот, дошутились

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

E>Это он не заценил. Кстати, у них ведь есть аналоги ++ и --: функции inc() и, если не ошибаюсь, dec()...

Ага, аналоги, типа while( Dec( i ) ) можно написать

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

N>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!

предлагаю такой вариант — проект писать с использованием этого хидера,
заказчикам отдавать без него

типа, обфускатор

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

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

AE>>а про +=, ++, *= и проч он не мечтает? я уже молчу про результат операции

E>Это он не заценил. Кстати, у них ведь есть аналоги ++ и --: функции inc() и, если не ошибаюсь, dec()...

E>А насчёт += и т.п.: не все ЦПП программеры их везде используют вместо i = i + ...; (есть примеры). Иногда эти операторы такие глюки делают, что не сразу врубисся, так вот!

inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы) со всеми вытекающими накладнами расходами.
Я понимаю, есть всякие птимизующие компиляторы, но насколько я заню, дельфино к ним не относится.

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

E>>А насчёт += и т.п.: не все ЦПП программеры их везде используют вместо i = i + ...; (есть примеры). Иногда эти операторы такие глюки делают, что не сразу врубисся, так вот!
__>Это не операторы глюки делают. А кое-кто другой.

Ну почему чуть что — сразу программист?

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

DS>Здравствуйте, Аноним, Вы писали:

А>>Как вы думаете имеет ли какое-либо практическое применение такой ашничек:

А>>#define a A
А>>#define b B
А>>#define c C

DS>Есть вариант чуть лучше:
DS>

DS>#define i j
DS>// I whish You happy debugging
DS>

ага, и вписать это в precompiled headers в какой-нибудь крупный проект — пусть твои последователи разбираются.

100% что никто ничего менять не будет, просто будут про это "помнить"

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Ну почему чуть что — сразу программист?

все та же статистика...

Правда когда я программировал на реализации с++ в CA Visual Objects, там статистика была в пользу программиста, что приводило к тому что порой все ошибки просто списывались на среду разработки

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

M>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы) со всеми вытекающими накладнами расходами.

выглядят как функции, определены в System, так что практически встроены в язык. В связи с последним допустимо, думаю, считать операторами.

M>Я понимаю, есть всякие птимизующие компиляторы, но насколько я заню, дельфино к ним не относится.

слишком ты критичен к делфи, скорее предубежден . Никаких накладных расходов:

inc(1) есть просто inc eax, 1 к примеру (ну и где тут накладные расходы)

посмотри на генерируемый код для инструкции case, разве там плохая оптимизация?

Здравствуйте, llirik, Вы писали:
L>выглядят как функции, определены в System, так что практически встроены в язык. В связи с последним допустимо, думаю, считать операторами.
Более точно этот раздел называется functions requiring compiler magic

M>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы)
А в чем разница?

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


M>>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы)
V>А в чем разница?

Не функции а процедуры (которые войд) -- они значение не возвращают.
Поэтому при написании while ( dec(i) ) — начнется ругань -- типа тип выражения д.б. boolean.

Здравствуйте, Аноним, Вы писали:

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

N>>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!

А>предлагаю такой вариант — проект писать с использованием этого хидера,
А>заказчикам отдавать без него

А>типа, обфускатор

Какой-такой обфускатор ? Лечится скриптом из 2х строк.

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

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


M>>>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы)
V>>А в чем разница?

T>Не функции а процедуры (которые войд) -- они значение не возвращают.

К сожалению это справедливо для всех небулевых операторов паскаля Поэтому в данном случае разница между dec и оператором чисто формальная (операторы как правило обозначаются небуквами, ну кроме is, in, and, not и проч)

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

N>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!
{...}

От себя добавлю
Если в коде будет хотябы одна переменная длиной 20, то
количество вариантов ее записи будет равно 2^20

длина строки определения
#define Abcdefghijklmnopqrst abcdefghijklmnopqrst равна 50 символов
Соответственно при описании в ашке только этой переменной ашка выйдет больше чем 50 метров!!!!

так что дефайны здесть не помощник.

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

E>Есть предложение:
E>

E>#ifdef _DEBUG
E>#define i j
E>#else
E>#define j i
E>#endif
E>

Вот это талант, вот это полет мысли, гигант ! Уважаю

Но для тех кто хочет добиться регистронезависимости на с++ могу предложить CA Visual Objects.... там кстати вышеописанный код дефайнов и много другого прекрасного, рандомного уже встроены в систему

как советует мой коллега, на линуксе в компайлер с++ можно добавить UPPERCASE при синтаксическом разборе — вот тут уж что-то да получится

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

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


M>>>inc() и dec() — это, как справедливо отмечено, не операторы, а ФУНКЦИИ (подпрограммы)
V>>А в чем разница?

T>Не функции а процедуры (которые войд) -- они значение не возвращают.
T>Поэтому при написании while ( dec(i) ) — начнется ругань -- типа тип выражения д.б. boolean.

Да? Тогда все даже хуже, чем я думал...
Компайцлер magic — хорошо. Нет накладных расходов.
Но... значение то в регистре можно вернуть для дальнейшего использования в большом выражении.

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

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

T>И тем не менее я не знаю кода написанного на c++, который нельзя былобы написать на Делфи. Только с бОльшими трудозатратами.
T>Поправьте если я неправ.

Дальше лучше — я не знаю такого кода на с++ который нельзя было бы переписать на асме (вариант, на машинных кодах ). Про трудозатраты молчу.

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

T>З.Ы. Не перерастет ли это в очередную священную войну?

Там и так мусора хватает... А из юмора по-моему еще никто не уходил

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

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

N>>Теперь вспомни комбинаторику и посчитай какого размера будет этот "ашничек". Как бы компилятор у тебя не подавился!!!
T>{...}

T>От себя добавлю
T>Если в коде будет хотябы одна переменная длиной 20, то
T>количество вариантов ее записи будет равно 2^20

Что то не так с комбинаторикой
Английских символов 27, плюс 10 символов цифр, плюс другие символы, в итоге как минимум 37.
С учетом регистра 37+20 = 57.
Переменную из 20 символов можна записать 57^20 способов

T>И тем не менее я не знаю кода написанного на c++, который нельзя былобы написать на Делфи. Только с бОльшими трудозатратами.
T>Поправьте если я неправ.
T>З.Ы. Не перерастет ли это в очередную священную войну?

Не, не перерастет. Знаешь почему?
Во-первых, посмтри, в каком форуме мы находимся. :-D
Во-вторых, ты не указал, где больше будет трудозатрат — на дельфи или на сях.
пооэтому щас пойдет 2 ветки —
одна про то, почему на дельфи трудозатраты будут меньше,
другая про то, почему
и обе будут соглашаться с твоей фразой о различии величины трудозатрат ;-D

----
"Все суета и асимметричный дуализм языкового знака."
(c) Белое Безмозглое "Между двух стульев" Клюев &&over (c) Фердинанд де Соссюр.

Слегка ошибся
С учетом регистра 37+27 = 64.
Переменную из 20 символов можна записать 64^20 способов

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

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

T>>И тем не менее я не знаю кода написанного на c++, который нельзя былобы написать на Делфи. Только с бОльшими трудозатратами.
T>>Поправьте если я неправ.

AE>Дальше лучше — я не знаю такого кода на с++ который нельзя было бы переписать на асме (вариант, на машинных кодах ). Про трудозатраты молчу.

Затраты больше процентов на 50, ну в крайнем случае на 100.
Когда мне надо написать что-нить простенькое получасовое, я обычно пишу на делфе.
Между прочим на олимпиадах много народу пишет именно на паскале.

AE>Но ведь в чем преимущество — в низких трдозатратах и в гибкости используемого инструментария для выбранной задачи... Именно поэтому разные задачи решают разными инструментальными средствами

А я и не спорю

T>>З.Ы. Не перерастет ли это в очередную священную войну?

AE>Там и так мусора хватает... А из юмора по-моему еще никто не уходил

2аффтор: ИМХО различимость регистров программированию на с++ совсем не мешает, даже наоборот, приучает к нормальному оформлению кода.

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

MS>Слегка ошибся

Не думаю, с математикой я вроде дружу

MS>С учетом регистра 37+27 = 64.
MS>Переменную из 20 символов можна записать 64^20 способов

Я так понимаю надо поподробнее:

#define abC abc
#define aBc abc
#define aBC abc
#define Abc abc
#define AbC abc
#define ABc abc
#define ABC abc

для слова длиной 3 надо 2^3 — 1

Трохан обшибся, надо не 2^20 а 2^20 — 1 вариантов -- саму переменную дефайнить не надо

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


T>>И тем не менее я не знаю кода написанного на c++, который нельзя былобы написать на Делфи. Только с бОльшими трудозатратами.
T>>Поправьте если я неправ.
T>>З.Ы. Не перерастет ли это в очередную священную войну?

M>Не, не перерастет. Знаешь почему?
M>Во-первых, посмтри, в каком форуме мы находимся. :-D
M>Во-вторых, ты не указал, где больше будет трудозатрат — на дельфи или на сях.
M> пооэтому щас пойдет 2 ветки —
M> одна про то, почему на дельфи трудозатраты будут меньше,
M> другая про то, почему
M> и обе будут соглашаться с твоей фразой о различии величины трудозатрат ;-D

M>----
M>"Все суета и асимметричный дуализм языкового знака."
M>(c) Белое Безмозглое "Между двух стульев" Клюев &&over (c) Фердинанд де Соссюр.

Просто может получиться так, что беседа о регистронезависимом с++ плавно перетечет в спор Delphi vs C++

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

T>Между прочим на олимпиадах много народу пишет именно на паскале.

Ну правильно, дети вначале на трехколесном учатся ездить а потом на мацацикле

T>2аффтор: ИМХО различимость регистров программированию на с++ совсем не мешает, даже наоборот, приучает к нормальному оформлению кода.

Не вопрос! Согласен на все 100! Но я просто пытался предложить решение на заданный вопрос..

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

AE>>Ну правильно, дети вначале на трехколесном учатся ездить а потом на мацацикле

DK>Не совсем. На Паскале/Дельфи труднее сделать плохозаметную ошибку, а цена ошибки на олимпиаде (особенно на ACM'овских) весьма высока.

Смотря на чем до этого программировал... Я например регулярно после с++ наступаю на грабли с inherited Destroy

MS>>С учетом регистра 37+27 = 64.
MS>>Переменную из 20 символов можна записать 64^20 способов

T>Я так понимаю надо поподробнее:
T>

T>#define abC abc
T>#define aBc abc
T>#define aBC abc
T>#define Abc abc
T>#define AbC abc
T>#define ABc abc
T>#define ABC abc
T>

T>для слова длиной 3 надо 2^3 — 1

T>Трохан обшибся, надо не 2^20 а 2^20 — 1 вариантов -- саму переменную дефайнить не надо

Да, я написал не то.
Почему то думал про другую задачу.

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

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

AE>>>Ну правильно, дети вначале на трехколесном учатся ездить а потом на мацацикле

DK>>Не совсем. На Паскале/Дельфи труднее сделать плохозаметную ошибку, а цена ошибки на олимпиаде (особенно на ACM'овских) весьма высока.

AE>Смотря на чем до этого программировал... Я например регулярно после с++ наступаю на грабли с inherited Destroy

Я думаю, на олимпиаде у тя подобных проблем не возникнет
И еще один довод в пользу того, что в некоторых сферах применения (на тех же олимпадах) Object pascal рулит --
он намного легче чем С++. Хотя согласен некоторые тривиальные в С++ вещи на паскале надо писать через одно общеизвестное место.

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

DK>Не совсем. На Паскале/Дельфи труднее сделать плохозаметную ошибку, а цена ошибки на олимпиаде (особенно на ACM'овских) весьма высока.

И тем не менее, на мировых финалах ACM ICPC от Паскаля уже отказываются.
Головоломные констуркции языка на олимпиадах не используются, так что тут, имхо, все решает практика — кому на чем удобнее. Мы писали (и будем писать, если повезет ) на C++ — и никаких проблем со стороны языка не испытывали.

Здравствуйте, Кодт, Вы писали:
К>Ну, inc/dec — это всего лишь intrinsic functions, такого добра и в С/С++ хватает (например, чтение-запись портов inp(), outp(), да и strlen() может быть запросто).
К>А вот по-настоящему compiler magic — это паскалевские процедуры writeln, readln и особенно exit.
А как же break и continue? Вот ужо где бубен-то зарыт! Всегда хотел получить их адрес.

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

К>>Ну, inc/dec — это всего лишь intrinsic functions, такого добра и в С/С++ хватает (например, чтение-запись портов inp(), outp(), да и strlen() может быть запросто).
К>>А вот по-настоящему compiler magic — это паскалевские процедуры writeln, readln и особенно exit.
S>А как же break и continue? Вот ужо где бубен-то зарыт! Всегда хотел получить их адрес.

Да-да-да!
Я уже подзабыл паскаль — мне казалось, что в дельфях это уже ключевые слова; а в старом добром TP это действительно распарсивалось как процедуры без параметров.

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

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

--skip--

T>Затраты больше процентов на 50, ну в крайнем случае на 100.
T>Когда мне надо написать что-нить простенькое получасовое, я обычно пишу на делфе.
T>Между прочим на олимпиадах много народу пишет именно на паскале.

Хотел бы я посмотреть, как на базовой реализации паскаля в условиях олимпиады
(критично время, отсутствует возможность пользоваться своими старыми наработками.либами)
Вы напишете, например, программку для матричных вычислений... для больших матриц...
и для очень больших...
А возвращаясь к топику — году в 1993-м, примерно, в одной и софтпанорам был весьма
забавный хидер, после подключения которого можно было писать на C используя Великий
и Могучий в наиболее народной его версии.

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

N> Но гораздо коварней будет вот так:

N>

N> #ifndef _DEBUG
N> #define i j
N> #endif
N>

Тогда ещё коварнее и непонятнее:

#ifndef _DEBUG
#define i (++i)
#define j (--j)
#endif

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

E>Тогда ещё коварнее и непонятнее:
E>

E>#ifndef _DEBUG
E>#define i (++i)
E>#define j (--j)
E>#endif
E>

E>

Ой блин, гоню. Определять то как?