Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Тпру Касте Оберонопочитателей напоминаю, что я ни против Оберона, ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и я" ), так что иронию можно перенацелить на кого-нибудь более враждебно настроенного. В данном случае мне было, действительно, интересно, как же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не написали объявление функции, а не чтобы задеть
Ну, виноват, прости мерзавца...
Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на глаз и на ощупь.
ПК>Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.): ПК>
Буду думать.
(Надеюсь, никто не ожидает, что я "рожу" архитектуру глобальной библиотеки в пятиминутном перекуре? )
ПК> ПК>(*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил
Неправда!
Я хороший! Просто строчку забыл напечатать, а компилятор сильно типизированного языка Си++ и так "сжевал", вот я и не заметил. Должно было быть примерно так:
#include <fstream>
#include <list>
using namespace std;
ifstream dataFile("ints.dat");
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
int main()
{
return 0;
}
Две строки (ifstream и list<int>) позаимствованы у Мейерса ("Эффективное использование STL", совет 6).
Там он пишет:
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> ПК> Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.): > ПК>
AVC пишет:
> ПК>Тпру Касте Оберонопочитателей напоминаю, что я ни против Оберона, > ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и > я" ), так что иронию можно перенацелить на кого-нибудь более враждебно > настроенного. В данном случае мне было, действительно, интересно, как > же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не > написали объявление функции, а не чтобы задеть > Ну, виноват, прости мерзавца... > Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь > белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на > глаз и на ощупь.
Да я понял. Я вроде бы никогда не утверждал, что С++ — это простой язык Но фичастый — это точно.
Здравствуйте, Cyberax, Вы писали:
>> Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь >> белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на >> глаз и на ощупь. C>Да я понял. Я вроде бы никогда не утверждал, что С++ — это простой язык C> Но фичастый — это точно.
Я не со зла.
Просто хотелось так: Cyberax попадается в ловушку, тут появляюсь я и грозно спрашиваю:
Ну, теперь понял, что я имею в виду?
Но тут пришел Павел Кузнецов и весь праздник испортил.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
>> (Надеюсь, никто не ожидает, что я "рожу" архитектуру глобальной библиотеки в пятиминутном перекуре? ) ПК>Ессно. Я просто думал, что там уже есть какой-то готовый аналог.
Я сначала проверил.
Посмотрел ETH Oberon, XDS, BlackBox.
Прямого аналога нет, вообще все строится по другому. (Это, в общем-то и интересно.)
Затем сделал пару набросков на Обероне.
Обобщенный код получить можно, но надо продумывать иерархию классов, а я что-то не в духе сегодня.
В общем, мне не понравилось.
А в конце, естественно: да что я вам — Пушкин, что ли?!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
К>>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.
AVC>Так ведь и платим! Вон уже сколько гигабайт требуется на винте.
Знаешь, вот если я не использую буст в своём проекте, то обновление буста никак не отразится на скорости компиляции. Да и вообще ставить его не придётся.
Не хочешь, не плати.
Здравствуйте, Cyberax, Вы писали:
C>Сергей Губанов пишет:
>> КЕ>Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит № >> четыре миллиарда? >> Нет, не будет. Хотя сам язык этого не запрещает. Все дело в реализации. >> Реализация BlackBox 1.5 дает следующее: >> MIN(SET) = 0 >> MAX(SET) = 31 >> (MIN, MAX — стандартные процедуры-функции)
C>Удивительно болшое множество....
Здравствуйте, Кодт, Вы писали:
К>А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.
Ответ прост:
Множество (SET) — есть скалярный тип, такой же элементарный как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе скалярный, но используемый как контейнер.
Комплексные числа, кватернионы, матрицы, векторы и т. п. — компонентные объекты (составные) не скалярные.
Hello, Сергей!
You wrote on Fri, 18 Feb 2005 11:01:50 GMT:
СГ> Ответ прост: СГ> Множество (SET) — есть скалярный тип, такой же элементарный СГ> как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква СГ> (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним СГ> можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или СГ> p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе СГ> скалярный, но используемый как контейнер. Комплексные числа, СГ> кватернионы, матрицы, векторы и т. п. — компонентные объекты СГ> (составные) не скалярные.
А мне, как программисту, какая, нафиг разница, составные там объекты или
цельнокованные? Собственно, составные даже удобнее — от них наследоваться
можно.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Сергей Губанов, Вы писали:
К>>Даже в Turbo Pascal 3 было 256... СГ>Зато работает быстрее, т.к. 256 битов в одном регистре не убираются, а 32 бита убираются.
Если в паскале указать set of 0..31, то тоже в дворд влезет
На самом деле, после прочтения статьи Вирта, я понял, зачем так сделано.
Поддержка битовых флагов — конечно, нужна; но обобщать её до set of any_range — это большие накладные расходы:
1) либо всё впихивается во всеобъятный set of byte, — оверхед по памяти и по обработке,
2) либо создаётся семейство безымянных типов — диапазоны/перечисления и множества над ними — а это усложнение компилятора
Поэтому общепринятые 32-битные флаги, оформленные как отдельный тип — это такой хороший компромисс.
Теперь вместо булевой алгебры над числами как битовыми векторами (сишные &, |, ^, ~ и соответствующие паскалевские операции) используются эквивалентные теоретико-множественные действия — это, как правило, нагляднее, а значит, и ошибкоустойчивее.
Ну а реализация действительно больших множеств — это предмет исследования в каждом конкретном случае.
Битовый вектор — ARRAY(n) OF SET — одно из возможных, но необязательно самое эффективное представление. Например, если универсум — это все целые числа, то размер такого вектора будет 2^29 байт. Восемь векторов, и адресное пространство кончилось
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Кодт, Вы писали:
К>>А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.
СГ>Ответ прост: СГ> Множество (SET) — есть скалярный тип, такой же элементарный как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе скалярный, но используемый как контейнер. СГ> Комплексные числа, кватернионы, матрицы, векторы и т. п. — компонентные объекты (составные) не скалярные.
Множество как математическая абстракция — это не скалярный тип.
SET — это очень узкий случай множества {0..31}, сделанный элементарным.
Точно так же, целые числа без ограничений разрядности могут быть (LISP, Python), а могут не быть (Smalltalk, C++) элементарным типом. А целые числа небольшой разрядности (приемлемой для большинства платформ — скажем, 32 или 64 бита) — элементарный тип.
Комплексные числа — могут быть элементарным типом (Fortran, MatLab), а могут реализовываться как составные (C++).
Кватернионы и 3-мерные аффиноры тоже могли бы быть элементарным типом, если бы встречались достаточно часто.
P.S.
Понимая глубинную суть языка (С++, Оберон и т.д.), не надо сужать горизонт только до него одного.
Самое интересное начинается на границе и за границей познанного
Здравствуйте, Cyberax, Вы писали:
C>То есть, если пользователь Вася загрузит модуль "Photoshop", то C>пользователь Петя уже не сможет его загрузить?
C>Или Оберон — исключительно однопользовательский?
Здравствуйте, Cyberax, Вы писали:
C>Удивительно болшое множество.... СГ> Ни что мешает сделать так: >> >>TYPE >> BigSet = ARRAY 1000000 OF SET; >> C>А чем это лучше
int arr[100000];
? И как будут выглядеть C>операции над таким составным множеством?
Примерно так:
DEFINITION BitSets;
TYPE
BitSet* = RECORD
size-: INTEGER; (** число элементов в битовом множестве *)PROCEDURE (VAR set: BitSet) Init*(size: INTEGER);
PROCEDURE (VAR set: BitSet) Incl*(bit: INTEGER);
PROCEDURE (VAR set: BitSet) Excl*(bit: INTEGER);
END;
END BitSets.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Кодт, Вы писали:
К>>>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить. AVC>>Так ведь и платим! Вон уже сколько гигабайт требуется на винте. К>Знаешь, вот если я не использую буст в своём проекте, то обновление буста никак не отразится на скорости компиляции. Да и вообще ставить его не придётся. К>Не хочешь, не плати.
Я (как программист) могу и не использовать boost.
Я его и не использую. Не по каким-то принципиальным соображениям (например, boost::shared_ptr<T> я, в отстутствие GC, не прочь использовать), а просто нет необходимости. Это отдельный пункт — почему в таких важных супербиблиотеках нет большой практической необходимости?
Но (как пользователь) замечу, что многие программы слишком велики по размерам, неадекватно их функциональности. А раз так, то мне требуется новый большой "винт". Т.е. я все-таки плачу (как пользователь), за некоторые технологии создания ПО.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
То есть, мы перестаём мучаться и извращаться с базовыми типами, и делаем нормальный класс с нормальными методами.
ООП рулит
Тут я хочу заметить некую фишку:
— процедурное программирование — создаём операции над голыми типами (элементарными или составными); применяя разрешённый набор операций, мы сохраняем целостность модели; но помимо разрешённых (введённых нами + некое подмножество присущих языку и рантайму) можно по глупому или злому умыслу применять и другие.
— ООП — операции суть неотъемлимые свойства объектов; за счёт инкапсуляции невозможно получить злодейский доступ к голым данным.
Указатели и массивы — это голые типы; возможность misuse/abuse их необычайна (особенно в С++, где есть прямой доступ к памяти; хотя и в Обероне, и в Васике можно разломать программу на логическом уровне).
Такова цена, которую программист платит за язык, совмещающий несколько парадигм одновременно (процедурное + ООП).
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Ни что мешает сделать так: СГ>
СГ>TYPE
СГ> BigSet = ARRAY 1000000 OF SET;
СГ>
Только еще бы "завернуть" в класс.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Кодт, Вы писали:
К>- процедурное программирование — создаём операции над голыми типами (элементарными или составными); применяя разрешённый набор операций, мы сохраняем целостность модели; но помимо разрешённых (введённых нами + некое подмножество присущих языку и рантайму) можно по глупому или злому умыслу применять и другие. К>- ООП — операции суть неотъемлимые свойства объектов; за счёт инкапсуляции невозможно получить злодейский доступ к голым данным.
Полностью согласен.
Хотя, наверное, здесь каждый согласится.
Я так и рассматриваю класс как способ реализовать АТД, а АТД как некую математическую модель.
В полном соответствии с учебником Ахо, Хопкрофта и Ульмана.
Строить программы таким способом — кайф!
Но вот беда с языками. У одного одни недостатки, у второго — другие.
К>Указатели и массивы — это голые типы; возможность misuse/abuse их необычайна (особенно в С++, где есть прямой доступ к памяти; хотя и в Обероне, и в Васике можно разломать программу на логическом уровне).
Увы...
К>Такова цена, которую программист платит за язык, совмещающий несколько парадигм одновременно (процедурное + ООП).
Следует ли это понимать как апологию Смоллтока?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
> Я (как программист) могу и не использовать boost. > Я его и не использую. Не по каким-то принципиальным соображениям > (например, boost::shared_ptr<T> я, в отстутствие GC, не прочь > использовать), а просто нет необходимости.
Это только кажется.
> Это отдельный пункт — почему в таких важных супербиблиотеках нет > большой практической необходимости?
Speak for yourself... У меня практическая необходимость уже где для 40%
буста
> Но (как пользователь) замечу, что многие программы слишком велики по > размерам, неадекватно их функциональности. А раз так, то мне требуется > новый большой "винт". Т.е. я все-таки плач*у* (как пользователь), за > некоторые технологии создания ПО.
А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место
на диске.
Касте Оберонопочитателей напоминаю, что я ни против Оберона, ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и я" 
), так что иронию можно перенацелить на кого-нибудь более враждебно настроенного. В данном случае мне было, действительно, интересно, как же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не написали объявление функции, а не чтобы задеть 
Перекуём баги на фичи!
