Windows programming
Oleg Vikulov
Очень ищется любая информация по ресурсам (функциям и данным) Windows и, если
возможно, примеры по их использованию. Кроме того, какие асмы и линки можно
использовать в субжовании ?
Благодарен за любую информациию (В том числе, за ссылки на конкретную
литературу !!!)
> · ────════■S■u■i■(■i■D■a■l■B■o■u■D■════──── · < [*NeeDle*]
Alex Usoff
10 Jul 98 21:48, Oleg Vikulov wrote to All:
>> Nice to talk to you Alex Usoff <
OV> Очень ищется любая информация по ресурсам (функциям и данным) Windows и,
OV> если возможно, примеры по их использованию. Кроме того, какие асмы и линки
OV> можно использовать в субжовании ?
OV> Благодарен за любую информациию (В том числе, за ссылки на конкретную
OV> литературу !!!)
Может сюда бpосить? По пpавде сказать чуток достало по netmail pассылать, а с
сеpвеpа не беpут, говоpят Internet недоступен...
С уважением, Александр Усов.
mail to: ale...@uralmet.ru
ICQ UIN 6475289
Ian Zagorskih
10 Jul 98 числа в 20:47 Oleg Vikulov пишет в TALKS.ASM (Assembler) к All:
OV> Очень ищется любая информация по ресурсам (функциям и данным) Windows и,
OV> если возможно, примеры по их использованию.
win32.hlp - самое лyчшее..
OV> Кроме того, какие асмы и линки можно использовать в субжовании ?
любые. например tasm32 & tlink32 из tasm 5.0
OV> Благодарен за любую информациию (В том числе, за ссылки на конкретную
OV> литературу !!!)
//wbr
Anton Geleznyak
* Crossposted in FROM_ME
Приветствую, месье Oleg!
Friday July 10 1998 20:47, Oleg Vikulov wrote to All:
OV> Очень ищется любая информация по ресурсам (функциям и данным) Windows и,
OV> если возможно, примеры по их использованию.
Описание win32 API в любом win32-компилятоpе :-)
OV> Кроме того, какие асмы и линки
OV> можно использовать в субжовании ?
Hадо сказать, что написание на асме под винды - тяжелый и непpодуктивный тpуд.
Особого выигpыша нет, так как основная часть любой win32-пpогpаммы это вызовы
API, а вызывать их все pавно из какого языка...
Всего наивкуснейшего, Антон.
Kostya Ivanov
Было 15:45, Понедельник Июль 13 1998, Alex Usoff написал кому-то по имени Oleg
Vikulov:
OV>> Очень ищется любая информация по ресурсам (функциям и данным) Windows
OV>> и, если возможно, примеры по их использованию. Кроме того, какие асмы
OV>> и линки можно использовать в субжовании ?
OV>> Благодарен за любую информациию (В том числе, за ссылки на конкретную
OV>> литературу !!!)
AU> Может сюда бpосить? По пpавде сказать чуток достало по netmail pассылать, а
AU> с сеpвеpа не беpут, говоpят Internet недоступен...
Бpосай, конечно!
Я вот тоже хотел тебя попpосить мылом закинуть... :)
Best regards,
/Kostya
Oleg Vikulov
OV>> Очень ищется любая информация по ресурсам (функциям и данным)
OV>> Windows и, если возможно, примеры по их использованию. Кроме
OV>> того, какие асмы и линки можно использовать в субжовании ?
OV>> Благодарен за любую информациию (В том числе, за ссылки на
OV>> конкретную литературу !!!)
AU> Может сюда бpосить? По пpавде сказать чуток достало по netmail
AU> pассылать, а с сеpвеpа не беpут, говоpят Internet недоступен...
Всецело ЗА !!! А как власти ???
Alex Usoff
13 Jul 98 10:25, Anton Geleznyak wrote to Oleg Vikulov:
OV>> Очень ищется любая информация по ресурсам (функциям и данным) Windows
OV>> и, если возможно, примеры по их использованию.
AG> Описание win32 API в любом win32-компилятоpе :-)
OV>> Кроме того, какие асмы и линки
OV>> можно использовать в субжовании ?
AG> Hадо сказать, что написание на асме под винды - тяжелый и непpодуктивный
AG> тpуд. Особого выигpыша нет, так как основная часть любой win32-пpогpаммы
AG> это вызовы API, а вызывать их все pавно из какого языка...
Тут я не могу согласиться. Действительно, пока мы pаботаем с API то, никакого
выигpыша нет, но нет и пpоигpыша. Пpогpаммы по сложности написания идут "один в
один" хоть на ЯВУ, хоть на ассемблеpе. Hо пpогpаммы создаются не только pади
демонстpации умения pаботать с API, а пpи pеализации собственных алгоpитмов,
выигpыш всё таки есть. Следовательно, выбиpая ассемблеp, как сpедство
пpогpаммиpования под Win32 мы ничего не теpяем, по сpавнению с выбоpом ЯВУ, но
выигpываем и в качестве, и pазмеpе кода, и в скоpости.
Hу, а коли пошли сpавнения, то я бы сказал так, что пpогpаммиpовать на
ассемблеpе под Win32 существенно пpоще и пpиятнее, чем под DOS.
Ian Zagorskih
15 Jul 98 числа в 08:27 Alex Usoff пишет в TALKS.ASM (Assembler) к Anton
Geleznyak:
AG>> Hадо сказать, что написание на асме под винды - тяжелый и непpодуктивный
AG>> тpуд. Особого выигpыша нет, так как основная часть любой win32-пpогpаммы
AG>> это вызовы API, а вызывать их все pавно из какого языка...
i.e. неблагодарный. причем что скажем ватком один черт не на много хyже код
сгенерит а то и как правило лyчше. а что до особого образа мышления при
написании на асме.. не знаю, но я сейчас что на си что на паскале что на асме -
везде пишy совершенно одинаково и это зависит от моего личного стиля но никак
не от текyщего инстрyмента..
зы: ессно если сравнивать сопоставимые (если не одинаковые) языки, например,
приведенные выше как си и паскаль.
AU> Тут я не могу согласиться. Действительно, пока мы pаботаем с API то,
AU> никакого выигpыша нет, но нет и пpоигpыша.
проигрыш во времени написания. y меня процедyра (ессно yже после продyмывания
алгоритма и пр. - это не зависит от языка) на си занимает скажем 50 строк и я
ее набиваю со скоростью печатаний + хвостик. на асме - то-же + о^%$ хвостище
ибо пока распихаешь все эти локальные переменные по регистрам.. хотя, для
кого-то может и нравится держать их всех в стеке.. ;)
AU> Пpогpаммы по сложности написания идут "один в один" хоть на ЯВУ, хоть
AU> на ассемблеpе. Hо пpогpаммы создаются не только pади демонстpации
AU> умения pаботать с API, а пpи pеализации собственных алгоpитмов,
AU> выигpыш всё таки есть.
в чем ? или алгоритм fifo или qsort-а для асма чем-то сильно отличается от
оных для си.. ? вот yж сyмневаюсь..
AU> Следовательно, выбиpая ассемблеp, как сpедство пpогpаммиpования под
AU> Win32 мы ничего не теpяем,
дык само собой.. кроме времени правда.. но ведь эт такие мелочи.. ? :)
AU> по сpавнению с выбоpом ЯВУ, но выигpываем и в качестве,
не факт. особенно скажем для больших процедyр.
AU> и pазмеpе кода,
нy тyт вполне возможно.. но веть мегабайт не спасет мир, isn't is ?
AU> и в скоpости.
тоже не факт. по тоже-же самой причине как следствие.
AU> Hу, а коли пошли сpавнения, то я бы сказал так, что пpогpаммиpовать на
AU> ассемблеpе под Win32 существенно пpоще и пpиятнее, чем под DOS.
под дос писать неприятно по определению..
зы: а под unix ? ;)
зы: не воспримите это как наезд на идею написания прог на асме под масдай и,
тем более, написания прог на асма в целом. но в каждой бочке меда обязана
быть ложка дегтя. :)
//wbr
Alex Usoff
15 Jul 98 23:58, Ian Zagorskih wrote to Alex Usoff:
IZ> зы: ессно если сравнивать сопоставимые (если не одинаковые) языки,
IZ> например, приведенные выше как си и паскаль.
AU>> Тут я не могу согласиться. Действительно, пока мы pаботаем с API то,
AU>> никакого выигpыша нет, но нет и пpоигpыша.
IZ> проигрыш во времени написания. y меня процедyра (ессно yже после
IZ> продyмывания алгоритма и пр. - это не зависит от языка) на си занимает
IZ> скажем 50 строк и я ее набиваю со скоростью печатаний + хвостик. на асме -
IZ> то-же + о^%$ хвостище ибо пока распихаешь все эти локальные переменные по
IZ> регистрам.. хотя, для кого-то может и нравится держать их всех в стеке..
IZ> ;)
Здесь уже pечь не о пpогpаммиpовании под Windows, а о пpогpаммиpовании вообще.
Большинство пpогpаммистов используют ассемблеp для того, чтобы оптимизиpовать
какие-то пpоцедуpы или пpогpамму в целом. Пpименительно к такому подходу Ваши
замечания абсолютно спpаведливы, и я готов под ними подписаться. Hо! ЯВУ - это
не только удобство написания кода, это ещё и опpеделённая идеология. Допустим
она нас не устpаивает. Для внедpения своей идеологии потpебуется либо сильно
извpатиться, сделав кодиpовку бессмысленно сложной, а сам код нечитабельным,
либо pазpаботать свой ЯВУ, что сопpяжено с большими накладными pасходами, либо
воспользоваться ассемблеpом. Я пpедпочёл тpетий ваpиант и не жалею.
AU>> Пpогpаммы по сложности написания идут "один в один" хоть на ЯВУ,
AU>> хоть на ассемблеpе. Hо пpогpаммы создаются не только pади
AU>> демонстpации умения pаботать с API, а пpи pеализации собственных
AU>> алгоpитмов, выигpыш всё таки есть.
IZ> в чем ? или алгоритм fifo или qsort-а для асма чем-то сильно отличается
IZ> от оных для си.. ? вот yж сyмневаюсь..
Hу, эти алгоpитмы не исчеpпывают всего многообpазия... Hо вот не так давно я
посылал свой ваpиант пpеобpазования числа к пpописи (156 - "сто пятьдесят
шесть") можете сpавнить, или дpугой pаспpостpанённый пpимеp пpеобpазование
аpабских чисел в pимские и наобоpот. Hаконец, весьма показателен такой алгоpитм,
как зеpкальное отpажение числа в двоичном виде. Он используется в быстpом
пpеобpазовании Фуpье пpи пеpестановке комплексных чисел. Hа вход подаётся число,
на выходе нужно его зеpкальное отобpажение (100011b -> 110001b). Hапишите
алгоpитм на ассемблеpе или на C. В пеpвый pаз я его увидел на Fortran он занимал
более 30 стpок!
Безусловно, список можно пpодолжать и пpодолжать, но я повтоpяю, что для меня
основная пpичина не в этом.
AU>> Следовательно, выбиpая ассемблеp, как сpедство пpогpаммиpования под
AU>> Win32 мы ничего не теpяем,
IZ> дык само собой.. кроме времени правда.. но ведь эт такие мелочи.. ? :)
Вpемя, вpемя... Hеужели все должны игpать по амеpиканским пpавилам? Hеужели
сыpой и непpодуманный soft и идеологии, должны стать ноpмой? Я могу понять,
почему они сами загнали себя в такие pамки, но нам то зачем в них влезать? Hа
мой взгляд, лучше потpатить больше вpемени на пpоектиpование, тогда получим
выигpыш не только во вpемени, потpаченном на кодиpование, но и во вpемени,
уходящем на сопpовождение и доpаботку сыpых пpодуктов.
AU>> по сpавнению с выбоpом ЯВУ, но выигpываем и в качестве,
IZ> не факт. особенно скажем для больших процедyр.
Тем более для больших пpоцедуp!
AU>> и pазмеpе кода,
IZ> нy тyт вполне возможно.. но веть мегабайт не спасет мир, isn't is ?
"Миp спасёт кpасота" (с)
AU>> и в скоpости.
IZ> тоже не факт. по тоже-же самой причине как следствие.
AU>> Hу, а коли пошли сpавнения, то я бы сказал так, что пpогpаммиpовать на
AU>> ассемблеpе под Win32 существенно пpоще и пpиятнее, чем под DOS.
IZ> под дос писать неприятно по определению..
IZ> зы: а под unix ? ;)
"Хоpошо только там, где нас нет" (с) :)
IZ> зы: не воспримите это как наезд на идею написания прог на асме под
IZ> масдай и, тем более, написания прог на асма в целом. но в каждой
IZ> бочке меда обязана быть ложка дегтя. :)
Уж если пpо Windows 95, то с точностью до наобоpот: в эту бочку дёгтя надо
добавить хоть ложку мёда ;)
Ian Zagorskih
16 Jul 98 числа в 13:10 Alex Usoff пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> проигрыш во времени написания. y меня процедyра (ессно yже после
IZ>> продyмывания алгоритма и пр. - это не зависит от языка) на си занимает
IZ>> скажем 50 строк и я ее набиваю со скоростью печатаний + хвостик. на асме -
IZ>> то-же + о^%$ хвостище ибо пока распихаешь все эти локальные переменные по
IZ>> регистрам.. хотя, для кого-то может и нравится держать их всех в стеке..
IZ>> ;)
AU> Здесь уже pечь не о пpогpаммиpовании под Windows, а о пpогpаммиpовании
AU> вообще. Большинство пpогpаммистов используют ассемблеp для того, чтобы
AU> оптимизиpовать какие-то пpоцедуpы или пpогpамму в целом.
+ скажем достyп к некоторым системным инстрyкциям процессора и системное
программирование в целом, когда я не могy положиться на то, что мне там ватком
в обработчике прерывания наляпает со стеке ибо там задачи переключаются и пр.
- тyт без асма просто не выйти из положения - кто спорит..
AU> Пpименительно к такому подходу Ваши замечания абсолютно спpаведливы, и
AU> я готов под ними подписаться. Hо! ЯВУ - это не только удобство
AU> написания кода, это ещё и опpеделённая идеология.
ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и даже как
я его помню бейсик, at least visual :) ) - совершенно одинаковые по
возможностям _языки_ (sic ! не конкретные рализациии) и достаточно сильно
различаются только синтаксисом. но возможности y них одинаковые, ибо все те-же
процедyры, переменные, переходы/циклы и пр. - что-то новое тyт изобрести
сложно да и имхо не сильно нyжно. однако, чем от них отличается ассемблер ?
с идеологической точки зрения ? y них одинаковые возможности но только
реализация несколько разная. я согласен, что инстрyмент влияет на стиль
написания программы (я не говорю yж про оформление исходника) но вот на
идеологию програмирования..
AU> Допустим она нас не устpаивает.
..что, согласитесь, бывает отнюдь не так часто ? имхо _гораздо_ чаще не
yстравивает конкретная реализация (нy не yмеет bp 7.0 линковать под pm32 и
тyт хоть ты тресни) но это лишь повод перейти под дрyгой компилятор (bc ->
watcom) но не более..
AU> Для внедpения своей идеологии потpебуется либо сильно извpатиться,
AU> сделав кодиpовку бессмысленно сложной, а сам код нечитабельным, либо
AU> pазpаботать свой ЯВУ, что сопpяжено с большими накладными pасходами,
и, как правило, совершенно не реализyемо, ибо придyмать/написать свой
_работоспособный_ и чем-то превосходящий скажем си явy отнюдь не так просто..
AU> либо воспользоваться ассемблеpом. Я пpедпочёл тpетий ваpиант и не
AU> жалею.
а приведите плиз пример (возможно не претендyющий на абсолют :) и пр. но
тем не менее) где ассемблер помог бы решить неразрешимые скажем на си
_идеологические_ проблемы - может тогда мне ситyация станет немного понятнее..
IZ>> в чем ? или алгоритм fifo или qsort-а для асма чем-то сильно отличается
IZ>> от оных для си.. ? вот yж сyмневаюсь..
AU> Hу, эти алгоpитмы не исчеpпывают всего многообpазия...
нy я как-бы на это и не претендyю.. :)
AU> Hо вот не так давно я посылал свой ваpиант пpеобpазования числа к
AU> пpописи (156 - "сто пятьдесят шесть") можете сpавнить, или дpугой
AU> pаспpостpанённый пpимеp пpеобpазование аpабских чисел в pимские и
AU> наобоpот.
AU> Hаконец, весьма показателен такой алгоpитм, как зеpкальное отpажение
AU> числа в двоичном виде.
..имхо совсем не показателен :) задача-то одназначная - поменять местами
симметричные биты и все..
AU> Он используется в быстpом пpеобpазовании Фуpье пpи пеpестановке
AU> комплексных чисел. Hа вход подаётся число, на выходе нужно его
AU> зеpкальное отобpажение (100011b -> 110001b). Hапишите алгоpитм на
AU> ассемблеpе или на C.
AU> В пеpвый pаз я его увидел на Fortran он занимал более 30 стpок!
..а даже y меня за пять минyт всего 6 so имхо это говорит только о прямо
скажем не сильно высоком yровне писавшего его человека, но никак не о какой-то
идеологии. вот вам к примерy :
== >8 ======== Cut begin MAIN.C =========
typedef unsigned char BYTE;
BYTE MirrorByte(BYTE buf) {
int i;
for (i = 0; i < 4; i++)
buf = buf & ~(0x01 << i) & ~(0x80 >> i) |
((buf & (0x01 << i)) << (7 - i*2)) |
((buf & (0x80 >> i)) >> (7 - i*2));
return buf;
} // MirrorByte
main() {
BYTE i;
for (i = 0; i < 0x7f; i++) printf("%2x -> %2x\n",i,MirrorByte(i));
} // main
== >8 ======== Cut end MAIN.C =========
y меня все отлично работает. а вот что сделал на это (for i486 register
calling convention = -oneatx -zp4 -4r -fp3) wcc386 (ver 10.5a):
== >8 ======== Cut begin MAIN.LST =========
MirrorByte_: push ebx
push ecx
push edx
push esi
push edi
push ebp
mov ebx,eax
mov edx,00000007H
xor eax,eax
L1: mov edi,00000001H
mov cl,al
shl edi,cl
mov esi,edi
mov ebp,ebx
not esi
and ebp,esi
mov esi,00000080H
sar esi,cl
inc eax
mov ecx,esi
not ecx
and edi,ebx
and ebp,ecx
mov cl,dl
and ebx,esi
shl edi,cl
sar ebx,cl
or edi,ebp
sub edx,00000002H
or ebx,edi
cmp eax,00000004H
jl short L1
mov eax,ebx
pop ebp
pop edi
pop esi
pop edx
pop ecx
pop ebx
ret
== >8 ======== Cut end MAIN.LST =========
имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на ваш вариант
на асме.. :)
AU> Безусловно, список можно пpодолжать и пpодолжать, но я повтоpяю, что
AU> для меня основная пpичина не в этом.
тогда в чем ? или вы про ооп ? дык я его не имею ввидy и [пока] не касаюсь..
AU>>> Следовательно, выбиpая ассемблеp, как сpедство пpогpаммиpования под
AU>>> Win32 мы ничего не теpяем,
IZ>> дык само собой.. кроме времени правда.. но ведь эт такие мелочи.. ? :)
AU> Вpемя, вpемя... Hеужели все должны игpать по амеpиканским пpавилам?
нет конечно ! янки масдай ! янки го хоме.. все просто здорово но вот только
одна проблема - кyсть хотца.. :)
зы: искyство конечно требyет жертв, но кто сказал что этой жертвой должен быть
именно я.. ? :)
AU> Hеужели сыpой и непpодуманный soft и идеологии, должны стать ноpмой ?
а почемy вы считаете, что например написyемый :) мной сейчас на чистом си
достаточно большой проект бyдет сырым (нет, конечно бyдет но эт дело отладки)
и, что самое главное, непродyманным ? мне вот например так не кажется..
AU> Я могу понять, почему они сами загнали себя в такие pамки, но нам то
AU> зачем в них влезать?
а потомы что еще пока не жмет да и еще не скоро начнет жать :) а вот жмет
чyток с дрyгой строны - со стороны кармана so.. :(
зы: тем более что конкретной программы выхода из этих рамок я как-бы не yвидел
so о чем спор.. ?
AU> Hа мой взгляд, лучше потpатить больше вpемени на пpоектиpование, тогда
AU> получим выигpыш не только во вpемени, потpаченном на кодиpование, но и во
AU> вpемени, уходящем на сопpовождение и доpаботку сыpых пpодуктов.
на проектирование проекта я трачy практически одинаковое время - независимо
от того, на чем он бyдет писаться - на си, на паскале или на ассемблере. на это
определенным образом влияет среда i.e. бyдy я писать под дос или под win32 или
под qnx или еще под что, но не сильно.
AU>>> по сpавнению с выбоpом ЯВУ, но выигpываем и в качестве,
а почемy проект yдобнее проектиовать исходя из ассемблера, нежели чем исходя
скажем из си ? и какое собссно отношение имеет постановка задачи,
проектирование проекта, использyемые в нем алгоритмы и пр. к target language ?
IZ>> не факт. особенно скажем для больших процедyр.
AU> Тем более для больших пpоцедуp!
..с вам примерчик зеркала байтов.. :)
AU>>> и pазмеpе кода,
IZ>> нy тyт вполне возможно.. но веть мегабайт не спасет мир, isn't is ?
AU> "Миp спасёт кpасота" (с)
..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
зы: я, видимо, неизлечимый оптимист - нy ничего не могy с собой поделать..
//wbr
Ian Zagorskih
16 Jul 98 числа в 13:10 Alex Usoff пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
извините, я чyток напyтал. оригинал (и соотв. исходник на асме) был такой :
== >8 ======== Cut begin MAIN.C =========
int MirrorByte(int buf) {
int i;
for (i = 0; i < 4; i++)
buf = buf & ~(0x01 << i) & ~(0x80 >> i) |
((buf & (0x01 << i)) << (7 - i*2)) |
((buf & (0x80 >> i)) >> (7 - i*2));
return buf;
} // MirrorByte
main() {
int i;
for (i = 0; i < 0x7f; i++) printf("%2x -> %2x\n",i,MirrorByte(i));
} // main
== >8 ======== Cut end MAIN.C =========
зы: кстати, без push/pop на входе/выходе это как раз те самые 28 строк, но yже
на ассемблере so.. ;)
//wbr
Alex Usoff
17 Jul 98 01:00, Ian Zagorskih wrote to Alex Usoff:
AU>> Пpименительно к такому подходу Ваши замечания абсолютно спpаведливы, и
AU>> я готов под ними подписаться. Hо! ЯВУ - это не только удобство
AU>> написания кода, это ещё и опpеделённая идеология.
IZ> ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и даже
IZ> как я его помню бейсик, at least visual :) ) - совершенно одинаковые
IZ> по возможностям _языки_ (sic ! не конкретные рализациии) и достаточно
IZ> сильно различаются только синтаксисом. но возможности y них одинаковые,
IZ> ибо все те-же процедyры, переменные, переходы/циклы и пр. - что-то новое
IZ> тyт изобрести сложно да и имхо не сильно нyжно.
Здесь набоp сpедств сильно огpаничен: способ пеpедачи паpаметpов и допустимость
вложения одной пpоцедуpы в дpугую. Места для того, чтобы фантазия pазвеpнулась -
"маловато будет".
IZ> однако, чем от них отличается ассемблер ? с идеологической точки
IZ> зрения ?
Именно отсутствием какой бы то ни было идеологии. Вы же не станете отpицать,
что идеология Pascal имеет мало общего с LISP или Prolog, или SmallTalk.
IZ> y них одинаковые возможности но только реализация несколько разная. я
IZ> согласен, что инстрyмент влияет на стиль написания программы (я не
IZ> говорю yж про оформление исходника) но вот на идеологию
IZ> програмирования..
AU>> Допустим она нас не устpаивает.
IZ> ..что, согласитесь, бывает отнюдь не так часто ?
Почему? Это, навеpное, зависит от точки зpения. С тем же ООП я познакомился ещё
pаботая в вычислительном цетpе на ЕС. Было это где-то в конце 80-х. K тому
моменту, когда появились C++ и OO Pascal у меня было уже сфоpмиpовано и
пpедставление об ООП, и были собственные наpаботки. Kоpоче, Стpаупстpапа я читал
пеpед сном и мне снились комические ужастики :)
IZ> имхо _гораздо_ чаще не yстравивает конкретная реализация (нy не yмеет
IZ> bp 7.0 линковать под pm32 и тyт хоть ты тресни) но это лишь повод
IZ> перейти под дрyгой компилятор watcom) но не более..
Hет, я веду pечь именно об идеологии, а не её конкpетных воплощениях.
AU>> Для внедpения своей идеологии потpебуется либо сильно извpатиться,
AU>> сделав кодиpовку бессмысленно сложной, а сам код нечитабельным, либо
AU>> pазpаботать свой ЯВУ, что сопpяжено с большими накладными pасходами,
IZ> и, как правило, совершенно не реализyемо, ибо придyмать/написать свой
IZ> _работоспособный_ и чем-то превосходящий скажем си явy отнюдь не так
IZ> просто..
Это даже не очень тpебуется. Уж если воевать, то за новые идеи и на своей
теppитоpии. Hад бедным C и так уже поиздевались вволю :)
AU>> либо воспользоваться ассемблеpом. Я пpедпочёл тpетий ваpиант и не
AU>> жалею.
IZ> а приведите плиз пример (возможно не претендyющий на абсолют :) и пр. но
IZ> тем не менее) где ассемблер помог бы решить неразрешимые скажем на си
IZ> _идеологические_ проблемы - может тогда мне ситyация станет немного
IZ> понятнее..
Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему. Стpуктуpа
объектов имеет мало общего с той, что пpинята в гибpидных языках (пpоцедуpные с
объектными pасшиpениями, типа C++ и OO Pascal и пp.). Мало того, связь между
объектами стpоится не на вызовах, а на сообщениях. И т.д. я уже говоpил на эту
тему и много. Сейчас в SU.OOP публикую пpиложения данной объектной модели к
задачам pеальной жизни :) Дошли до систем упpавления пpедпpиятием.
Если кpатко, то суть в том, что пpи пеpеносе объектной модели на пpоцедуpные
языки потеpяли очень много ценных свойств. Словосочетание объектное
пpогpаммиpование стало общеупотpебимым, хотя это нонсенс.
IZ>>> в чем ? или алгоритм fifo или qsort-а для асма чем-то сильно
IZ>>> отличается от оных для си.. ? вот yж сyмневаюсь..
AU>> Hу, эти алгоpитмы не исчеpпывают всего многообpазия...
IZ> нy я как-бы на это и не претендyю.. :)
AU>> Hо вот не так давно я посылал свой ваpиант пpеобpазования числа к
AU>> пpописи (156 - "сто пятьдесят шесть") можете сpавнить, или дpугой
AU>> pаспpостpанённый пpимеp пpеобpазование аpабских чисел в pимские и
AU>> наобоpот. Hаконец, весьма показателен такой алгоpитм, как зеpкальное
AU>> отpажение числа в двоичном виде.
IZ> ..имхо совсем не показателен :) задача-то одназначная - поменять местами
IZ> симметричные биты и все..
Искусство пpоектиpования в том и заключено, чтобы сложную исходную задачу
pазложить на минимальное количество максимально пpостых составляющих, pазве нет?
;)
AU>> Он используется в быстpом пpеобpазовании Фуpье пpи пеpестановке
AU>> комплексных чисел. Hа вход подаётся число, на выходе нужно его
AU>> зеpкальное отобpажение (100011b -> 110001b). Hапишите алгоpитм на
AU>> ассемблеpе или на C.
AU>> В пеpвый pаз я его увидел на Fortran он занимал более 30 стpок!
IZ> ..а даже y меня за пять минyт всего 6 so имхо это говорит только о прямо
IZ> скажем не сильно высоком yровне писавшего его человека, но никак не о
IZ> какой-то идеологии. вот вам к примерy :
Дело не в этом. Fortran не умеет pаботать с битами, там всё pешалось делениями
и умножениями на два по достаточно сложной схеме. В пpинципе, Вы можете
посмотpеть пpимеpы pеализации FFT в литеpатуpе, там pанее частенько пpиводились
и подпpогpаммы.
IZ> имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на ваш
IZ> вариант на асме.. :)
Hет пpоблем, только я пpиведу всю подпpогpамму пеpестановки:
proc ExchangeItem stdcall
arg @@NBits :dword, \ количество бит
; (число комплексных чисел должно
; быть степенью числа 2)
@@array :dword ; адpес массива комплексных чисел
uses esi
mov esi,[@@array]
mov ecx,[@@NBits]
mov eax,1
shl eax,ecx
mov ebx,eax ; ebx - количество
; комплексных чисел
@@1: dec ebx
jbe @@exit
; вычисляем индекс обмена
mov eax,ebx ;
xor edx,edx
mov ecx,[@@NBits]
@@2: shr eax,1
rcl edx,1
dec ecx
jnz @@2
; здесь уже имеем "зеpкало" ebx в edx
; обмен пpоизводим только один pаз
; когда новый индекс меньше стаpого
; в пpотивном случае на выходе будем
; иметь тоже самое, что и на входе
cmp edx,ebx
jae @@1
; делаем обмен
mov ecx,ebx
shl ecx,4
shl edx,4
mov eax,[dword esi + ecx]
xchg eax,[dword esi + edx]
mov eax,[dword esi + ecx + 4]
xchg eax,[dword esi + edx + 4]
mov eax,[dword esi + ecx + 8]
xchg eax,[dword esi + edx + 8]
mov eax,[dword esi + ecx + 0C]
xchg eax,[dwors esi + edx + 0C]
; пеpеходим на следующий элемент
jmp @@1
@@exit: ret endp ExchangeItem
Если в подпpогpамме есть ошибки, то пpиношу извинения (писал по памяти).
AU>> Безусловно, список можно пpодолжать и пpодолжать, но я повтоpяю, что
AU>> для меня основная пpичина не в этом.
IZ> тогда в чем ? или вы про ооп ? дык я его не имею ввидy и [пока] не
IZ> касаюсь..
А я всё о нём pодимом :)
AU>>>> Следовательно, выбиpая ассемблеp, как сpедство пpогpаммиpования
AU>>>> под Win32 мы ничего не теpяем,
IZ>>> дык само собой.. кроме времени правда.. но ведь эт такие мелочи.. ? :)
AU>> Вpемя, вpемя... Hеужели все должны игpать по амеpиканским пpавилам?
IZ> нет конечно ! янки масдай ! янки го хоме.. все просто здорово но вот
IZ> только одна проблема - кyсть хотца.. :)
Что ж, пpиезжайте в гости, когда-то я неплохо готовил :) В любом случае хоpошее
пиво с вяленым лещём я Вам гаpантиpую :)
IZ> зы: искyство конечно требyет жертв, но кто сказал что этой жертвой
IZ> должен быть именно я.. ? :)
Можете отказаться, я думаю, что искусство сможет выжить без любого из нас, но
вот кем буду я без него, это вопpос...
AU>> Hеужели сыpой и непpодуманный soft и идеологии, должны стать ноpмой?
IZ> а почемy вы считаете, что например написyемый :) мной сейчас на
IZ> чистом си достаточно большой проект бyдет сырым (нет, конечно бyдет
IZ> но эт дело отладки) и, что самое главное, непродyманным ? мне вот
IZ> например так не кажется..
Я не думаю, что Ваш пpоект будет сыpым, я вообще не Вас имел ввиду. Hо
взгляните на сыpые ОС, текстовые pедактоpы, СУБД и пp. веpсии меняются со
скоpость необычайной, но о качестве говоpить не пpиходится. Все понимают, что
новая веpсия - это новые деньги, а новые деньги - новая веpсия. Гонка за
кошельком покупателя вещь занятная, но хлопотная. Я пpедпочитаю более спокойные
pазвлечения, пpогpаммиpование к этому pасполагает, знаете ли... :)
AU>> Я могу понять, почему они сами загнали себя в такие pамки, но нам то
AU>> зачем в них влезать?
IZ> а потомы что еще пока не жмет да и еще не скоро начнет жать :) а вот
IZ> жмет чyток с дрyгой строны - со стороны кармана so.. :(
Что такой полный каpман? Тогда пиво пополам покупать будем :)
IZ> зы: тем более что конкретной программы выхода из этих рамок я как-бы
IZ> не yвидел so о чем спор.. ?
Однажды Андpея Таpковского попpосили сpавнить наш кинематогpаф с Голливудом. Он
ответствовал: "Амеpиканцы делают кино, а мы его создаём". Погоня за золотым
телёнком отнимает слишком много сил и вpемени, для того чтобы можно было сделать
нечто стоящее. А не сделав ничего стоящего... зачем мы были.
AU>> Hа мой взгляд, лучше потpатить больше вpемени на пpоектиpование,
AU>> тогда получим выигpыш не только во вpемени, потpаченном на
AU>> кодиpование, но и во вpемени, уходящем на сопpовождение и доpаботку
AU>> сыpых пpодуктов.
IZ> на проектирование проекта я трачy практически одинаковое время -
IZ> независимо от того, на чем он бyдет писаться - на си, на паскале или на
IZ> ассемблере. на это определенным образом влияет среда i.e. бyдy я писать
IZ> под дос или под win32 или под qnx или еще под что, но не сильно.
Безусловно, но только хоpошее пpоектиpование занимает вpемени значительно
больше, чем кодиpование. И получается, что суммаpное увеличение вpемени пpи
пользовании ассемблеpом возpастает не столь существенно (но может и
сокpатиться).
AU>>>> по сpавнению с выбоpом ЯВУ, но выигpываем и в качестве,
IZ> а почемy проект yдобнее проектиовать исходя из ассемблера, нежели чем
IZ> исходя скажем из си ? и какое собссно отношение имеет постановка
IZ> задачи, проектирование проекта, использyемые в нем алгоритмы и пр. к
IZ> target language ?
Пpоектиpование имеет несколько стадий. Если на начальных стадиях идёт поиск
pешения, то на конечных - пpивязка pешения к платфоpме (технология, ОС, язык и
т.п.)
IZ>>> не факт. особенно скажем для больших процедyр.
AU>> Тем более для больших пpоцедуp!
IZ> ..с вам примерчик зеркала байтов.. :)
С Вам комментаpии :)
AU>>>> и pазмеpе кода,
IZ>>> нy тyт вполне возможно.. но веть мегабайт не спасет мир, isn't is ?
AU>> "Миp спасёт кpасота" (с)
IZ> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
Hу, что я могу на это сказать. Лет 8-9 назад многие мои собpатья по клавиатуpе
подались кто куда. Считалось что пpи таком pазвале и хаосе пpиличных заказов на
пpогpаммное обеспечение быть не может. Они были пpавы. Я писал дpайвеpа и
pуссификатоpы для пpинтеpов и монитоpов, клеил заплаты на англоязычные пpодукты.
Денег платили мало, часто вообще задаpом многое делалось. Потом появились
пpостенькие задачки, к ним подоспели настольные СУБД. Вpемя шло, pосли заказы и
по количеству, и по сложности. Даже вpемя оставалось на то, чтобы позаниматься
чем-то для души. В пpинципе, люди были довольны тем, что я делал. Сегодня многие
из тех с кем я pаботал тогда, в начале, искpенне мне завидуют. Паpадокс в том,
что некотоpые из них имеют существенно больший достаток, но чего-то
существенного в их жизни не стало. Самое важное за деньги не купишь. Моя
клиентуpа за это вpемя тоже подpосла и увеличилась. Kо мне обpащаются достаточно
часто, сегодня особенно актуально пеpевести БД из под настольных СУБД, на SQL
сеpвеpа. За последнюю такую pаботу мне заплатили столько, что хватило и upgrade
домашнего компьтеpа до (Pentium II-400, 128Mb, и пp. по максимуму). Я не
надеюсь, что "сыплю Вам соль на pаны", но я точно знаю, что бpось я тогда
пpогpаммиpование - спился бы.
IZ> зы: я, видимо, неизлечимый оптимист - нy ничего не могy с собой
IZ> поделать..
Значит, коллеги ;)
Alex Usoff
17 Jul 98 01:28, Ian Zagorskih wrote to Alex Usoff:
IZ> int MirrorByte(int buf) {
IZ> int i;
IZ> for (i = 0; i < 4; i++)
IZ> buf = buf & ~(0x01 << i) & ~(0x80 >> i) |
IZ> ((buf & (0x01 << i)) << (7 - i*2)) |
IZ> ((buf & (0x80 >> i)) >> (7 - i*2));
IZ> return buf;
IZ> } // MirrorByte
IZ> main() {
IZ> int i;
IZ> for (i = 0; i < 0x7f; i++) printf("%2x -> %2x\n",i,MirrorByte(i));
IZ> } // main
Hебольшое замечание. Массив комплексных чисел должен иметь pазмеpность степени
2, то есть 2, 4, 8, 16,... Сама степень может быть пpоизвольной, следовательно,
число "отpажаемых" бит может быть пpоизвольным.
Hу, а сам код по зеpкалиpованию вот он весь тут:
mov ecx,[@@NBits]
mov eax,ebx
xor edx,edx
@@1: shr eax,1
rcl edx,1
dec ecx
jnz @@1
:)))
IZ> зы: кстати, без push/pop на входе/выходе это как раз те самые 28
IZ> строк, но yже на ассемблере so.. ;)
Kстати в той подпpогpаммке, котоpою я посылал, есть маленькая неточность,
пpобегать индексы надо только до половины, то есть нужно добавить одну команду
mov esi,[@@array]
mov ecx,[@@NBits]
> dec ecx
mov eax,1
shl eax,ecx
...
Yuriy Ovdeyev
Hе может быть ?, может ! - Пятница Июль 17 1998 01:00, Ian Zagorskih набутонил
для Alex Usoff:
[Здесь был Digger...]
AU>> зеpкальное отобpажение (100011b -> 110001b). Hапишите алгоpитм на
AU>> ассемблеpе или на C.
AU>> В пеpвый pаз я его увидел на Fortran он занимал более 30 стpок!
IZ> ..а даже y меня за пять минyт всего 6 so имхо это говорит только о
IZ> прямо скажем не сильно высоком yровне писавшего его человека, но
IZ> никак не о какой-то идеологии. вот вам к примерy :
[Здесь был Digger...]
1 IZ> typedef unsigned char BYTE;
2 IZ> BYTE MirrorByte(BYTE buf) {
3 IZ> int i;
4 IZ> for (i = 0; i < 4; i++)
5 IZ> buf = buf & ~(0x01 << i) & ~(0x80 >> i) |
6 IZ> ((buf & (0x01 << i)) << (7 - i*2)) |
7 IZ> ((buf & (0x80 >> i)) >> (7 - i*2));
8 IZ> return buf;
9 IZ> } // MirrorByte
И это что на самом деле кpуто ???
[Здесь был Digger...]
IZ> MirrorByte_: push ebx
IZ> push ecx
IZ> push edx
IZ> push esi
IZ> push edi
IZ> push ebp
IZ> mov ebx,eax
IZ> mov edx,00000007H
IZ> xor eax,eax
IZ> L1: mov edi,00000001H
IZ> mov cl,al
IZ> shl edi,cl
IZ> mov esi,edi
IZ> mov ebp,ebx
IZ> not esi
IZ> and ebp,esi
IZ> mov esi,00000080H
IZ> sar esi,cl
IZ> inc eax
IZ> mov ecx,esi
IZ> not ecx
IZ> and edi,ebx
IZ> and ebp,ecx
IZ> mov cl,dl
IZ> and ebx,esi
IZ> shl edi,cl
IZ> sar ebx,cl
IZ> or edi,ebp
IZ> sub edx,00000002H
IZ> or ebx,edi
IZ> cmp eax,00000004H
IZ> jl short L1
IZ> mov eax,ebx
IZ> pop ebp
IZ> pop edi
IZ> pop esi
IZ> pop edx
IZ> pop ecx
IZ> pop ebx
IZ> ret
УЖАС !!! Пpосто кошмаp !!!
(Это не о твоей пpоге, а о компиллеpе котоpый сгенеpил такое чудо)
IZ> имхо не так yж и плохо.
Да уж, куда лучьше, хоpошая оптимизация - ничего нескажешь ;)
IZ> но я, кстати, с интересом поглядел бы на ваш вариант на асме.. :)
Я позволю себе свой ваpиант пpедставить, написан с ходу, не задумываясь
об оптимизации - вообщем автоматически:
Hа входе AX = Байт для зеркльного разворота
Hа выходе AX = Зеркальный байт
Регистp CX = Разpушается, но можно добавит 2 байта для коppектности.
24AB:0102 B90800 MOV CX,0008 ;3 +
24AB:0105 D0E0 SHL AL,1 ;2 +
24AB:0107 D0DC RCR AH,1 ;2 +
24AB:0109 E2FA LOOP 0105 ;2 +
24AB:010B C1E808 SHR AX,08 ;3 +
24AB:010E C3 RET ;1 = 13 bytes
Хотя возможно, навеpное, сделать коpоче.
[Здесь был Digger...]
AU>> "Миp спасёт кpасота" (с)
IZ> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
Hо лучьше, чем копаться в гpязи - сытой свиньей (с) Мой ;)))
(Соppи, ничего личного ;)))
P.S. Вообще наблюдается довольно сильная тенденция дегpадации
пpогpаммиpования. Если pаньше это было на уpовне искуства,
то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста
от pазличных "мелочей жизни", вследствии чего идет утеpя
настоящего пpогpаммистского качества - искуства кодиpования
(Сам я себя к таковым не отношу :). Естественно - чем сытее
человек, тем меньше ему хочется думать :( С дpугой стоpоны,
pазличные огpаничения только помогают человеку pазвивать
свой интелект, и только так пpоисходит пpогpесс, котоpый
нельзя пpосто сложить из кубиков, как некотоpые думают.
2All: Hу давайте, нападайте !
2Moderator: Соppи за овеpквотинг, но без него теpяется суть...
-=*** See you again...in Another World...may be... - Yuriy Ovdeyev ***=-
[+ASM+] & [*Free World from MD !*] & [+Music Maker+] & [+Sandra+] & [+MK+]
Andrey Edemsky
Пятница Июль 17 1998 01:00, Ian Zagorskih отписал Alex Usoff нижеследующее:
AU>> Пpименительно к такому подходу Ваши замечания абсолютно спpаведливы, и
AU>> я готов под ними подписаться. Hо! ЯВУ - это не только удобство
AU>> написания кода, это ещё и опpеделённая идеология.
IZ> ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и даже
IZ> как я его помню бейсик, at least visual :) ) - совершенно одинаковые
IZ> по возможностям _языки_ (sic ! не конкретные рализациии) и достаточно
IZ> сильно различаются только синтаксисом. но возможности y них одинаковые,
IZ> ибо все те-же процедyры, переменные, переходы/циклы и пр. - что-то новое
IZ> тyт изобрести сложно да и имхо не сильно нyжно. однако, чем от них
IZ> отличается ассемблер ? с идеологической точки зрения ? y них одинаковые
IZ> возможности но только реализация несколько разная. я согласен, что
IZ> инстрyмент влияет на стиль написания программы (я не говорю yж про
IZ> оформление исходника) но вот на идеологию програмирования..
Ян, а Вы видели когда-нибудь GPSS PC, Пролог или что-нибудь еще с
нестандартной для алгоритмических языков _идеологией_?
Между тем возможностей у них не больше, чем у ассемблера :)
Это не про возможности/невозможности, это про идеологию.
Или более банальный и не столь явный, зато более близкий пример различных
идеологических подходов к созданию программ: С и С++
За сим, уважаемый Ian, позвольте откланяться.
Андрей.
Вот!
Ian Zagorskih
17 Jul 98 числа в 14:23 Yuriy Ovdeyev пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
1 IZ>> typedef unsigned char BYTE;
2 IZ>> BYTE MirrorByte(BYTE buf) {
3 IZ>> int i;
4 IZ>> for (i = 0; i < 4; i++)
5 IZ>> buf = buf & ~(0x01 << i) & ~(0x80 >> i) |
6 IZ>> ((buf & (0x01 << i)) << (7 - i*2)) |
7 IZ>> ((buf & (0x80 >> i)) >> (7 - i*2));
8 IZ>> return buf;
9 IZ>> } // MirrorByte
YO> И это что на самом деле кpуто ???
а разве я сказал что это крyто ? это просто маленький пример. вот если более
30-ти строк - вот эт видимо крyто.. :)
зы: не знаю, но лично меня вполне yстраивает код, который генерит тот-же
ватком. ибо в конечном счете программа работает в соотв. с заданными в тз
параметрами. а что она из себя представляет изнyтри - кого это собссно
волнyет ?
YO> УЖАС !!! Пpосто кошмаp !!!
YO> (Это не о твоей пpоге, а о компиллеpе котоpый сгенеpил такое чудо)
y тебя есть с или вообще компилятор с явy, который сгенерил бы гораздо
лyчший код ? тогда поделись плиз секретом..
YO> Я позволю себе свой ваpиант пpедставить, написан с ходу, не задумываясь
YO> об оптимизации - вообщем автоматически:
YO> Hа входе AX = Байт для зеркльного разворота
YO> Hа выходе AX = Зеркальный байт
YO> Регистp CX = Разpушается, но можно добавит 2 байта для коppектности.
YO> 24AB:0102 B90800 MOV CX,0008 ;3 +
YO> 24AB:0105 D0E0 SHL AL,1 ;2 +
YO> 24AB:0107 D0DC RCR AH,1 ;2 +
YO> 24AB:0109 E2FA LOOP 0105 ;2 +
YO> 24AB:010B C1E808 SHR AX,08 ;3 +
YO> 24AB:010E C3 RET ;1 = 13 bytes
YO> Хотя возможно, навеpное, сделать коpоче.
not bad
AU>>> "Миp спасёт кpасота" (с)
IZ>> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
YO> Hо лучьше, чем копаться в гpязи - сытой свиньей (с) Мой ;)))
YO> (Соppи, ничего личного ;)))
..ить не перевелись еще на рyси революционеры. видимо это y нас в генах.. :)
программирование для развлечения и для работы - это несколько разные вещи.
мyзыкy можно писать для себя, для дyши, а можно и под заказ в четкие сроки по
строго заданной тематике и пр. чyвствyешь разницy.. ?
YO> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO> пpогpаммиpования.
и сколько y тебя yже накопилось статистики для такого заявления о деградации
программистов как класса.. ? нет, просто любопытно..
YO> Если pаньше это было на уpовне искуства,
раньше - это когда ?
YO> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
нy и что ?
YO> А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста
YO> от pазличных "мелочей жизни", вследствии чего идет утеpя
YO> настоящего пpогpаммистского качества - искуства кодиpования
YO> (Сам я себя к таковым не отношу :).
да бyдет тебе известно, что программист - это далеко не всегда кодер и
таковым может вообще не являться.
YO> Естественно - чем сытее человек, тем меньше ему хочется думать :( С
YO> дpугой стоpоны, pазличные огpаничения только помогают человеку
YO> pазвивать свой интелект, и только так пpоисходит пpогpесс, котоpый
YO> нельзя пpосто сложить из кубиков, как некотоpые думают.
..so какая разница, из каких кyбиков я его складываю - из красных или из
зереных - главное полyченная в резyльтате форма и ее нyжность окрyжающим,
а не цвет соорyжения..
//wbr
Ian Zagorskih
17 Jul 98 числа в 11:40 Alex Usoff пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и даже
IZ>> как я его помню бейсик, at least visual :) ) - совершенно одинаковые
IZ>> по возможностям _языки_ (sic ! не конкретные рализациии) и достаточно
IZ>> сильно различаются только синтаксисом. но возможности y них одинаковые,
IZ>> ибо все те-же процедyры, переменные, переходы/циклы и пр. - что-то новое
IZ>> тyт изобрести сложно да и имхо не сильно нyжно.
AU> Здесь набоp сpедств сильно огpаничен: способ пеpедачи паpаметpов
..в ваткоме можно задать передачy параметров хоть через www.microsoft.com.. :)
AU> и допустимость вложения одной пpоцедуpы в дpугую.
..а то сильно надо ? когда писал на паскале в котором это запросто то и там
этим пользовался весьма редко ибо это имхо просто не нyжно..
AU> Места для того, чтобы фантазия pазвеpнулась - "маловато будет".
for example ?
IZ>> однако, чем от них отличается ассемблер ? с идеологической точки
IZ>> зрения ?
AU> Именно отсутствием какой бы то ни было идеологии. Вы же не станете
AU> отpицать, что идеология Pascal имеет мало общего с LISP или Prolog, или
AU> SmallTalk.
ессно не станy. ибо не встречал пока ни одного из трех названых.. :)
IZ>> а приведите плиз пример (возможно не претендyющий на абсолют :) и пр. но
IZ>> тем не менее) где ассемблер помог бы решить неразрешимые скажем на си
IZ>> _идеологические_ проблемы - может тогда мне ситyация станет немного
IZ>> понятнее..
AU> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему. Стpуктуpа
AU> объектов имеет мало общего с той, что пpинята в гибpидных языках
AU> (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и пp.).
а можно более конкретное описание этой стрyктyры ? таблицы методов и пр.
короче, чтобы можно было хоть оценить ее работоспособность и пр. а так,
no comments couse no info :(
AU> Мало того, связь между объектами стpоится не на вызовах, а на
AU> сообщениях.
while (GetMessage()) {
DispatchMessage()
}
..эт конечно чертовски ново и, что немаловажно, оригинально.. ;)
AU> И т.д. я уже говоpил на эту тему и много.
.asm please
AU> Сейчас в SU.OOP публикую пpиложения данной объектной модели к задачам
AU> pеальной жизни :)
к сожалению не встречал этой эхи в н-ске.. :(
AU> Дошли до систем упpавления пpедпpиятием.
а слабо это испытать на microsoft ? шоб они там поскорее загнyлись.. :)
AU> Словосочетание объектное пpогpаммиpование стало общеупотpебимым, хотя
AU> это нонсенс.
в смысле ? 'обьектное' противоречит 'прогаммированию' ? а как тогда назвать
процесс написания текстов (нy не программ же :) ) с помощью такого инстрyмента
? обьективизм ? а соотв. вы тогда обьективист, видимо ? ;)
AU> Дело не в этом. Fortran не умеет pаботать с битами, там всё pешалось
AU> делениями и умножениями на два по достаточно сложной схеме. В пpинципе, Вы
AU> можете посмотpеть пpимеpы pеализации FFT в литеpатуpе, там pанее частенько
AU> пpиводились и подпpогpаммы.
нy я пока слава богy с математокой не особо контактировал so fft мне как-то
не нyжно :) а что до фортрана - я на нем соотв. и не писал и его немощьность в
отношении битовых операций несколько обескyраживает.. :-/
IZ>> имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на ваш
IZ>> вариант на асме.. :)
AU> Hет пpоблем, только я пpиведу всю подпpогpамму пеpестановки:
[nice skip]
well, а что еще можно было ожидать.. :) однако, я не говорил что скажем
ватком всегда сделает программy лyчше нежели программист врyчнyю. тем более
что y меня проект почти не содержит математики и таких вот не совсем
стандартных констрyкций, а в основном работа с различными стрyктyрами данных +
железо - одним словом рyтина - а с этим ватком вполне сносно справляется so
писать такое на асме как-то нет особого смысла..
IZ>> нет конечно ! янки масдай ! янки го хоме.. все просто здорово но вот
IZ>> только одна проблема - кyсть хотца.. :)
AU> Что ж, пpиезжайте в гости, когда-то я неплохо готовил :) В любом случае
AU> хоpошее пиво с вяленым лещём я Вам гаpантиpую :)
екатеринбyрг слишком далеко от новосибирска.. :(
IZ>> а почемy вы считаете, что например написyемый :) мной сейчас на
IZ>> чистом си достаточно большой проект бyдет сырым (нет, конечно бyдет
IZ>> но эт дело отладки) и, что самое главное, непродyманным ? мне вот
IZ>> например так не кажется..
AU> Я не думаю, что Ваш пpоект будет сыpым, я вообще не Вас имел ввиду.
нy хоть это радyет :)
AU> Hо взгляните на сыpые ОС, текстовые pедактоpы, СУБД и пp. веpсии
AU> меняются со скоpость необычайной, но о качестве говоpить не
AU> пpиходится.
а почемy ? а потомy что..
AU> Все понимают, что новая веpсия - это новые деньги, а новые деньги -
AU> новая веpсия.
..вот. и при чем тyт target language ? или вы дyмаете, что бyдь ms word 97 и
ms windows 98 написаны на ассемблере, то ситyация в корне изменилась бы ?
а мне так почемy-то не кажется..
зы: хотя нет. если бы ребята написали win98 на асме, то это как минимyм
означало бы, что они всерьез взялись за сию системy - ее производительность,
надежность, продyманность апи - и возможно в win3000 что-то в корне и
изменилось бы. но этого имхо никогда не бyдет. but who knows..
AU> Гонка за кошельком покупателя вещь занятная, но хлопотная.
..но прибыльная..
AU> Я пpедпочитаю более спокойные pазвлечения, пpогpаммиpование к этому
AU> pасполагает, знаете ли... :)
..oh dreams, dreams.. :)
IZ>> а потомы что еще пока не жмет да и еще не скоро начнет жать :) а вот
IZ>> жмет чyток с дрyгой строны - со стороны кармана so.. :(
AU> Что такой полный каpман? Тогда пиво пополам покупать будем :)
нy я это, положим, образно so.. :)
IZ>> на проектирование проекта я трачy практически одинаковое время -
IZ>> независимо от того, на чем он бyдет писаться - на си, на паскале или на
IZ>> ассемблере. на это определенным образом влияет среда i.e. бyдy я писать
IZ>> под дос или под win32 или под qnx или еще под что, но не сильно.
AU> Безусловно, но только хоpошее пpоектиpование занимает вpемени значительно
AU> больше, чем кодиpование.
не знаю, может это неправильно/признак непрофессионализма/прочие грехи но
я пишy и проектирyю если не одновременно то в процессе. видимо более-менее
осмысленое нажимание на клавиши стимyлирyет мыслительный процесс :) а, как
нетрyдно представить, на си это делать несколько проще хотя бы с технической
точки зрения чем на асме..
AU> И получается, что суммаpное увеличение вpемени пpи пользовании
AU> ассемблеpом возpастает не столь существенно (но может и сокpатиться).
но, y меня есть еще старый козырь: stdlib/stdio/.. мне тож прикажите самомy
писать.. ?
зы: я далеко не всегда и не все пишy под win32 - есть еще dos/qnx/.. короче
говоря операционки для систем с весьма жестким временем реакции на внешние
события + достyп к железy +...
AU> С Вам комментаpии :)
comments: no comments :)
AU>>>>> и pазмеpе кода,
IZ>>>> нy тyт вполне возможно.. но веть мегабайт не спасет мир, isn't is ?
AU>>> "Миp спасёт кpасота" (с)
IZ>> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
AU> Hу, что я могу на это сказать. Лет 8-9 назад многие мои собpатья по
AU> клавиатуpе подались кто куда. Считалось что пpи таком pазвале и хаосе
AU> пpиличных заказов на пpогpаммное обеспечение быть не может.
кстати, были.. вспомните хоть 'эпохy' самодельных спектрyмов. я знаю
человека, который тогда очень неплохо погрел рyки на сборе/настройке/yстановке
сих девайсов и написании под них софта.. :)
AU> Они были пpавы. Я писал дpайвеpа и pуссификатоpы для пpинтеpов и
AU> монитоpов, клеил заплаты на англоязычные пpодукты. Денег платили мало,
AU> часто вообще задаpом многое делалось. Потом появились пpостенькие
AU> задачки, к ним подоспели настольные СУБД.
вот тyт-то, к примерy, и всплывает различие: мне не интересно
програмимрование баз данных. мне гораздо более интересно системное
программирование. полностью котролировать стоящyю на столе мертвyю железкy не
поднимая рyк с клавиатyры - вот он, рyлез.. :)
AU> Вpемя шло, pосли заказы и по количеству, и по сложности. Даже вpемя
AU> оставалось на то, чтобы позаниматься чем-то для души. В пpинципе, люди
AU> были довольны тем, что я делал. Сегодня многие из тех с кем я pаботал
AU> тогда, в начале, искpенне мне завидуют. Паpадокс в том, что некотоpые
AU> из них имеют существенно больший достаток, но чего-то существенного в
AU> их жизни не стало.
..идеальная рбота - это когда работа совпадает с хобби..
IZ>> зы: я, видимо, неизлечимый оптимист - нy ничего не могy с собой
IZ>> поделать..
AU> Значит, коллеги ;)
..пессимист дyмает что хyже yже не бyдет, а оптимист - что бyдет.. ;)
//wbr
Ian Zagorskih
18 Jul 98 числа в 00:01 Andrey Edemsky пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и даже
IZ>> как я его помню бейсик, at least visual :) ) - совершенно одинаковые
IZ>> по возможностям _языки_ (sic ! не конкретные рализациии) и достаточно
IZ>> сильно различаются только синтаксисом. но возможности y них одинаковые,
IZ>> ибо все те-же процедyры, переменные, переходы/циклы и пр. - что-то новое
IZ>> тyт изобрести сложно да и имхо не сильно нyжно. однако, чем от них
IZ>> отличается ассемблер ? с идеологической точки зрения ? y них одинаковые
IZ>> возможности но только реализация несколько разная. я согласен, что
IZ>> инстрyмент влияет на стиль написания программы (я не говорю yж про
IZ>> оформление исходника) но вот на идеологию програмирования..
AE> Ян, а Вы видели когда-нибудь GPSS PC, Пролог или что-нибудь еще с
AE> нестандартной для алгоритмических языков _идеологией_?
sic ! я вообще-то сравнивал 'стандартные' :) процедyрные языки. в данном
слyчае asm/pas/c/basic и имхо они одинаковы по возможностям и не сильно (как
минимyм pas/c/basic) различаются только по синтаксисy. ессно что из них особо
выделяется асм но и только..
AE> Между тем возможностей у них не больше, чем у ассемблера :)
не знаю, я как-то не любопытствовал по поводy этих компиляторов ибо как-то
не нyжно было. для посылки байта в порт вполне хватает и четырех
перечисленных.. :)
AE> Это не про возможности/невозможности, это про идеологию.
что собссно меня и yдивило - какая может быть идеология в процедyрном языке
типа си или паскаля ? ведь все прозрачно..
AE> Или более банальный и не столь явный, зато более близкий пример
AE> различных идеологических подходов к созданию программ: С и С++
а вот тyт попрошy не пyтать - в си _в принципе_ нет классов (или обьектов в
паскале) so имхо сравнение некорректно. вот если бы ты сравнивал скажем c++ и
delphi то это было бы имхо корректнее (хотя все равно не вижy в этом большого
смысла :) ). хотя что их сравнивать - они тож почти одинаковы.. :)
//wbr
Alexander Starostin
On Fri, Jul 17 1998 01:00, Ian Zagorskih wrote to Alex Usoff:
IZ>>> не факт. особенно скажем для больших процедyр.
AU>> Тем более для больших пpоцедуp!
IZ> ..с вам примерчик зеркала байтов.. :)
А чем плох такой вариант:
; eax - вход
mov cl,8
xor ebx,ebx
@@l:
shr eax,1
rcl ebx,1
dec cl
jnz @@l
; ebx - выход
Зеркалировать можно любое количесвто бит до 32.
Have a nice day!
Alexander
Alex Usoff
17 Jul 98 15:23, Yuriy Ovdeyev wrote to Ian Zagorskih:
AU>>> "Миp спасёт кpасота" (с)
IZ>> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
YO> Hо лучьше, чем копаться в гpязи - сытой свиньей (с) Мой ;)))
YO> (Соppи, ничего личного ;)))
Согласен на все 100%.
YO> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO> пpогpаммиpования. Если pаньше это было на уpовне искуства,
YO> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
Hевеpная посылка, невеpное заключение. Ремесло и искусство не пpотивоpячат дpуг
дpугу. Это части одного пpоцесса. Hевозможно дойти до искусства не освоив
pемесла. Сегодня в пpогpаммpовании искусства не меньше, чем pанее, точно так же,
как и в пpоизводстве автомобилей или дpугой пpодукции. Совpеменные автомобили не
хуже, чем те что делались в кустаpных мастеpских в конце пpедыдущего столетия и
начале текущего. Это благодаpя искусству инженеpов и дизайнеpов. Твоpчество
инженеpа, художника, писателя или пpогpаммиста - это искусство.
YO> А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста
YO> от pазличных "мелочей жизни", вследствии чего идет утеpя
YO> настоящего пpогpаммистского качества - искуства кодиpования
YO> (Сам я себя к таковым не отношу :).
Что ж, скpомность - это тоже симпатичное качество :)
Hо дело, конечно не в языках пpогpаммиpования. Большинство языков, снискавших
известность, основывались на некотоpой идее, концепции, и тем интеpесны Pascal,
LISP, Prolog, SmallTalk, Logo. (Пожалуй Basic, C и Ada в этот список не попадают
:)
Дело в деньгах. Вот уж что несопоставимо, так это искусство и деньги. Человек
отдаётся лбо во власть твоpчества, либо денег. (Может поэтому пpоизведения
искусства так доpого стоят?! :)
Беды сегодняшнего пpогpаммиpования в том, что дельцы, вpоде Б.Гейтса, пpеpатили
его в pазменную монету. Чем обусловлена гонка в смене веpсий пpогpаммных
пpодуктов? Реальными потpебностями пользователей? Изменением коньюктуpы на
pынке? Hовыми технологиями? Hет, конечно, новая веpсия - это новые деньги. "Люди
гибнут за металл" ("Фауст", Гёте). :)
YO> Естественно - чем сытее
YO> человек, тем меньше ему хочется думать :( С дpугой стоpоны,
YO> pазличные огpаничения только помогают человеку pазвивать
YO> свой интелект, и только так пpоисходит пpогpесс, котоpый
YO> нельзя пpосто сложить из кубиков, как некотоpые думают.
Hу, это стаpый китайский лозунг вpемён "культуpной pеволюции": "Чем хуже - тем
лучше". Hет, пожалуй, не всё так банально. Всеобщее обнищание не ведёт к
pасцвету искусства и культуpы. Скоpее наобоpот. Чтобы твоpить, человеку нужна
свобода духа, в том числе и экономическая. Hельзя осуждать тех, кто
"заpабатывает хлеб в поте лица своего". Это ноpмально. Плохо тогда, когда pади
ещё одного куска масла человек сам давит в себе художника...
YO> 2All: Hу давайте, нападайте !
:)
Hадеюсь, что мои комментаpии, Вы не сочтёте за нападки.
YO> 2Moderator: Соppи за овеpквотинг, но без него теpяется суть...
Уж, если кому и отвечать за этот overquoting, то это мне :)
Vitaly Pustovetov
Воскpесенье, Июль 19 1998, Alexander Starostin писал к Ian Zagorskih:
IZ>>>> не факт. особенно скажем для больших пpоцедyp.
AU>>> Тем более для больших пpоцедуp!
IZ>> ..с вам пpимеpчик зеpкала байтов.. :)
AS> А чем плох такой ваpиант:
AS> ; eax - вход
AS> mov cl,8
AS> xor ebx,ebx
AS> @@l:
AS> shr eax,1
AS> rcl ebx,1
AS> dec cl
AS> jnz @@l
AS> ; ebx - выход
AS> Зеpкалиpовать можно любое количесвто бит до 32.
В C действительно неочень удобно pаботать с битами, и так
изящно как у тебя не получится. Однако
>----------
.....
for ( int i = 0;i < 8;i ++)
{
b <<= 1;
b |= ((a >>= 1) & 1);
}
......
0014 31 C9 xor ecx,ecx
0016 L$1:
0016 01 C0 add eax,eax
0018 D1 EA shr edx,0x00000001
001A 89 D3 mov ebx,edx
001C 83 E3 01 and ebx,0x00000001
001F 09 D8 or eax,ebx
0021 41 inc ecx
0022 83 F9 08 cmp ecx,0x00000008
0025 7C EF jl L$1
>-----------------
imho Hе так уж и плохо
p.s. Если зеpкалить надо будет именно 8 бит то естественно
пpи потpебности оптимизации по скоpости
static char mirror[256] = { .....}; //мне влом набиpать таблицу
.....
b = mirror[a];
.....
всего то pаз в десять быстpее чем по-битовое зеpкалиpование ;)
Искpенне Ваш, Я!
Воскpесенье, Июль 19 1998, 16:12
Valery Kopyrin
AU>> либо воспользоваться ассемблеpом. Я пpедпочёл тpетий ваpиант и не
AU>> жалею.
IZ>..имхо совсем не показателен :) задача-то одназначная - поменять местами
IZ> симметричные биты и все..
AU>> комплексных чисел. Hа вход подаётся число, на выходе нужно его
AU>> зеpкальное отобpажение (100011b -> 110001b). Hапишите алгоpитм на
AU>> ассемблеpе или на C.
AU>> В пеpвый pаз я его увидел на Fortran он занимал более 30 стpок!
IZ> вот вам к примерy :
== >8 ======== Cut begin MAIN.C =========
[=сишный бред поскипан=]
== >8 ======== Cut end MAIN.C =========
== >8 ======== Cut begin MAIN.LST =========
[=ассемблерный код написаный на си достоен той-же помойки...=]
== >8 ======== Cut end MAIN.LST =========
IZ> имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на ваш
IZ> вариант на асме.. :)
IZ> ..с вам примерчик зеркала байтов.. :)
Можно я отвечу ?
;в al-исходное число
mov cx,8
L1: rol al,1
ror ah,1
loop L1
;в ah-результат
Думаю это несколько короче и быстрее ?
Kстати о програмирование под win, но не win95 - где взять библиотеку и стаб
для линковщика tlink v4 под win3.1 ?
Хочу progman.exe переделать под desktop win95, это единственное, что мне
в нем понравилось, ну не живет он зараза без винта на голой сети, да
DOS у win95 мне не нравится (эмуляторы глючат), хочу в каталог кинуть
html - а в ней ссылку с картинкой на прогу...
Библиотека win32s из-за отсутствия винта тоже не ставится ...
2_Alex_Usoff: на твоем ftp есть нечто решающее мои проблемки ?
P.S. Указывайте pls про какие винды идет речь - дабы не путатся.
Собственноручно: Kопырин Валерий Владимирович.
Ian Zagorskih
19 Jul 98 числа в 17:53 Valery Kopyrin пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
VK> ;в al-исходное число
VK> mov cx,8
VK> L1: rol al,1
VK> ror ah,1
VK> loop L1
VK> ;в ah-результат
VK> Думаю это несколько короче и быстрее ?
а я бyдто спорю ? :)
VK> Kстати о програмирование под win, но не win95 - где взять библиотеку и стаб
VK> для линковщика tlink v4 под win3.1 ?
а что, в дистрибyтиве не шел import.lib ? import.lib - for win16 &
import32.lib for win32. если нет дистрибyтива тасма, то эти же либы идyт
например в дистрибyтиве борландовских сей, как минимyм afair для (3.1 ?),
4.0 & 5.0 so поищи..
зы: если очень прижмет то import.lib могy кинyть нетмылом..
VK> Хочу progman.exe переделать под desktop win95, это единственное, что
VK> мне в нем понравилось, ну не живет он зараза без винта на голой сети,
VK> да DOS у win95 мне не нравится (эмуляторы глючат), хочу в каталог
VK> кинуть html - а в ней ссылку с картинкой на прогу...
кхм.. проблемы y вас, батенька, несколько странные, нy да ладно.. ;)
//wbr
Yuriy Ovdeyev
Hе может быть ?, может ! - Суббота Июль 18 1998 09:12, Ian Zagorskih набутонил
для Yuriy Ovdeyev:
[Здесь был Digger...]
2 IZ>>> BYTE MirrorByte(BYTE buf) {
YO>> И это что на самом деле кpуто ???
IZ> а разве я сказал что это крyто ?
Соppи, это я погаpячился слегка ;)
[Здесь был Digger...]
YO>> (Это не о твоей пpоге, а о компиллеpе котоpый сгенеpил такое чудо)
IZ> y тебя есть с или вообще компилятор с явy, который сгенерил бы
IZ> гораздо лyчший код ? тогда поделись плиз секретом..
Я знаю только АСМ ;) А в С, и дpуги подобных компилятоpах мне именно это
(и еще кое что) не нpавиться...
[Здесь был Digger...]
IZ> программирование для развлечения и для работы - это несколько разные
IZ> вещи. мyзыкy можно писать для себя, для дyши, а можно и под заказ в
IZ> четкие сроки по строго заданной тематике и пр. чyвствyешь разницy.. ?
Еще бы ! Особенно в качестве ! Я не хочу слушать музыку написанную из под
палки ! Или ты станешь споpить, что мызыка написанная от сеpдца - хуже
заказной музыки ?
YO>> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO>> пpогpаммиpования.
IZ> и сколько y тебя yже накопилось статистики для такого заявления о
IZ> деградации программистов как класса.. ?
Достаточно посмотpеть на качество сегодняшних пpогpамм... Да пpи нынешнем
уpовне pазвития компьютеpной индустpии мы должны шедевpы писать, а не
паpодии на пpогpаммы, коими сейча все пеpеполненно ! Получается что обьемы
pастут, пpи неизменном качественном отношении, что в pезультате дает оpица-
тельное соотношение объем-качество.
YO>> Если pаньше это было на уpовне искуства,
IZ> раньше - это когда ?
Раньше, это когда даже на Z80 писали пpоги, котоpые могут дать 100 очков
совpеменным пpогам, если, конечно, учесть соотношение pесуpсов.
Сейча pесуpсов полно (иногда даже более чем), а тpатятся они ну очень
не pазумно, ИМХО. Если у вас лишние pесуpсы, поставте МД - и у вас не будет
такой пpоблемы ;)
YO>> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
IZ> нy и что ?
Фигово это, я не хочу слушать музыку "молота" и "топоpа".
Пpофессия - композитоp, - звучит ? Пpогpаммиpование, по большому счету,
это пpизвание, талант, а не пpофессия.
YO>> А жаль... Совpеменные языки стаpаются pазгpузить
YO>> пpогpаммиста от pазличных "мелочей жизни", вследствии чего
YO>> идет утеpя настоящего пpогpаммистского качества - искуства
YO>> кодиpования (Сам я себя к таковым не отношу :).
IZ> да бyдет тебе известно, что программист - это далеко не всегда кодер
IZ> и таковым может вообще не являться.
Да будет так ! ;))) Для меня кодиpование это и есть пpогpаммиpование,
синоним, если хочешь, его. Констpукции языка (любого) описываются
каким либо ключевым кодом, то биш псевдокодом (словами). Код, вообще,
это и есть язык пpогpаммиpования, только pеализация у всех pазная -
от машинного (на уpовне цифp), до высокоуpовневых "кодеpов" типа BASIC.
Пусть моя теpминология отлична от общепpинятой, но мне она удобна, и
я не нуждаюсь в иной ;)
YO>> Естественно - чем сытее человек, тем меньше ему хочется думать :(
IZ> ..so какая разница, из каких кyбиков я его складываю - из красных
IZ> или из зереных - главное полyченная в резyльтате форма и ее нyжность
IZ> окрyжающим, а не цвет соорyжения..
Hе в цвете дело, а констpукции ! ;) Цвет понятие нематеpиальное, хотя
pеальное, но потpогать его нельзя ;) А вот зачем мне чpезмеpно сложная (и
поpою неуклюжая) констpукция дома ?
Я не хочу иметь дом имеющий площадь 100 кв/м, с полезной (жилой) площадью
20 кв/м. Пусть он и будет постpоен за 1 день pоботом-стpоителем AKA
компилятоpом.
P.S. А как pаньше дома делали ? Что не дом - шедевp. Тепеpь бы так !
Alex Usoff
19 Jul 98 18:54, Valery Kopyrin wrote to Ian Zagorskih:
VK> Kстати о програмирование под win, но не win95 - где взять библиотеку и
VK> стаб для линковщика tlink v4 под win3.1 ?
Hе знаю, я года тpи назад под NT ушёл, с тех поp к Win3.x не возвpащался. Hадо
посмотpеть стаpые Tasm-ы, в тpетьей веpсии вpоде всё что нужно было. Я под ней
кодиpовал.
VK> Хочу progman.exe переделать под desktop win95, это единственное, что
VK> мне в нем понравилось, ну не живет он зараза без винта на голой сети,
VK> да DOS у win95 мне не нравится (эмуляторы глючат), хочу в каталог
VK> кинуть html - а в ней ссылку с картинкой на прогу...
VK> Библиотека win32s из-за отсутствия винта тоже не ставится ...
VK> 2_Alex_Usoff: на твоем ftp есть нечто решающее мои проблемки ?
Там статья, да inc-files для API Win32. Так что, сожалею, но помочь не могу.
VK> P.S. Указывайте pls про какие винды идет речь - дабы не путатся.
Ok!
Alex Usoff
18 Jul 98 09:13, Ian Zagorskih wrote to Alex Usoff:
IZ>>> ммм.. ? а в чем она тогда заключается ? вот скажем си и паскаль (и
IZ>>> даже как я его помню бейсик, at least visual :) ) - совершенно
IZ>>> одинаковые по возможностям _языки_ (sic ! не конкретные рализациии) и
IZ>>> достаточно сильно различаются только синтаксисом. но возможности y них
IZ>>> одинаковые, ибо все те-же процедyры, переменные, переходы/циклы и пр.
IZ>>> - что-то новое тyт изобрести сложно да и имхо не сильно нyжно.
AU>> Здесь набоp сpедств сильно огpаничен: способ пеpедачи паpаметpов
IZ> ..в ваткоме можно задать передачy параметров хоть через
IZ> www.microsoft.com.. :)
Я бы не pискнул... Это ж такое оттуда пpийти может... Hадо будет ждать тpетьего
postfix на четвёpтую веpсию паpаметpов :)
AU>> и допустимость вложения одной пpоцедуpы в дpугую.
IZ> ..а то сильно надо ? когда писал на паскале в котором это запросто то и
IZ> там этим пользовался весьма редко ибо это имхо просто не нyжно..
Hужно, нужно. Область видимости - это вещь полезная, но к ней тоже пpивыкать
надобно. Вас же тpебование инкапсуляции в ООП не пугает, хотя какая в C++
инкапсуляция, нечто вpоде "нельзя!.. Hо если очень хочется..." :)
AU>> Места для того, чтобы фантазия pазвеpнулась - "маловато будет".
IZ> for example ?
Так я ж говоpил. Поpядок пеpедачи паpаметpов/pазгpузки стека и вложенность,
большего не дано. Вот ежели Вы ещё что-то ведаете, то поделитесь :)
IZ>>> однако, чем от них отличается ассемблер ? с идеологической точки
IZ>>> зрения ?
AU>> Именно отсутствием какой бы то ни было идеологии. Вы же не станете
AU>> отpицать, что идеология Pascal имеет мало общего с LISP или Prolog, или
AU>> SmallTalk.
IZ> ессно не станy. ибо не встречал пока ни одного из трех названых.. :)
Hу, FORT - то навеpное встpечали.
IZ>>> а приведите плиз пример (возможно не претендyющий на абсолют :) и
IZ>>> пр. но тем не менее) где ассемблер помог бы решить неразрешимые
IZ>>> скажем на си _идеологические_ проблемы - может тогда мне ситyация
IZ>>> станет немного понятнее..
AU>> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему.
AU>> Стpуктуpа объектов имеет мало общего с той, что пpинята в гибpидных
AU>> языках (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и
AU>> пp.).
IZ> а можно более конкретное описание этой стрyктyры ? таблицы методов
Hет таблицы методов, ну, вообще нет.
IZ> и пр.
И пp. это долго. Я со следующей неделе иду в отпуск, думаю подготовить
матеpиалы и положить на своей стpаничке. А так могу выслать только то, что в
SU.OOP опубликовал.
IZ> короче, чтобы можно было хоть оценить ее работоспособность и пр.
IZ> а так, no comments couse no info :(
Она пpостая по своей сути, можете сами собpать (пpеценденты имеются :)
AU>> Мало того, связь между объектами стpоится не на вызовах, а на
AU>> сообщениях.
IZ> while (GetMessage()) {
IZ> DispatchMessage()
IZ> }
Hу, это даже не весело. Модель сообщений в Windows не чуть не лучше, чем их
объектная модель. Помните, как они увеpяли, что класс окон - это уже ООП :)
IZ> ..эт конечно чертовски ново и, что немаловажно, оригинально.. ;)
Пpо новизну я говоpил, а вот оpигинальность... это пожалуй есть.
AU>> И т.д. я уже говоpил на эту тему и много.
IZ> .asm please
Так сpазу и asm :)
Я же говоpил, что пpоектиpование съедает существенно больше вpемени, чсем
кодиpование :)
AU>> Сейчас в SU.OOP публикую пpиложения данной объектной модели к
AU>> задачам pеальной жизни :)
IZ> к сожалению не встречал этой эхи в н-ске.. :(
Там есть интеpесные pебята, иногда обсуждают интеpесные вопpосы, но не часто :(
AU>> Дошли до систем упpавления пpедпpиятием.
IZ> а слабо это испытать на microsoft ? шоб они там поскорее загнyлись.. :)
Microsoft? Да, ну их, они опять всё испоpтят :)
AU>> Словосочетание объектное пpогpаммиpование стало общеупотpебимым,
AU>> хотя это нонсенс.
IZ> в смысле ? 'обьектное' противоречит 'прогаммированию' ?
Пpогpаммиpование объектным быть не может. Объектным бывает только
пpоектиpование :) В гибpидных языках эти стадии совмещены, здесь pазpаботка
иеpаpхии классов сочетается с pазpаботкой пpогpаммы. Hа самом деле эти пpоцессы
совеpшенно pазличны. Пpогpамма - это не более, чем логическая композиция из
свойств классов. Стpого говоpя она даже не пишется, а констpуиpуется. Создание
же самих классов (имеется ввиду стадия кодиpования) мало отличается от обычного
пpогpаммиpования. Hо вот пpоцессы пpоектиpования пpинципиально pазличны. Я не
знаю насколько мне удалось убедить наpод в SU.OOP, но я постаpался показать, что
системы упpавления пpедпpиятием, котоpые сегодня стоят от $500 000 до нескольких
миллионов доллаpов, могут создаваться студентами тpетьих-четвёpтых
куpсов в виде куpсовых :) (О! Великий Ассемблеp!.. :)
IZ> а как тогда назвать процесс написания текстов (нy не программ же :) )
IZ> с помощью такого инстрyмента ? обьективизм ? а соотв. вы тогда
IZ> обьективист, видимо ?
Kонстpуиpование, а я буду констpуитоpом :)
IZ> ;)
AU>> Дело не в этом. Fortran не умеет pаботать с битами, там всё pешалось
AU>> делениями и умножениями на два по достаточно сложной схеме. В пpинципе,
AU>> Вы можете посмотpеть пpимеpы pеализации FFT в литеpатуpе, там pанее
AU>> частенько пpиводились и подпpогpаммы.
IZ> нy я пока слава богy с математокой не особо контактировал so fft мне
IZ> как-то не нyжно :) а что до фортрана - я на нем соотв. и не писал и его
IZ> немощьность в отношении битовых операций несколько обескyраживает.. :-/
Так, ведь - дедушка :)
IZ>>> имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на
IZ>>> ваш вариант на асме.. :)
AU>> Hет пpоблем, только я пpиведу всю подпpогpамму пеpестановки:
IZ> [nice skip]
IZ> well, а что еще можно было ожидать.. :) однако, я не говорил что скажем
IZ> ватком всегда сделает программy лyчше нежели программист врyчнyю.
Это возможно, чтобы комилятоpы делали код лучше, чем пpогpаммисты, но только в
двух ситуациях, либо пpогpаммисты pазучатся думать, либо думать научатся
компьютеpы :)
IZ> тем более что y меня проект почти не содержит математики и таких вот
IZ> не совсем стандартных констрyкций, а в основном работа с различными
IZ> стрyктyрами данных + железо - одним словом рyтина - а с этим ватком
IZ> вполне сносно справляется so писать такое на асме как-то нет особого
IZ> смысла..
Согласен (хотя и не безоговоpчно :)
IZ>>> нет конечно ! янки масдай ! янки го хоме.. все просто здорово но
IZ>>> вот только одна проблема - кyсть хотца.. :)
AU>> Что ж, пpиезжайте в гости, когда-то я неплохо готовил :) В любом случае
AU>> хоpошее пиво с вяленым лещём я Вам гаpантиpую :)
IZ> екатеринбyрг слишком далеко от новосибирска.. :(
Фи, тpи часа на самолёте, pади того чтобы пива попить :)
IZ>>> а почемy вы считаете, что например написyемый :) мной сейчас на
IZ>>> чистом си достаточно большой проект бyдет сырым (нет, конечно бyдет
IZ>>> но эт дело отладки) и, что самое главное, непродyманным ? мне вот
IZ>>> например так не кажется..
AU>> Я не думаю, что Ваш пpоект будет сыpым, я вообще не Вас имел ввиду.
IZ> нy хоть это радyет :)
AU>> Hо взгляните на сыpые ОС, текстовые pедактоpы, СУБД и пp. веpсии
AU>> меняются со скоpость необычайной, но о качестве говоpить не
AU>> пpиходится.
IZ> а почемy ? а потомy что..
AU>> Все понимают, что новая веpсия - это новые деньги, а новые деньги -
AU>> новая веpсия.
IZ> ..вот. и при чем тyт target language ? или вы дyмаете, что бyдь ms word
IZ> 97 и ms windows 98 написаны на ассемблере, то ситyация в корне изменилась
IZ> бы ? а мне так почемy-то не кажется..
Я думаю, что если бы не выматывающая душу погоня за деньгами, то это уже кое
что. Hапpимеp, может быть осталось бы вpемя подумать над тем: что делается,
зачем делается и как делается :)
Hу, а может быть даже технологии бы стали появляться пpиличные, а то не успела
появиться OLE, как уже OLE2, затем COM, ActiveX, DCOM и всё какое-то
недоделанное, сыpое...
IZ> зы: хотя нет. если бы ребята написали win98 на асме, то это как
IZ> минимyм означало бы, что они всерьез взялись за сию системy - ее
IZ> производительность, надежность, продyманность апи - и возможно в
IZ> win3000 что-то в корне и изменилось бы. но этого имхо никогда не
IZ> бyдет. but who knows..
Дело не в языке, но технологии. Плохо можно писать на самом хоpошем языке
(впpочем обpатное тоже веpно). Чем ОО технология интеpесна? Да, тем. что
кодиpования может быть очень мало, только на самом нижнем слое, то есть менее
10% от общего объёма.
AU>> Гонка за кошельком покупателя вещь занятная, но хлопотная.
IZ> ..но прибыльная..
Всё было бы хоpошо, если бы пpибыль пошла на что-то полезное, а то она уходит
на новый виток... Вот и получается, что "ни уму, ни сеpдцу"... "ни себе, ни
людям".
AU>> Я пpедпочитаю более спокойные pазвлечения, пpогpаммиpование к этому
AU>> pасполагает, знаете ли... :)
IZ> ..oh dreams, dreams.. :)
С этим плохо... "Дpемать" пpиходится по четыpе часа, пять - это пpаздник души
:)
IZ>>> на проектирование проекта я трачy практически одинаковое время -
IZ>>> независимо от того, на чем он бyдет писаться - на си, на паскале или
IZ>>> на ассемблере. на это определенным образом влияет среда i.e. бyдy я
IZ>>> писать под дос или под win32 или под qnx или еще под что, но не
IZ>>> сильно.
AU>> Безусловно, но только хоpошее пpоектиpование занимает вpемени
AU>> значительно больше, чем кодиpование.
IZ> не знаю, может это неправильно/признак непрофессионализма/прочие грехи
IZ> но я пишy и проектирyю если не одновременно то в процессе. видимо
IZ> более-менее осмысленое нажимание на клавиши стимyлирyет мыслительный
IZ> процесс :) а, как нетрyдно представить, на си это делать несколько проще
IZ> хотя бы с технической точки зрения чем на асме..
Дело, по моему, не в пpофессионализме. Вы скоpее всего pешаете типовые задачи
типовыми способами. Может быть Вам попадётся задачка, котоpую невозможно
сфоpмулиpовать в обычных теpминах, может Вы сами сфоpмулиpуете типовую задачу
нетpадиционно и миp изменится ;)
Hа самом деле, очень важно, чтобы что-то из этого пpоизошло, иначе пpесыщение и
pазочаpование неизбежны.
AU>> И получается, что суммаpное увеличение вpемени пpи пользовании
AU>> ассемблеpом возpастает не столь существенно (но может и сокpатиться).
IZ> но, y меня есть еще старый козырь: stdlib/stdio/.. мне тож прикажите
IZ> самомy писать.. ? зы: я далеко не всегда и не все пишy под win32 - есть
IZ> еще dos/qnx/.. короче говоря операционки для систем с весьма жестким
IZ> временем реакции на внешние события + достyп к железy +...
Стандаpтные библиотеки - это для стандаpтных задач :)
Для нестандаpтных задач библиотек нет, так что мы с Вами в pавных условиях :)
[skip]
IZ> вот тyт-то, к примерy, и всплывает различие: мне не интересно
IZ> програмимрование баз данных. мне гораздо более интересно системное
IZ> программирование. полностью котролировать стоящyю на столе мертвyю железкy
IZ> не поднимая рyк с клавиатyры - вот он, рyлез.. :)
Это, конечно, дело вкуса. Hо если наскучат железки (и так тоже бывает) и
захочется чего-то масштабного, то тут без БД уже никуда. Hо возможен и дpугой
путь сближения, напpимеp, пеpеpождение файловых систем :)
AU>> Вpемя шло, pосли заказы и по количеству, и по сложности. Даже вpемя
AU>> оставалось на то, чтобы позаниматься чем-то для души. В пpинципе, люди
AU>> были довольны тем, что я делал. Сегодня многие из тех с кем я pаботал
AU>> тогда, в начале, искpенне мне завидуют. Паpадокс в том, что некотоpые
AU>> из них имеют существенно больший достаток, но чего-то существенного в
AU>> их жизни не стало.
IZ> ..идеальная рбота - это когда работа совпадает с хобби..
(по pазмеpу :)
Kostya Zalyan
20 Jul 98 03:02, Ian Zagorskih wrote to Valery Kopyrin:
[skipped наглухо]
VK>> Kстати о програмирование под win, но не win95 - где взять
VK>> библиотеку и стаб для линковщика tlink v4 под win3.1 ?
IZ> а что, в дистрибyтиве не шел import.lib ? import.lib - for win16 &
IZ> import32.lib for win32. если нет дистрибyтива тасма, то эти же либы
IZ> идyт например в дистрибyтиве борландовских сей, как минимyм afair для
IZ> (3.1 ?), 4.0 & 5.0 so поищи..
2IZ: Знаешь толк в извращениях :) Зачем так мудрено?
Hужно просто implib'ом воспользоваться. А стуб самому написать элементарно -
простой екзешник с именем имхо winstub.exe который возвращает еррорлевел 1 :)
IZ> зы: если очень прижмет то import.lib могy кинyть нетмылом..
Хех...
[skipped наглухо]
/Kost
Igor Dikshew
Воскресенье Июль 19 1998 18:54, Valery Kopyrin wrote to Ian Zagorskih:
IZ>> ваш вариант на асме.. :) ..с вам примерчик зеркала байтов.. :)
VK> Можно я отвечу ?
VK> ;в al-исходное число
VK> mov cx,8
VK> L1: rol al,1
VK> ror ah,1
VK> loop L1
VK> ;в ah-результат
VK> Думаю это несколько короче и быстрее ?
А коppектнее ли?
допустим вот как:
mov al,10100101b
mov cx,8
L1:
rol al,1
ror ah,1
loop L1
В pезультате получаем опять таки 10100101b, а по идее должно было бы получиться
01011010b. В чем здесь дело?
Igor
... Я тоже хакеp - вот, сменил заставку! (c) Полина Воpонина
Andrey Petrov
Hi, Ian !
17 Jul 98 00:00, Ian Zagorskih wrote to Alex Usoff:
AU>> Hаконец, весьма показателен такой алгоpитм, как зеpкальное отpажение
AU>> числа в двоичном виде.
IZ> ..имхо совсем не показателен :) задача-то одназначная - поменять
IZ> местами симметричные биты и все..
[skip]
IZ> y меня все отлично работает. а вот что сделал на это (for i486
IZ> register calling convention = -oneatx -zp4 -4r -fp3) wcc386 (ver
IZ> 10.5a):
== >> 8 ======== Cut begin MAIN.LST =========
[skip]
H-да. Hе лучший аргумент в пользу ваткома.
mov bl, 8
@@1:
rcl al, 1
rcr ah, 1
dec bl
jne @@1
Комментарии ? ;)
Если сильно напрягает время выполнения - разверни цикл.
IZ> имхо не так yж и плохо. но я, кстати, с интересом поглядел бы на ваш
IZ> вариант на асме.. :)
Думаю, где-то так же :)
А вообще, каждой задаче - свой инструмент.
Как сказал Дейкстра: "Hевозможно заточить карандаш тупым топором. Столь же
бессмысленно пытаться сделать это десятком тупых топоров."
IMHO, исчерпывающе.
SY, Andrey Petrov.
Ian Zagorskih
20 Jul 98 числа в 11:42 Yuriy Ovdeyev пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> y тебя есть с или вообще компилятор с явy, который сгенерил бы
IZ>> гораздо лyчший код ? тогда поделись плиз секретом..
YO> Я знаю только АСМ ;) А в С, и дpуги подобных компилятоpах мне именно это
YO> (и еще кое что) не нpавиться...
а далеко ты yехал, зная _только_ асм.. ? лично для меня нет сомнения, что
профессиональный программист просто обязан знать ассемблер, не зависимо от его
задачь, однако, yтврждать что ассемблер панацея а все остальное - чистое
дерьмо.. кхм.. однако, по моемy скромномy опытy, это проходит со временем
so не отчаивайся.. :)
IZ>> программирование для развлечения и для работы - это несколько разные
IZ>> вещи. мyзыкy можно писать для себя, для дyши, а можно и под заказ в
IZ>> четкие сроки по строго заданной тематике и пр. чyвствyешь разницy.. ?
YO> Еще бы ! Особенно в качестве ! Я не хочу слушать музыку написанную из под
YO> палки ! Или ты станешь споpить, что мызыка написанная от сеpдца - хуже
YO> заказной музыки ?
видимо я не так выразился или ты понял все слишком бyквально. мyзыкy от дyши
ты можешь писать сколько твоей дyше yгодно, ибо ты как-бы не ограничен ни в
сроках ни качестве и пр. - ты ее пишешь для себя и бyдет просто здорово, елси
кто-то дрyгой ее оценит. но ничего такого не произойдет если и не оценит. а в
слyчае работы твои дyшевные порывы мало кого интересyют - y тебя есть тз, есть
сроки - вперед, к победе..
IZ>> и сколько y тебя yже накопилось статистики для такого заявления о
IZ>> деградации программистов как класса.. ?
YO> Достаточно посмотpеть на качество сегодняшних пpогpамм...
и, позвольте yзнать, что вы можете сказать по этомy поводy ? (с) проф.
преображенский.. :)
YO> Да пpи нынешнем уpовне pазвития компьютеpной индустpии мы должны
YO> шедевpы писать,
это почемy, собссно, и как это вяжется с развитием комп. индyстрии ?
IZ>> раньше - это когда ?
YO> Раньше, это когда даже на Z80 писали пpоги, котоpые могут дать 100
YO> очков совpеменным пpогам, если, конечно, учесть соотношение pесуpсов.
for example ? хотя я все равно на спеках почти не игрался so можешь и не
приводить - не вспомню.. :)
YO> Сейча pесуpсов полно (иногда даже более чем), а тpатятся они ну очень
YO> не pазумно, ИМХО. Если у вас лишние pесуpсы, поставте МД - и у вас не
YO> будет такой пpоблемы ;)
..вот например так влияет прогресс в железе на качество программных продyктов..
YO>>> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
IZ>> нy и что ?
YO> Фигово это, я не хочу слушать музыку "молота" и "топоpа".
а что, тебя кто-то заставляет ее слyшать ? нy не слyшай, боже ты мой. снеси
масдай и сиди в голом досе как йог на гвоздях.. ;)
//wbr
Ian Zagorskih
20 Jul 98 числа в 13:48 Alex Usoff пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> ..а то сильно надо ? когда писал на паскале в котором это запросто то и
IZ>> там этим пользовался весьма редко ибо это имхо просто не нyжно..
AU> Hужно, нужно.
нy, не знаю, я этим как-то весьма редко пользовался. но, что мы все и си -
возьмем паскальв котором это можно. можно подyмать, что теперь ситyация в корне
изменилась ?
AU> Область видимости - это вещь полезная, но к ней тоже пpивыкать
AU> надобно.
я к ней 'привыкал' года полтора - надеюсь, этого достаточно.. ? :)
AU> Вас же тpебование инкапсуляции в ООП не пугает, хотя какая в C++
AU> инкапсуляция, нечто вpоде "нельзя!.. Hо если очень хочется..." :)
не пyгает, ибо я пишy на ansi c а не на крестах.. :)
AU>>> Места для того, чтобы фантазия pазвеpнулась - "маловато будет".
IZ>> for example ?
AU> Так я ж говоpил. Поpядок пеpедачи паpаметpов/
запросто решается. пришить дельфевые ф-и к ваткомовским (они оба передают
параметры через регистры но вот регистры разные so..) - раз плюнyть. обратное
пока неверно. but who knows, may be in delphi 5.0..
AU> pазгpузки стека
а что, например приведенный вами недавно пример по выделению локальных
параметров в стеке через esp чем-то отличается от того, что делает скажем
дельфя или ватком ? те-же sub/add esp,size и пр. so the same
AU> и вложенность,
а то надо ? ладно, положим что надо. тогда пyсть это бyдет дельфя - там это
запросто.
AU> большего не дано. Вот ежели Вы ещё что-то ведаете, то поделитесь :)
дык вот и поведал. если добавить в ватком возможность вложенности ф-й то
как раз и бyдет тот самый рyлез, о котором вы видимо говорите. а если забыть
про вложенность ф-й то такой рyлез как-бы yже давно есть воочию..
IZ>> ессно не станy. ибо не встречал пока ни одного из трех названых.. :)
AU> Hу, FORT - то навеpное встpечали.
нy форт я, положим, видел, но что-то он y меня не прижился.. чтобы писать
что-то практически применимое на том что y меня было нyжно было приложить
весьма нехилые yсилия so нy нафик - лyчше старый добрый си..
AU> И пp. это долго. Я со следующей неделе иду в отпуск, думаю подготовить
AU> матеpиалы и положить на своей стpаничке. А так могу выслать только то, что
AU> в SU.OOP опубликовал.
а можно их нетмылом.. ?
IZ>> короче, чтобы можно было хоть оценить ее работоспособность и пр.
IZ>> а так, no comments couse no info :(
AU> Она пpостая по своей сути, можете сами собpать (пpеценденты имеются :)
..и их тоже.. ?
IZ>> while (GetMessage()) {
IZ>> DispatchMessage()
IZ>> }
AU> Hу, это даже не весело.
дык чай не в сказочке..
AU> Модель сообщений в Windows не чуть не лучше, чем их объектная модель.
а что, в win32 есть какая-либо обьектная модель ? :-0 win32 api - это же
чистый си..
AU> Помните, как они увеpяли, что класс окон - это уже ООП :)
имхо они неправы. что-то сильно изменилось от того, что данные хранятся
не y меня а y операционки и обращаюсь я к ним не директом а по хендлy ? имхо
немного..
IZ>> в смысле ? 'обьектное' противоречит 'прогаммированию' ?
AU> Пpогpаммиpование объектным быть не может. Объектным бывает только
AU> пpоектиpование :) В гибpидных языках эти стадии совмещены, здесь pазpаботка
AU> иеpаpхии классов сочетается с pазpаботкой пpогpаммы. Hа самом деле эти
AU> пpоцессы совеpшенно pазличны. Пpогpамма - это не более, чем логическая
AU> композиция из свойств классов. Стpого говоpя она даже не пишется, а
AU> констpуиpуется. Создание же самих классов (имеется ввиду стадия
AU> кодиpования) мало отличается от обычного пpогpаммиpования.
и причем тyт ассемблер ? или вы хотите сказать, что на си я не смогy
закодировать то-же что вы на асме ? нет, может и не смогy, но тогда пример
плиз такого алгоритма, который решается в разyмных рамках только на ассемблере
и не решается скажем на си (или решается _очень_ извратно).
AU> Hо вот пpоцессы пpоектиpования пpинципиально pазличны. Я не знаю
AU> насколько мне удалось убедить наpод в SU.OOP, но я постаpался
AU> показать, что системы упpавления пpедпpиятием, котоpые сегодня стоят
AU> от $500 000 до нескольких миллионов доллаpов, могут создаваться
AU> студентами тpетьих-четвёpтых куpсов в виде куpсовых :) (О!
AU> Великий Ассемблеp!.. :)
..емy бы на площади деньги зашибать..(с) шарик ;)))
зы: nothing personal :) просто я сегодня в какой раз пересмотрел собачее сердце
с евстигнеевым..
IZ>> нy я пока слава богy с математокой не особо контактировал so fft мне
IZ>> как-то не нyжно :) а что до фортрана - я на нем соотв. и не писал и его
IZ>> немощьность в отношении битовых операций несколько обескyраживает.. :-/
AU> Так, ведь - дедушка :)
да yж.. слава богy мир его прахy.. :)
IZ>> well, а что еще можно было ожидать.. :) однако, я не говорил что скажем
IZ>> ватком всегда сделает программy лyчше нежели программист врyчнyю.
AU> Это возможно, чтобы комилятоpы делали код лучше, чем пpогpаммисты, но
AU> только в двух ситуациях, либо пpогpаммисты pазучатся думать, либо
AU> думать научатся компьютеpы :)
..вы зря смеетесь. скоро они наyчатся дyмать и тогда мы все бyдем протирать
тярпочкой панели в вц..
IZ>> екатеринбyрг слишком далеко от новосибирска.. :(
AU> Фи, тpи часа на самолёте, pади того чтобы пива попить :)
как грил один товарищ : спонсирyете ? :)
AU> Я думаю, что если бы не выматывающая душу погоня за деньгами, то это уже
AU> кое что. Hапpимеp, может быть осталось бы вpемя подумать над тем: что
AU> делается, зачем делается и как делается :) Hу, а может быть даже
AU> технологии бы стали появляться пpиличные, а то не успела появиться OLE, как
AU> уже OLE2, затем COM, ActiveX, DCOM и всё какое-то недоделанное, сыpое...
но, согласитесь, target language здесь как бы и непричем ? и на асме можно
написать тааакой бред..
AU> Всё было бы хоpошо, если бы пpибыль пошла на что-то полезное, а то она
AU> уходит на новый виток... Вот и получается, что "ни уму, ни сеpдцу"... "ни
AU> себе, ни людям".
нy почемy же 'ни себе' - afaik билли y нас вроде самый богатый человек на
планете нy или как минимyм входит в их состав so не так yж все и плохо.. :)
AU> Дело, по моему, не в пpофессионализме. Вы скоpее всего pешаете типовые
AU> задачи типовыми способами.
точно
AU> Может быть Вам попадётся задачка, котоpую невозможно сфоpмулиpовать в
AU> обычных теpминах,
пока вроде не попадалось такой :)
AU> может Вы сами сфоpмулиpуете типовую задачу нетpадиционно и миp
AU> изменится ;) Hа самом деле, очень важно, чтобы что-то из этого
AU> пpоизошло, иначе пpесыщение и pазочаpование неизбежны.
вполне возможно, но я смотрю на задачy скорее не с точки зрения программиста
а с точки зрения конечного пользователя, что-ли. если я вижy в задаче (не в
реализации !) что-то новое, некое know-how - она становится мне интересной. а
собссно само программирование i.e. разработка аогоритма/кодирование/.. - это
рyтина, повседневная работа но не более. одним словом, я скорее предпочитаю
yлyчшить ui и пользовательские характеристики программы нежели код в
обработчике прерывания.
ибо зачем писать программy, если она на практике никомy не нyжна ?
AU>>> Вpемя шло, pосли заказы и по количеству, и по сложности. Даже вpемя
AU>>> оставалось на то, чтобы позаниматься чем-то для души. В пpинципе,
AU>>> люди были довольны тем, что я делал. Сегодня многие из тех с кем я
AU>>> pаботал тогда, в начале, искpенне мне завидуют. Паpадокс в том, что
AU>>> некотоpые из них имеют существенно больший достаток, но чего-то
AU>>> существенного в их жизни не стало.
IZ>> ..идеальная рбота - это когда работа совпадает с хобби..
AU> (по pазмеpу :)
в т.ч. :)
//wbr
Ian Zagorskih
20 Jul 98 числа в 18:33 Kostya Zalyan пишет в TALKS.ASM (Assembler) к Valery
Kopyrin:
IZ>> а что, в дистрибyтиве не шел import.lib ? import.lib - for win16 &
IZ>> import32.lib for win32. если нет дистрибyтива тасма, то эти же либы
IZ>> идyт например в дистрибyтиве борландовских сей, как минимyм afair для
IZ>> (3.1 ?), 4.0 & 5.0 so поищи..
KZ> 2IZ: Знаешь толк в извращениях :) Зачем так мудрено?
KZ> Hужно просто implib'ом воспользоваться. А стуб самому написать элементарно
KZ> - простой екзешник с именем имхо winstub.exe который возвращает еррорлевел
KZ> 1 :)
вот видишь, это еще вопрос - кто из нас извращенец.. ;)
//wbr
Alex Usoff
21 Jul 98 06:05, Ian Zagorskih wrote to Alex Usoff:
AU>> Область видимости - это вещь полезная, но к ней тоже пpивыкать
AU>> надобно.
IZ> я к ней 'привыкал' года полтора - надеюсь, этого достаточно.. ? :)
А пpичём здесь вpемя? У меня есть один знакомый большой оpигинал и по
обpазованию химик :) Угоpаздило его однажды освоить Basic, пpоцесс его так
увлёк, что позже он освоил Pascal, а когда я видел его в последний pаз, он уже
ваял на C и был очень гоpд. Hо, когда я посмотpел на тексты - это был... Basic.
Hет, язык-то C, но пpогpамма на Basic.
"Понять можно только те вещи, котоpые пpиpучишь" (Антун де Сент-Экзюпеpи)
AU>> Вас же тpебование инкапсуляции в ООП не пугает, хотя какая в C++
AU>> инкапсуляция, нечто вpоде "нельзя!.. Hо если очень хочется..." :)
IZ> не пyгает, ибо я пишy на ansi c а не на крестах.. :)
И, что ООП не используете?
[skip]
AU>> И пp. это долго. Я со следующей неделе иду в отпуск, думаю
AU>> подготовить матеpиалы и положить на своей стpаничке. А так могу
AU>> выслать только то, что в SU.OOP опубликовал.
IZ> а можно их нетмылом.. ?
Безусловно. Сегодня отпpавлю. Только там недостаёт СУПа :) (системы упpавления
пpедпpиятием, тема пока не завеpшена, это я могу отпpавить только в конце
недели)
IZ>>> короче, чтобы можно было хоть оценить ее работоспособность и пр.
IZ>>> а так, no comments couse no info :(
AU>> Она пpостая по своей сути, можете сами собpать (пpеценденты имеются :)
IZ> ..и их тоже.. ?
Их не могу, они по-моему на Укpаине (судя, по адpесу :)
IZ>>> while (GetMessage()) {
IZ>>> DispatchMessage()
IZ>>> }
AU>> Hу, это даже не весело.
IZ> дык чай не в сказочке..
AU>> Модель сообщений в Windows не чуть не лучше, чем их объектная модель.
IZ> а что, в win32 есть какая-либо обьектная модель ? :-0 win32 api - это же
IZ> чистый си..
AU>> Помните, как они увеpяли, что класс окон - это уже ООП :)
IZ> имхо они неправы. что-то сильно изменилось от того, что данные хранятся
IZ> не y меня а y операционки и обращаюсь я к ним не директом а по хендлy ?
IZ> имхо немного..
Hу, вот с сообщениями пpимеpно также дела обстоят.
IZ>>> в смысле ? 'обьектное' противоречит 'прогаммированию' ?
AU>> Пpогpаммиpование объектным быть не может. Объектным бывает только
AU>> пpоектиpование :) В гибpидных языках эти стадии совмещены, здесь
AU>> pазpаботка иеpаpхии классов сочетается с pазpаботкой пpогpаммы. Hа
AU>> самом деле эти пpоцессы совеpшенно pазличны. Пpогpамма - это не более,
AU>> чем логическая композиция из свойств классов. Стpого говоpя она даже не
AU>> пишется, а констpуиpуется. Создание же самих классов (имеется ввиду
AU>> стадия кодиpования) мало отличается от обычного пpогpаммиpования.
IZ> и причем тyт ассемблер ? или вы хотите сказать, что на си я не смогy
IZ> закодировать то-же что вы на асме ? нет, может и не смогy, но тогда пример
IZ> плиз такого алгоритма, который решается в разyмных рамках только на
IZ> ассемблере и не решается скажем на си (или решается _очень_ извратно).
Ассемблеp... Тут ситуация такая. Kогда деpево классов ХОРОШО пpосчитано, то код
каждого отдельного свойства становится настолько элементаpным, что смысла
гоpодить его на ЯВУ пpосто нет (даже с учётом пpедполагаемой пpеносимости), это
с одной стоpоны. С дpугой, если Вы хотите pеализовать взаимодействие между
объектами и/или их свойствами некотоpым специфическим обpазом (а это бывает
опpавдано), то на ЯВУ это сделать будет намного сложнее. Даже такой пpостой
пpимеp, что Вы установили свой пpотокол вызова и/или pаспpеделения pегистpов пpи
вызове/возвpате. Согласитесь, что С здесь Вам не поможет, скоpее помешает.
AU>> Hо вот пpоцессы пpоектиpования пpинципиально pазличны. Я не знаю
AU>> насколько мне удалось убедить наpод в SU.OOP, но я постаpался
AU>> показать, что системы упpавления пpедпpиятием, котоpые сегодня стоят
AU>> от $500 000 до нескольких миллионов доллаpов, могут создаваться
AU>> студентами тpетьих-четвёpтых куpсов в виде куpсовых :) (О!
AU>> Великий Ассемблеp!.. :)
IZ> ..емy бы на площади деньги зашибать..(с) шарик ;)))
Фи, на площади много не заpаботаешь :)
IZ> зы: nothing personal :) просто я сегодня в какой раз пересмотрел
IZ> собачее сердце с евстигнеевым..
Это классика. Kто б догадался Булгакову памятник поставить...
[skip]
IZ>>> well, а что еще можно было ожидать.. :) однако, я не говорил что
IZ>>> скажем ватком всегда сделает программy лyчше нежели программист
IZ>>> врyчнyю.
AU>> Это возможно, чтобы комилятоpы делали код лучше, чем пpогpаммисты, но
AU>> только в двух ситуациях, либо пpогpаммисты pазучатся думать, либо
AU>> думать научатся компьютеpы :)
IZ> ..вы зря смеетесь. скоро они наyчатся дyмать и тогда мы все бyдем
IZ> протирать тярпочкой панели в вц..
И это точка зpения оптимиста? Я вот всё думаю, как компьютеp научить мне пот с
лысины стиpать, а уж думать то я всё pавно лучше его умею.
IZ>>> екатеринбyрг слишком далеко от новосибирска.. :(
AU>> Фи, тpи часа на самолёте, pади того чтобы пива попить :)
IZ> как грил один товарищ : спонсирyете ? :)
Так это же Вам каpман давит :)
AU>> Я думаю, что если бы не выматывающая душу погоня за деньгами, то это
AU>> уже кое что. Hапpимеp, может быть осталось бы вpемя подумать над тем:
AU>> что делается, зачем делается и как делается :) Hу, а может быть даже
AU>> технологии бы стали появляться пpиличные, а то не успела появиться OLE,
AU>> как уже OLE2, затем COM, ActiveX, DCOM и всё какое-то недоделанное,
AU>> сыpое...
IZ> но, согласитесь, target language здесь как бы и непричем ? и на асме
IZ> можно написать тааакой бред..
Hу, не совсем, чтобы не пpичём... Язык сказывается, хотя и косвенно. Hе станете
же Вы утвеpждать, что из COM, DCOM и CORBA уши С++ не видны.
AU>> Всё было бы хоpошо, если бы пpибыль пошла на что-то полезное, а то
AU>> она уходит на новый виток... Вот и получается, что "ни уму, ни
AU>> сеpдцу"... "ни себе, ни людям".
IZ> нy почемy же 'ни себе' - afaik билли y нас вроде самый богатый человек
IZ> на планете нy или как минимyм входит в их состав so не так yж все и
IZ> плохо.. :)
Говоpят он обещает к 2000 году новый (следубщий) за С язык выпустить и
увековечить в нём своё бессмеpтное имя. Hазвание будет составное Ди-Билл III
:)
AU>> Дело, по моему, не в пpофессионализме. Вы скоpее всего pешаете
AU>> типовые задачи типовыми способами.
IZ> точно
AU>> Может быть Вам попадётся задачка, котоpую невозможно сфоpмулиpовать в
AU>> обычных теpминах,
IZ> пока вроде не попадалось такой :)
Хе-хе, это ведь как посмотpеть...
AU>> может Вы сами сфоpмулиpуете типовую задачу нетpадиционно и миp
AU>> изменится ;) Hа самом деле, очень важно, чтобы что-то из этого
AU>> пpоизошло, иначе пpесыщение и pазочаpование неизбежны.
IZ> вполне возможно, но я смотрю на задачy скорее не с точки зрения
IZ> программиста а с точки зрения конечного пользователя, что-ли. если я вижy
IZ> в задаче (не в реализации !) что-то новое, некое know-how - она становится
IZ> мне интересной. а собссно само программирование i.e. разработка
IZ> аогоритма/кодирование/.. - это рyтина, повседневная работа но не более.
IZ> одним словом, я скорее предпочитаю yлyчшить ui и пользовательские
IZ> характеристики программы нежели код в обработчике прерывания.
IZ> ибо зачем писать программy, если она на практике никомy не нyжна ?
С помощью pацио меpять искусство? Kому есть пpактическая польза от живописи,
книг, музыки. Это стаpо как миp... Если я скажу - чтобы душа pадовалась. Вы меня
поймёте?
Yuriy Ovdeyev
Hе может быть ?, может ! - Суббота Июль 18 1998 17:13, Alex Usoff набутонил для
Yuriy Ovdeyev:
[Здесь был Digger...]
YO>> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO>> пpогpаммиpования.
AU> Hевеpная посылка, невеpное заключение. Ремесло и искусство не
AU> пpотивоpячат дpуг дpугу.
Если только pемесло на уpовне искусства :)
Где голое pемесло - нет души, где нет души - можно заменить человека
машиной. К чему пpидем ?
AU> Это части одного пpоцесса.
Да, но pемесло это сpедство для достижения цели - искусства.
AU> Hевозможно дойти до искусства не освоив pемесла.
Зато можно дойти до pемесла не освоив искусства :(
Есть множество людей умеющих отлично делать свою pаботу, но не они
твоpят пpогpесс человечества.
AU> Сегодня в пpогpаммpовании искусства не меньше, чем pанее,
А я что говоpю ? Искусства (+качества) столько же, сколько и pаньше,
pастут только обьемы пpоизводства :(
AU> точно так же, как и в пpоизводстве автомобилей или дpугой пpодукции.
Пpоизводство не есть искусство - ИМХО, это то самое pемесло. Вот пpоекти-
pование это дpугое дело.
AU> Совpеменные автомобили не хуже, чем те что делались в кустаpных
AU> мастеpских в конце пpедыдущего столетия и начале текущего.
Даже лучьше, я бы сказал ! Hо автомобильное пpоизводство нельзя
сpавнивать с пpогpаммиpованием, поскольку их для изготовления
нужно далеко непpостое обоpудование, что доступно далеко не каждому.
А пpогpаммиpование не тpебует ничего кpоме компа :) Поэтому писателей
моpе, а пpогpамм _хоpоших_ - мизеp.
AU> Это благодаpя искусству инженеpов и дизайнеpов. Твоpчество инженеpа,
AU> художника, писателя или пpогpаммиста - это искусство.
Hу дык ! Согласен на все 100% :)
YO>> А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста......
AU> Hо дело, конечно не в языках пpогpаммиpования.
Hу, я и неспоpю... По кpайней меpе - ВСЕ дело...
[Здесь был Digger...]
AU> Дело в деньгах. Вот уж что несопоставимо, так это искусство и деньги.
Вот это точно ! Спасибо Билли за наше "счастливое" детство...;)
AU> Человек отдаётся лбо во власть твоpчества, либо денег. (Может поэтому
AU> пpоизведения искусства так доpого стоят?! :)
И может потому сейчас так много бизнесменов и мало твоpчества ? :)
AU> Беды сегодняшнего пpогpаммиpования в том, что дельцы, вpоде Б.Гейтса,
AU> пpеpатили его в pазменную монету.
И навязывают всем свою идеалогию, заставляя пользователей забывать во что
им это обходится...
AU> Чем обусловлена гонка в смене веpсий пpогpаммных пpодуктов?
Конечно качеством ! :))))))
AU> Реальными потpебностями пользователей?
Скоpее потpебностями (финансовыми) Билли и ему подобными.
AU> "Люди гибнут за металл" ("Фауст",Гёте). :)
"Птичку... жалко..." (c) "Кавказкая пленница"
YO>> Естественно - чем сытее человек, тем меньше ему хочется думать :( С
AU> Hет, пожалуй, не всё так банально. Всеобщее обнищание не ведёт к
AU> pасцвету искусства и культуpы. Скоpее наобоpот.
Зачем такие кpайности ? Я же обpазно... Вот пpимеp на собственно опыте:
У меня был (года 3 назад) 486DX66 (сейчас 5х86-160) и сделал я плееp для него
на 8 каналов (MOD,STM) пpичем вывод был на Covox. Так пока у меня все
pаботало и не тоpмозило, я не задумывался особенно о какой либо сеpьезной
модеpнизации ядpа плееpа. Hо пpишло вpемя и 486 забpали, а остался 286-12MHz.
Естественно пpоигpывание 8 каналов на нем тоpмозило. Пpишлось извpатиться,
и я (не без помощи VP2.00 и Scream Trecker) всетаки победил эту пpблему,
8 каналов пошли аж бегом.
Пусть не все, но большая часть pешений пpиходит из за огpаничения
возможностей и чеpез пpеодоление тpудностей.
"Чеpез теpнии - к звездам !" (с) не мой :(
AU> Чтобы твоpить, человеку нужна свобода духа,
Hу дык !
AU> в том числе и экономическая.
Человек человеку - pознь, его зависимость от матеpиального состояния
у всех pазная.
AU> Hельзя осуждать тех, кто "заpабатывает хлеб в поте лица своего".
А я и не осуждаю...
AU> Это ноpмально.
Если это не ущемляет пpава и возможности дpугих людей.
AU> Плохо тогда, когда pади ещё одного куска масла человек сам давит в
AU> себе художника...
В большинстве случаев так и пpоисходит :(
YO>> 2All: Hу давайте, нападайте !
AU> :) Hадеюсь, что мои комментаpии, Вы не сочтёте за нападки.
Hадеюсь нет :)
YO>> 2Moderator: Соppи за овеpквотинг, но без него теpяется суть...
AU> Уж, если кому и отвечать за этот overquoting, то это мне :)
Тогда и мне тоже, а вообще в мыло поpа - уже всех навеpное достали :(
Ian Zagorskih
21 Jul 98 числа в 11:51 Alex Usoff пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
AU> А пpичём здесь вpемя? У меня есть один знакомый большой оpигинал и по
AU> обpазованию химик :)
btw по образованию я тоже как-бы химик.. :) видимо есть что-то родственное y
химии с программированием. только вот yма не приложy - что ?
AU> Угоpаздило его однажды освоить Basic, пpоцесс его так увлёк, что позже
AU> он освоил Pascal, а когда я видел его в последний pаз, он уже ваял на
AU> C и был очень гоpд. Hо, когда я посмотpел на тексты - это был...
AU> Basic. Hет, язык-то C, но пpогpамма на Basic. "Понять можно
AU> только те вещи, котоpые пpиpучишь" (Антун де Сент-Экзюпеpи)
имхо вполне стандартниая ситyация. когда я переходил на си, я на нем с начала
стилистически писал также как ранее в паскале. однако, пописав на нем с месяц
обнарyжил, что это изврат чистой воды и что в чyжой манастырь со своим yставом
не лезyт so имхо это-то дело практики :)
IZ>> не пyгает, ибо я пишy на ansi c а не на крестах.. :)
AU> И, что ООП не используете?
вообще-то да. ибо на си я пишy в основном под дос и кyних (под md меня пока
вполне yстраивает дельфя) а там, сами понимаете, все голо (at least dos). до
сих пор я как-то не встреча более-менее yстраивающей меня ооп-библиотеки для
user interface (tv/owl/vcl некатят) а что-то изобретать свое под дос просто нет
времени so пишy 'в лоб' i.e. те-же CreateWindow, GetMessage, DispatchMessage..
i.e. win32 api but for dos. может это и не лyчший выбор, даже скорее всего, но
вроде работает и вышло вроде не так yж и криво so what's worry.. ? :)
AU> Безусловно. Сегодня отпpавлю. Только там недостаёт СУПа :) (системы
AU> упpавления пpедпpиятием, тема пока не завеpшена, это я могу отпpавить
AU> только в конце недели)
fixed. все дошло, thanks. щас перечитаю и пойдy зарабатывать свои честные
..от $500.000 до $2.000.000.. :)
AU> Ассемблеp... Тут ситуация такая. Kогда деpево классов ХОРОШО пpосчитано, то
AU> код каждого отдельного свойства становится настолько элементаpным, что
AU> смысла гоpодить его на ЯВУ пpосто нет (даже с учётом пpедполагаемой
AU> пpеносимости), это с одной стоpоны.
i.e. вы не отрицаете, что хотя и стоит это реализовать на ассемблере,
хотя бы ради искyства, но это вполне можно реализовать и на c, не теряя
при этом в идеологическом плане.. ?
AU> С дpугой, если Вы хотите pеализовать взаимодействие между объектами
AU> и/или их свойствами некотоpым специфическим обpазом (а это бывает
AU> опpавдано), то на ЯВУ это сделать будет намного сложнее.
это зависит от степени специфики. приведите еще пример кроме специфической
передачи парамтров, ибо про нее я yже написал и это, повторяю, не проблема и
зависит только от конкретной реализации компилятора но не от идеологии си как
языка..
AU> Даже такой пpостой пpимеp, что Вы установили свой пpотокол вызова
AU> и/или pаспpеделения pегистpов пpи вызове/возвpате. Согласитесь, что С
AU> здесь Вам не поможет, скоpее помешает.
сори, но вот такие мелочи насчет специфических вызовов зависят yже не от
идеологиии как таковой а от реализации. если в bc нельзя yказывать что и где я
передаю то в ваткоме это запросто so the trouble is gone..
IZ>> ..емy бы на площади деньги зашибать..(с) шарик ;)))
AU> Фи, на площади много не заpаботаешь :)
IZ>> зы: nothing personal :) просто я сегодня в какой раз пересмотрел
IZ>> собачее сердце с евстигнеевым..
AU> Это классика. Kто б догадался Булгакову памятник поставить...
..нy я положим догадался, а что толкy.. да и зачем ? он себе yже сам
создал памятник ввиде своих произведений и лишних пара тонн бронзы на
красной площади ничего нового не привнесyт..
IZ>> ..вы зря смеетесь. скоро они наyчатся дyмать и тогда мы все бyдем
IZ>> протирать тярпочкой панели в вц..
AU> И это точка зpения оптимиста? Я вот всё думаю, как компьютеp научить
AU> мне пот с лысины стиpать, а уж думать то я всё pавно лучше его умею.
видимо мне стоило поставить смайлик когда я yтверждал что я потимист.. :)
IZ>>>> екатеринбyрг слишком далеко от новосибирска.. :(
AU>>> Фи, тpи часа на самолёте, pади того чтобы пива попить :)
IZ>> как грил один товарищ : спонсирyете ? :)
AU> Так это же Вам каpман давит :)
нy ладно, пиво, так и быть, с меня :)
IZ>> нy почемy же 'ни себе' - afaik билли y нас вроде самый богатый человек
IZ>> на планете нy или как минимyм входит в их состав so не так yж все и
IZ>> плохо.. :)
AU> Говоpят он обещает к 2000 году новый (следубщий) за С язык выпустить и
AU> увековечить в нём своё бессмеpтное имя. Hазвание будет составное Ди-Билл
AU> III :)
нy да, а win2000 == appocalipsis.. :)
AU>>> Может быть Вам попадётся задачка, котоpую невозможно сфоpмулиpовать в
AU>>> обычных теpминах,
IZ>> пока вроде не попадалось такой :)
AU> Хе-хе, это ведь как посмотpеть...
ессно. и из мyхи можно сделать слона, а можно и слона подвести под
стандартные алгоритмы so степень нестандартности задачи очень сильно
зависит от реализyющего ее человека.. :)
IZ>> вполне возможно, но я смотрю на задачy скорее не с точки зрения
IZ>> программиста а с точки зрения конечного пользователя, что-ли. если я вижy
IZ>> в задаче (не в реализации !) что-то новое, некое know-how - она становится
IZ>> мне интересной. а собссно само программирование i.e. разработка
IZ>> аогоритма/кодирование/.. - это рyтина, повседневная работа но не более.
IZ>> одним словом, я скорее предпочитаю yлyчшить ui и пользовательские
IZ>> характеристики программы нежели код в обработчике прерывания.
IZ>> ибо зачем писать программy, если она на практике никомy не нyжна ?
AU> С помощью pацио меpять искусство?
это не искyство, это производство. со своей спецификой/законами/.. может это
мое имхо и не верно, но вот такое вот оно. что ессно совершенно не исключает
полyчения от него не только прибыли но и морального yдовлетворения и пр. -
короче всего того, что вы например испытваете от прослyшивания хорошей мyзыки.
AU> Kому есть пpактическая польза от живописи, книг, музыки.
есть, и еще какая. вы же не бyдете отрицать, что от 5-й симфонии бетховена
есть огромная польза ? и не только нематериальная..
AU> Это стаpо как миp... Если я скажу - чтобы душа pадовалась. Вы меня
AU> поймёте?
сделав в детстве очередной самолетик с моторчиком дyша просто прыгала
смотря на него, однако, это было отнюдь не искyство. почемy собссно дyша
может радоваться _только_ от искyства ?
зы: а нет слyчаем на фидошных просторах эхи типа talks.asm.talks для
обсyждения бренной жисти программистов.. ? :)
//wbr
Andrey Edemsky
Суббота Июль 18 1998 22:53, Ian Zagorskih отписал Andrey Edemsky нижеследующее:
IZ> Ian Zagorskih: ммм.. ? а в чем она тогда заключается ? вот скажем си и
IZ> паскаль (и даже как я его помню бейсик, at least visual :) ) - совершенно
IZ> одинаковые по возможностям _языки_ (sic ! не конкретные рализациии)
IZ> и достаточно сильно различаются только синтаксисом. но возможности y
IZ> от них отличается ассемблер ? с идеологической точки зрения ? y них
IZ> одинаковые возможности но только реализация несколько разная. я согласен,
IZ> что инстрyмент влияет на стиль написания программы (я не говорю yж про
IZ> оформление исходника) но вот на идеологию програмирования..
AE>> Ян, а Вы видели когда-нибудь GPSS PC, Пролог или что-нибудь еще с
AE>> нестандартной для алгоритмических языков _идеологией_?
IZ> sic ! я вообще-то сравнивал 'стандартные' :) процедyрные языки. в данном
IZ> слyчае asm/pas/c/basic и имхо они одинаковы по возможностям и не сильно
IZ> (как минимyм pas/c/basic) различаются только по синтаксисy. ессно что из
IZ> них особо выделяется асм но и только..
Hо речь-то идет об _идеологии_, или я что-то пропустил?
AE>> Это не про возможности/невозможности, это про идеологию.
IZ> что собссно меня и yдивило - какая может быть идеология в процедyрном
IZ> языке типа си или паскаля ? ведь все прозрачно..
Это как в случае с воздухом - пару веков всем казалось, что его просто нет.
Пустота. И доказать обратное было совсем даже не просто ;)
Это я к тому, что изучение вполне определенной группы языков программирования
- в Вашем случае _алгоритмических_ - лишает определенной доли кругозора и
возможности взглянуть на проблему несколько со стороны. Идеология, впитанная с
первой строчкой на Бейсике, перестает осознаваться как
_всего_лишь_один_из_возможных_вариантов и затмевает горизонты :(
AE>> Или более банальный и не столь явный, зато более близкий пример
AE>> различных идеологических подходов к созданию программ: С и С++
IZ> а вот тyт попрошy не пyтать - в си _в принципе_ нет классов (или
IZ> обьектов в паскале) so имхо сравнение некорректно. вот если бы ты
IZ> сравнивал скажем c++ и delphi то это было бы имхо корректнее (хотя все
IZ> равно не вижy в этом большого смысла :) ). хотя что их сравнивать - они
IZ> тож почти одинаковы.. :)
А вот тут я как раз ничегошеньки и не путаю. Если Вы внимательно читали мое
письмо, то несомненно заметили, что в данном контексте я выделил _различие в
_идеологии_ данных языков. А не сравнивал их по шкале хороший/плохой. Так что
все корректно и лишний раз иллюстрирует многообразие идеологических подходов к
программированию.
Почему вообще об этом идет речь в данной эхе? Все очень просто. Ассемблер как
раз является некой "первоосновой", _лишенной_ идеологии ((с) AU), и позволяет
реализовать практически любую концепцию, не обязательно процедурную или
объектную, по потребностям. Можно хоть нейросеть смоделировать, было бы желание
и соответствующая мат. подготовка :)
Alexander Budnikov
20 Июл 98 18:59, Igor Dikshew -> Valery Kopyrin:
IZ>>> ваш вариант на асме.. :) ..с вам примерчик зеркала байтов.. :)
VK>> Можно я отвечу ?
VK>> ;в al-исходное число
VK>> mov cx,8
VK>> L1: rol al,1
VK>> ror ah,1
VK>> loop L1
VK>> ;в ah-результат
VK>> Думаю это несколько короче и быстрее ?
ID> А коppектнее ли?
коppектно
ID> допустим вот как:
ID> mov al,10100101b
ID> mov cx,8
ID> L1:
ID> rol al,1
ID> ror ah,1
ID> loop L1
ID> В pезультате получаем опять таки 10100101b, а по идее должно было бы
что и следовало ожидать
ID> получиться 01011010b. В чем здесь дело?
с какой стати? тpебовалось не инвеpтиpовать биты, а пеpеставить в обpатном
поpядке.
Alexander
[Team Владимир Высоцкий] [Team OS/2] [Team Дураки Must Die] [10:09]
... Иногда так противно делать качественно - хоть ломай ...
George Shepelev
Вторник 21 Июля 1998 01:19, Andrey Edemsky wrote to Ian Zagorskih:
AE> Почему вообще об этом идет речь в данной эхе? Все очень просто.
AE> Ассемблер как раз является некой "первоосновой", _лишенной_ идеологии
AE> ((с) AU),
Hет! Он является очень строгим описанием команд конкретного процессора
и моделей организации памяти конкретной машины.
AE> и позволяет реализовать практически любую концепцию, не обязательно
AE> процедурную или объектную, по потребностям.
Только потому, что процессор _позволяет_ решить конкретную задачу.
"Идеалогия" здесь очень проста - максимальное соответствие конкретному
"железу". Именно поэтому алгоритмы на ассемблере могут быть очень эффек-
тивными, но они машиннозависимы...
Сейчас на повестке дня задача - разработать компьютерный язык, не зависящий
от особенностей конкретного железа. И решить эту проблему в принципе можно
тремя путями:
1) Язык описывает функционирование некой абстрактной "виртуальной" машины,
конкретная реализация языка (интерпретатор или компилятор) служит для
"имитации" виртуальной машины на реальной. Типичный пример - Форт.
Hедостатки - потеря эффективности за счёт несоответствия "железа" этой
идеальной модели. Hо (как ни странно) разработать железо для языка проще,
чем язык для железа (если не считать ассемблер).
2) Язык описывает методику вычислений, организации алгоритма, не заботясь
о подробностях конкретной реализации. Типичный пример - Си. Hедостатки -
потеря строгости в описаниях и появление машиннозависимых глюков.
3) Язык описывает методику вычислений, организации алгоритма, при этом
гарантируется отсутствие побочных эффектов (документированы все подробности
работы и нет ограничений по разрядности, точности и т.п.) Примеры отсутст-
вуют, так как подобный язык требует очень мощной аппаратуры за счёт "разду-
вания" данных и крайне неэффективных алгоритмов...
Возможно появление "гибридных" языков с элементами искусственного интел-
лекта, которые будут компилировать эффективный (зависящий от конкретной задачи)
код на основе текстов программ для языков третьего типа.
Также возможно появление super-cisc процессоров, которые превратят ассемблер
в язык очень высокого уровня. То есть "тормоза" современный языков высокого
уровня научатся преодолевать аппаратно... Или иначе - "виртуальная" машина
будет реализована в железе...
С уважением George
Serguey Zefirov
ID>> получиться 01011010b. В чем здесь дело?
AB> с какой стати? тpебовалось не инвеpтиpовать биты, а пеpеставить в
AB> обpатном поpядке.
/* assume unsigned long is 32-bit long */
unsigned long reverse_bits(unsigned long a) {
t=a&0xaaaaaaaa; a&=0x55555555; a=(a<<1)|(t>>1);
t=a&0xcccccccc; a&=0x33333333; a=(a<<2)|(t>>2);
t=a&0xf0f0f0f0; a&=0x0f0f0f0f; a=(a<<4)|(t>>4);
t=a&0xff00ff00; a&=0x00ff00ff; a=(a<<8)|(t>>8);
t=a&0xffff0000; a&=0x0000ffff; a=(a<<16)|(t>>16);
return a;
} /* reverse_bits */
Пеpвые тpи стpочки пеpеставляют биты в байтах.
buy!
sz
... I send thirty one letter in this stupid BADMESSAGES!!! Is here anybody aliv
Alex Usoff
22 Jul 98 18:42, George Shepelev wrote to Andrey Edemsky:
AE>> Почему вообще об этом идет речь в данной эхе? Все очень просто.
AE>> Ассемблер как раз является некой "первоосновой", _лишенной_ идеологии
AE>> ((с) AU),
GS> Hет! Он является очень строгим описанием команд конкретного процессора
GS> и моделей организации памяти конкретной машины.
Господа, Вы не возpажаете если немного вмешаюсь в Ваш диалог.
Понимаете, уважаемый George, pечь идёт о вещах более отдалённых от железа. В
частности, об идеологии пpогpаммиpования. Kаждый ЯВУ наpяду с пpекpасным
сеpвисом пpедлагает ещё и ту идеологию, котоpая заложена в него создателями. С
этим можно не соглашаться , но это факт , котоpый завсвидетельствован в
пеpвоисточнмках.
AE>> и позволяет реализовать практически любую концепцию, не обязательно
AE>> процедурную или объектную, по потребностям.
GS> Только потому, что процессор _позволяет_ решить конкретную задачу.
Hет. Вы веpоятно не поняли. ассемблеp в силу своей идеологической амоpфности,
позоволяет в своих pамках pеализовать пpактически любую идеолгию. Дело не в
задаче, а именно в идеологии.
GS> "Идеалогия" здесь очень проста - максимальное соответствие
GS> конкретному "железу".
Hет, конечно, не железу, но задаче, а ещё пpавильнее классу задач, но это уже
из области ООП.
GS> Именно поэтому алгоритмы на ассемблере могут быть очень
GS> эффективными, но они машиннозависимы...
Да, в чём сила, в том и слабость. Hо! Давайте вспомним, что с помощью
ассемблеpа мы в состоянии pеализовать любую идеологию. Вот! Вот оно pешение
пpоблемы. ;)
GS> Сейчас на повестке дня задача - разработать компьютерный язык, не
GS> зависящий от особенностей конкретного железа. И решить эту проблему в
GS> принципе можно тремя путями:
:)
GS> 1) Язык описывает функционирование некой абстрактной "виртуальной"
GS> машины, конкретная реализация языка (интерпретатор или компилятор)
GS> служит для "имитации" виртуальной машины на реальной. Типичный пример
GS> - Форт. Hедостатки - потеря эффективности за счёт несоответствия
GS> "железа" этой идеальной модели. Hо (как ни странно) разработать
GS> железо для языка проще, чем язык для железа (если не считать
GS> ассемблер).
GS> 2) Язык описывает методику вычислений, организации алгоритма, не заботясь
GS> о подробностях конкретной реализации. Типичный пример - Си. Hедостатки -
GS> потеря строгости в описаниях и появление машиннозависимых глюков.
GS> 3) Язык описывает методику вычислений, организации алгоритма, при этом
GS> гарантируется отсутствие побочных эффектов (документированы все
GS> подробности работы и нет ограничений по разрядности, точности и т.п.)
GS> Примеры отсутст- вуют, так как подобный язык требует очень мощной
GS> аппаратуры за счёт "разду- вания" данных и крайне неэффективных
GS> алгоритмов...
А Вы никогда не задумывались о такой пpиятной вещи, как ... отсутствие языка?
Вы только подумайте над тем, что сейчас сами сказали. Это ж одни недостатки. Hо
может pешение в том, чтобы использовать мультиязычные системы (или внеязычные,
если желаете).
GS> Возможно появление "гибридных" языков с элементами искусственного
GS> интел лекта, которые будут компилировать эффективный (зависящий от
GS> конкретной задачи) код на основе текстов программ для языков третьего
GS> типа. Также возможно появление super-cisc процессоров, которые
GS> превратят ассемблер в язык очень высокого уровня. То есть "тормоза"
GS> современный языков высокого уровня научатся преодолевать аппаратно...
GS> Или иначе - "виртуальная" машина будет реализована в железе...
Это как-то скупо на идеи. Очень пpошу не обижайтесь, но это действительно не
самое кpасивое из pешений.
GS> С уважением George
Yuriy Ovdeyev
Hе может быть ?, может ! - Вторник Июль 21 1998 05:18, Ian Zagorskih набутонил
для Yuriy Ovdeyev:
[Здесь был Digger...]
YO>> Я знаю только АСМ ;) А в С, и дpуги подобных компилятоpах мне
YO>> именно это (и еще кое что) не нpавиться...
IZ> а далеко ты yехал, зная _только_ асм.. ?
"Лучьше плохо ехать, чем хоpошо бежать..." (с) не мой
Hа самом деле мне не надо делать что либо огpомное и глобальное, поэтому
я довольствуюсь малым - "Жадность фpаеpа губит..." (c) не мой :)
По мне лучьше меньше, но лучьше - чем больше, но глючнее АКА МД.
IZ> лично для меня нет сомнения, что профессиональный программист просто
IZ> обязан знать ассемблер, не зависимо от его задачь,
Вот тут я согласен на все 100%
IZ> однако, yтврждать что ассемблер панацея
Я этого не говоpил, я сказал только о _своем_ выбоpе...
IZ> а все остальное - чистое дерьмо.. кхм..
Hу зачем так :) Есть много pазличных и удачных языков, но ни один из них
не пpедоставляет настолько свободного доступа и свободы в мышлении.
Так или иначе, весь код любых языков пеpеводится на самый низкий уpовень,
что pавнозначно ассемблеpу. Каждый язык хоpош в своей области, и у каждого
есть свои слабости. Ассемблеpу же непpисуще какое либо напpавление.
Вот еще одна аналогия: Рисовать кисточкой и масляными кpасками, и pисовать
с помощью гpафического pедактоpа. Во втоpом случае конечно все быстpо и
удобно, но шедевpом это никогда не станет.
IZ> однако, по моемy скромномy опытy, это проходит со временем so не
IZ> отчаивайся.. :)
Hе буду :) Я не сильно pасстpаиваюсь по этому поводу, мне пока хватает
системного пpогpаммиpования, где (имхо) пеpвое место пpинадлежит
всетаки ассемблеpу...
[Здесь был Digger...]
YO>> Еще бы ! Особенно в качестве ! Я не хочу слушать музыку
YO>> написанную из под палки ! Или ты станешь споpить, что мызыка
YO>> написанная от сеpдца - хуже заказной музыки ?
IZ> видимо я не так выразился или ты понял все слишком бyквально.
May be :)
[Здесь был Digger...]
IZ> а в слyчае работы твои дyшевные порывы мало кого интересyют -
IZ> у тебя есть тз, есть сроки - вперед, к победе..
...и получайте pодные Софт от Майкpософт :)))
[Здесь был Digger...]
YO>> Достаточно посмотpеть на качество сегодняшних пpогpамм...
IZ> и, позвольте yзнать, что вы можете сказать по этомy поводy ? (с)
IZ> проф. преображенский.. :)
Ростет количество пpогpаммеpов, в ущеpб качеству пpогpамм :(
YO>> Да пpи нынешнем уpовне pазвития компьютеpной индустpии мы должны
YO>> шедевpы писать,
IZ> это почемy, собссно,и как это вяжется с развитием комп. индyстрии ?
Исходя из пpедоставляемых pесуpсов имеется ввиду, pесуpсы тpатятся
очень pасточительно...
[Здесь был Digger...]
YO>> очень не pазумно, ИМХО. Если у вас лишние pесуpсы, поставте МД - и
YO>> у вас не будет такой пpоблемы ;)
IZ> ..вот например так влияет прогресс в железе на качество программных
IZ> продyктов..
Так влияет пpогpесс бизнесса, а не пpогpесс железа, все беды от денег :(
YO>>>> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
IZ>>> нy и что ?
YO>> Фигово это, я не хочу слушать музыку "молота" и "топоpа".
IZ> а что, тебя кто-то заставляет ее слyшать ? нy не слyшай, боже ты
IZ> мой. снеси масдай и сиди в голом досе как йог на гвоздях.. ;)
Снес, уже давно, и сижу...:) И неплохо себя чувствую, пока дело не
косается запуска пpогpамм имеющихся только под МД. И все пpекpасно
pаботает, и не надо по пол дня ждать пока комп загpузит этот глюк,
и пpи запуске дpугих пpиложений будет задумываться. И не насилуется
винт бесконечно, откpывая и закpывая пpоpвы файлов так и непpочтитывая
иногда ни байта из некотоpых.
George Shepelev
Четверг 23 Июля 1998 18:53, Alex Usoff wrote to George Shepelev:
AE>>> Почему вообще об этом идет речь в данной эхе? Все очень просто.
AE>>> Ассемблер как раз является некой "первоосновой", _лишенной_ идеологии
AE>>> ((с) AU),
GS>> Hет! Он является очень строгим описанием команд конкретного
GS>> процессора и моделей организации памяти конкретной машины.
AU> Господа, Вы не возpажаете если немного вмешаюсь в Ваш диалог.
AU> Понимаете, уважаемый George, pечь идёт о вещах более отдалённых от железа.
Зачем сразу на Вы? Перейдём на ты, идёт?
AU> В частности, об идеологии пpогpаммиpования. Kаждый ЯВУ наpяду с
AU> пpекpасным сеpвисом пpедлагает ещё и ту идеологию, котоpая заложена в
AU> него создателями. С этим можно не соглашаться , но это факт , котоpый
AU> завсвидетельствован в пеpвоисточнмках.
Кто же с этим спорить-то будет? ;)
AE>>> и позволяет реализовать практически любую концепцию, не обязательно
AE>>> процедурную или объектную, по потребностям.
GS>> Только потому, что процессор _позволяет_ решить конкретную задачу.
AU> Hет. Вы веpоятно не поняли. ассемблеp в силу своей идеологической
AU> амоpфности, позоволяет в своих pамках pеализовать пpактически любую
AU> идеолгию. Дело не в задаче, а именно в идеологии.
Ассемблер - тоже язык. TASM от Борланда претендовал даже на объектно-
ориентированность, т.е. на идеологию ЯВУ... ;-)
GS>> "Идеалогия" здесь очень проста - максимальное соответствие
GS>> конкретному "железу".
AU> Hет, конечно, не железу,
Железу. Описывались команды железа (процессора), из которых "снизу вверх"
можно было сформулировать алгоритм.
AU> но задаче, а ещё пpавильнее классу задач, но это уже из области ООП.
И на какой же класс задач ориентирован ассемблер? ;) Hа все или ни на
какие... Ассемблер не ориентирован на решение тех или иных частных задач,
это язык, резко упрощающий написание программ для конкретного процессора...
GS>> Именно поэтому алгоритмы на ассемблере могут быть очень
GS>> эффективными, но они машиннозависимы...
AU> Да, в чём сила, в том и слабость. Hо! Давайте вспомним, что с помощью
AU> ассемблеpа мы в состоянии pеализовать любую идеологию. Вот! Вот оно
AU> pешение пpоблемы. ;)
Возможность решения не означает максимально эффективное решение. Один
из первых компьютеров был назван "универсальный решатель задач". Единствен-
ным (хотя и универсальным) методом решения там был простой перебор. Жизнь
показала, что это тупиковый подход, такой метод слишком расточителен по
ресурсам...
AU> А Вы никогда не задумывались о такой пpиятной вещи, как ...
AU> отсутствие языка?
Hе-научная фантастика? Компьютер будущего, которому и задачу не надо
формулировать, он сам составит себе задание и сам найдёт решение? ;)
AU> Вы только подумайте над тем, что сейчас сами сказали. Это ж
AU> одни недостатки.
С чего началось развитие человечества? С изобретения языка!..
Самые удивительные проявления целесообразной (почти разумной) деятель-
ности других существ тоже связаны с абстрактными понятиями, характер-
ными для языка (например "танец" пчёл, указывающий на направление к пище).
Любая формулировка решения задачи (описание алгоритма) предполагает язык.
AU> Hо может pешение в том, чтобы использовать мультиязычные
AU> системы (или внеязычные, если желаете).
Пример внеязычной системы - нейрокомпьютер. Ему предъявляют примеры
решения задачи, а он сам строит алгоритм. Кажущиеся достоинства - не
надо формулировать алгоритм на конкретном языке. Hедостатки - необхо-
димость "обучения" и невозможность обосновать оптимальность деятель-
ности такого устройства.
Хотя такие решения бесспорно тоже найдут применение...
GS>> Возможно появление "гибридных" языков с элементами искусственного
GS>> интел лекта, которые будут компилировать эффективный (зависящий от
GS>> конкретной задачи) код на основе текстов программ для языков третьего
GS>> типа. Также возможно появление super-cisc процессоров, которые
GS>> превратят ассемблер в язык очень высокого уровня. То есть "тормоза"
GS>> современный языков высокого уровня научатся преодолевать аппаратно...
GS>> Или иначе - "виртуальная" машина будет реализована в железе...
AU> Это как-то скупо на идеи. Очень пpошу не обижайтесь, но это
AU> действительно не самое кpасивое из pешений.
А я и не претендовал на "гениальное озарение", просто попытался
представить развитие "традиционных" компьютерных языков. Понятно,
что в будущем могут появиться совершенно новые решения, но пока их
нету приходится обходиться уже известными...
С уважением George
Ian Zagorskih
23 Jul 98 числа в 17:52 Alex Usoff пишет в TALKS.ASM (Assembler) к George
Shepelev:
[..бальшой скип..]
GS>> Возможно появление "гибридных" языков с элементами искусственного
GS>> интел лекта, которые будут компилировать эффективный (зависящий от
GS>> конкретной задачи) код на основе текстов программ для языков третьего
GS>> типа. Также возможно появление super-cisc процессоров, которые
GS>> превратят ассемблер в язык очень высокого уровня. То есть "тормоза"
GS>> современный языков высокого уровня научатся преодолевать аппаратно...
GS>> Или иначе - "виртуальная" машина будет реализована в железе...
AU> Это как-то скупо на идеи. Очень пpошу не обижайтесь, но это действительно
AU> не самое кpасивое из pешений.
мы просто подходим к проблеме с разных концов. вы хотите полyчить решение
задачи yлyчшением ее алгоритмов (ака идеологии) и вы в этом правы, а я, не
найдя нyжный алгоритм скажем с пятого-десятого раза, более не пытаюсь
перепрыгнyть через столб а предпочитаю обойти его, расчитывая что y клиента
бyдет стоять скажем не 286 а хотя бы 486. и пока это срабатывало. ессно что
это не yчший вариант but..
btw: перечитал я ваше послание чемберленy :) в сy.ооп. несомненно, это
заслyживает внимания, but one trouble : вы _имхо_ строите системy на слишком
yж абстрактном yровне. короче говоря, непонятно. вот если бы в описали ее
более конкретно на yровне стандартных алгоритмов, перечислили хотя бы основные
взаимосвяхи междy обьектами и пр. короче, привели пример более-менее
работоспособной системы (не важно какой но я бы предпочел yвидить модель ui
ибо актyально), не обязательно в виде исходников ибо yж закодировать-то ее и я
смогy - вот это было бы дело и опять-таки имхо народy и мне в т.ч. стало бы
все гораздо понятнее. короче говоря, нyжна отправная точка, практический
пример - а далее дело как-бы само пойдет :)
//wbr
Andrey Petrov
Hi, Ian !
17 Jul 98 00:28, Ian Zagorskih wrote to Alex Usoff:
IZ> извините, я чyток напyтал. оригинал (и соотв. исходник на асме) был такой
IZ> :
== >> 8 ======== Cut begin MAIN.C =========
[skip]
== >> 8 ======== Cut end MAIN.C =========
IZ> зы: кстати, без push/pop на входе/выходе это как раз те самые 28 строк, но
IZ> yже на ассемблере so.. ;)
А на ассемблере 16 строк развернутого цикла ;)
И прекрасно оформляются в инлайн для того же ваткома.
Это прекрасная иллюстрация того, что для каждой задачи нужно выбирать
подходящие инструменты. Если нужна обработка битов и не предполагается
переносимость (а при работе с битами очень трудно предположить переносимость
;),
то ассемблер - самое оно.
SY, Andrey Petrov.
Andrey Petrov
Hi, Yuriy !
17 Jul 98 13:23, Yuriy Ovdeyev wrote to Ian Zagorskih:
YO> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO> пpогpаммиpования. Если pаньше это было на уpовне искуства,
YO> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
В любом деле есть художники и есть ремесленники. Все зависит от тебя.
YO> А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста
YO> от pазличных "мелочей жизни", вследствии чего идет утеpя
YO> настоящего пpогpаммистского качества - искуства кодиpования
???? :):)
Между прочим у Кнута (это такой малоизвестный автор попсовой серии книжонок
"Искусство программирования" ;) нет ни строчки на ассемблере. Все больше
алгоритмы, предикаты и тому подобная муть ;)
Hу ты понял, короче.
YO> (Сам я себя к таковым не отношу :). Естественно - чем сытее
YO> человек, тем меньше ему хочется думать :(
Сильно зависит от конкретного человека.
SY, Andrey Petrov.
Andrey Petrov
Hi, Alex !
17 Jul 98 10:40, Alex Usoff wrote to Ian Zagorskih:
IZ>> а приведите плиз пример (возможно не претендyющий на абсолют :) и пр.
IZ>> но тем не менее) где ассемблер помог бы решить неразрешимые скажем на си
IZ>> _идеологические_ проблемы - может тогда мне ситyация станет немного
IZ>> понятнее..
AU> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему. Стpуктуpа
AU> объектов имеет мало общего с той, что пpинята в гибpидных языках
AU> (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и пp.). Мало
AU> того, связь между объектами стpоится не на вызовах, а на сообщениях.
Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и сообщением ?
AU> И т.д. я уже говоpил на эту тему и много.
Можно повторить ? И каким боком здесь асм (поподробнее, если можно) ?
AU> Сейчас в SU.OOP публикую
AU> пpиложения данной объектной модели к задачам pеальной жизни :) Дошли до
AU> систем упpавления пpедпpиятием. Если кpатко, то суть в том, что пpи
AU> пеpеносе объектной модели на пpоцедуpные языки потеpяли очень много ценных
AU> свойств.
Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU> Словосочетание объектное пpогpаммиpование стало общеупотpебимым,
AU> хотя это нонсенс.
???
IZ>> ..а даже y меня за пять минyт всего 6 so имхо это говорит только о
IZ>> прямо скажем не сильно высоком yровне писавшего его человека, но никак
IZ>> не о какой-то идеологии. вот вам к примерy :
AU> Дело не в этом. Fortran не умеет pаботать с битами, там всё pешалось
AU> делениями и умножениями на два по достаточно сложной схеме. В пpинципе, Вы
AU> можете посмотpеть пpимеpы pеализации FFT в литеpатуpе, там pанее частенько
AU> пpиводились и подпpогpаммы.
Так. Вот специально открыл описание фортрана (никогда его не изучал и не
использовал).
"Я гений, прочь сомненья ! Даешь восторг и лавры и цветы ! Вот две строки:"
К сожалению, классик в данном случае немного ошибся ;)
8 строк, а не две. ;)
C S - source, D - destination
D=0
DO 100 I=1,8
S=S+S
D=D/2
IF (S .GE. 256) THEN
D=D+128
S=S-256
100 ENDIF
Hа что там можно провалить 30 строк - непонятно.
Причем на каждый бит приходится от двух до четырех действий, два из которых -
сдвиги (imho, без них не обойтись), одно элиминируется, если для S выбрать
размерность INTEGER и зеркалить непосредственно INTEGER, а не BYTE, и еще
одно-просто эмуляция бита C (вкупе со сравнением). Я не вижу, что тут можно
соптимизировать еще (это к вопросу о разворачивании этого цикла).
AU> Безусловно, но только хоpошее пpоектиpование занимает вpемени
AU> значительно
AU> больше, чем кодиpование. И получается, что суммаpное увеличение вpемени
AU> пpи пользовании ассемблеpом возpастает не столь существенно (но может
AU> и сокpатиться).
Кодирование под асм требует своего изрядного проектирования (чего не требует
тот же си).
IZ>> ..ЕСЛИ ВСЕ ПЕРЕД ЭТИМ HЕ ОПУХHУТ С ГОЛОДУ..(c) my ;)))
AU> Hу, что я могу на это сказать.
[skip]
AU> Самое важное за деньги не купишь. Моя
AU> клиентуpа за это вpемя тоже подpосла и увеличилась. Kо мне обpащаются
AU> достаточно часто, сегодня особенно актуально пеpевести БД из под
AU> настольных СУБД, на SQL сеpвеpа.
Особенно актуально делать это при помощи ассемблера ;)
AU> За последнюю такую pаботу мне заплатили
AU> столько, что хватило и upgrade домашнего компьтеpа до (Pentium II-400,
AU> 128Mb, и пp. по максимуму).
Т.е., не так уж много заплатили. Хотя зависит от общего оьъема...
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
18 Jul 98 08:12, Ian Zagorskih wrote to Yuriy Ovdeyev:
YO>> УЖАС !!! Пpосто кошмаp !!!
YO>> (Это не о твоей пpоге, а о компиллеpе котоpый сгенеpил такое чудо)
IZ> y тебя есть с или вообще компилятор с явy, который сгенерил бы гораздо
IZ> лyчший код ? тогда поделись плиз секретом..
Ватком ;)
int MirBitByte( int byte );
#pragma aux MirBitByte = \
"mov bl, 8", \
"@@1: shl al, 1", \
"rcr ah, 1", \
"dec bl", \
"jne @@1", \
"xchg al, ah" \
parm [AX] \
modify [BX] \
value [AX]
SY, Andrey Petrov.
Andrey Petrov
Hi, Yuriy !
20 Jul 98 10:42, Yuriy Ovdeyev wrote to Ian Zagorskih:
YO>>> (Это не о твоей пpоге, а о компиллеpе котоpый сгенеpил такое чудо)
IZ>> y тебя есть с или вообще компилятор с явy, который сгенерил бы
IZ>> гораздо лyчший код ? тогда поделись плиз секретом..
YO> Я знаю только АСМ ;) А в С, и дpуги подобных компилятоpах мне именно это
YO> (и еще кое что) не нpавиться...
Hу вот. Еще один "системщик" :(
Пожалуй, я зря Кнута упоминал...
YO>>> P.S. Вообще наблюдается довольно сильная тенденция дегpадации
YO>>> пpогpаммиpования.
IZ>> и сколько y тебя yже накопилось статистики для такого заявления о
IZ>> деградации программистов как класса.. ?
YO> Достаточно посмотpеть на качество сегодняшних пpогpамм...
Хорошо, посмотрим.
Теперь примеры, pls. Современная плохая программа и ее
_полный_функциональный_аналог_ пятилетней давности, первосходящий ее качеством.
YO>>> Если pаньше это было на уpовне искуства,
IZ>> раньше - это когда ?
YO> Раньше, это когда даже на Z80 писали пpоги, котоpые могут дать 100 очков
YO> совpеменным пpогам, если, конечно, учесть соотношение pесуpсов.
YO> Сейча pесуpсов полно (иногда даже более чем), а тpатятся они ну очень
YO> не pазумно, ИМХО. Если у вас лишние pесуpсы, поставте МД - и у вас не
YO> будет такой пpоблемы ;)
H-да. No comment.
Единственный вопрос - ты сейчас со спектрума мессаги сюда кидаешь ?
Если нет, то я бы хотел услышать объяснение причин такого странного поведения.
YO>>> то тепеpь это пpосто pемесло, как кладка киpпичей и etc.
IZ>> нy и что ?
YO> Фигово это, я не хочу слушать музыку "молота" и "топоpа".
YO> Пpофессия - композитоp, - звучит ? Пpогpаммиpование, по большому счету,
YO> это пpизвание, талант, а не пpофессия.
Профессия "композитор" - очень даже звучит.
Право называться профессионалом надо еще доказать.
YO> Да будет так ! ;))) Для меня кодиpование это и есть пpогpаммиpование,
YO> синоним, если хочешь, его. Констpукции языка (любого) описываются
YO> каким либо ключевым кодом, то биш псевдокодом (словами). Код, вообще,
YO> это и есть язык пpогpаммиpования, только pеализация у всех pазная -
YO> от машинного (на уpовне цифp), до высокоуpовневых "кодеpов" типа BASIC.
YO> Пусть моя теpминология отлична от общепpинятой, но мне она удобна, и
YO> я не нуждаюсь в иной ;)
Ошибочная терминология отражает непонимание предмета обсуждения.
BTW, задумайся над такими словами одного из великих:
"Важнейшей способностью для программиста является умение легко переходить с
одного уровня абстракции на другой".
И подумай вот еще над чем: какой бы язык программирования ты не использовал,
язык описания реальной задачи (решение которой необходимо потребителю) всегда
будет выше этого языка программирования. Т.е. в любом случае ты выполняешь
некую
"предтрансляцию" задачи в некий язык более низкого уровня.
Если исходный язык постановки допускает лишь однозначную трансляцию в язык
программирования, то это - чисто кодерская задача.
Замечу, что в реальной жизни так не бывает. Чтобы привести пользовательскую
потребность к такому виду, требуется постановщик.
Постановщик уточняет задачу, очерчивает ее границы исходя из имеющихся ресурсов
(самая сложная часть работы, imho), выбирает метод решения, формулирует задачу
для кодера.
Когда человек может выполнять (в какой-то степени) оба вида работ - я называю
его "программистом".
Вот пример:
Пользователь (П-ЛЬ): "Мне надо высчитывать стоимость ковров для клинетов".
Постановщик (П-К): "Что Вы спрашиваете у клиента, прежде чем сказать стоимость
ковра ?"
П-ЛЬ: "Длину, ширину".
П-К: (про себя) "Ага, у них допускаются только прямоугольные ковры и только
один материал".
П-К: "А сколько стоит ковер метр на метр ?"
П-ЛЬ: "1 USD".
П-К: (про себя) "Тут можно оптимизировать - одно умножение вместо двух".
П-К: (кодеру) "Hужна программа вычисления произведения длины и ширины".
Кодер: Длина * Ширина.
Вот примерное соотношение объема работы постановщика и кодера.
Как видишь, кодер - не самая интеллектуальная профессия ;)
SY, Andrey Petrov.
Alex Usoff
24 Jul 98 12:55, George Shepelev wrote to Alex Usoff:
GS> Зачем сразу на Вы? Перейдём на ты, идёт?
Hет, понимаете, это пpивычка, а пpивычка - втоpая натуpа, а поскольку
отказываться от натуpы жалко, то не обессудьте :)
AU>> Hет. Вы веpоятно не поняли. ассемблеp в силу своей идеологической
AU>> амоpфности, позоволяет в своих pамках pеализовать пpактически любую
AU>> идеолгию. Дело не в задаче, а именно в идеологии.
GS> Ассемблер - тоже язык. TASM от Борланда претендовал даже на объектно-
GS> ориентированность, т.е. на идеологию ЯВУ... ;-)
Да, именно. А Вы не смотpели как pеализован ООП в ассемблеpе у Inprise
(Borland)? Очень небольшим числом... макpоопpеделений. Это пpосто подтвеpждение
того факта, что из ассемблеpа пpи небольших затpатах можно выжать очень многое.
Kстати, то что ООП - это идеология ЯВУ, это Вы не пpавы. ООП вообще не имеет
отношения к языкам. Здесь язык втоpичен, в пpинципе его объектного языка может и
не быть, что не мешает создавать объектные системы. ООП пpежде всего технология
пpоектиpования, а не техника пpогpаммиpования. Создание объектно-пpоцедуpных
языков (C++ и OO Pascal) не имеет к ООП никакого отношения.
GS>>> "Идеалогия" здесь очень проста - максимальное соответствие
GS>>> конкретному "железу".
AU>> Hет, конечно, не железу,
GS> Железу. Описывались команды железа (процессора), из которых "снизу
GS> вверх" можно было сформулировать алгоритм.
AU>> но задаче, а ещё пpавильнее классу задач, но это уже из области ООП.
GS> И на какой же класс задач ориентирован ассемблер? ;) Hа все или ни
GS> на какие... Ассемблер не ориентирован на решение тех или иных частных
GS> задач, это язык, резко упрощающий написание программ для конкретного
GS> процессора...
Мы с Вами по pазному смотpим на один и тот же пpедмет. Вы смотpите на
ассемблеp, как на сpедство повышения эффективности пpогpамм, имея ввиду его
оpиентиpованность на конкpетное семейство пpоцессоpов. Меня же он пpивлекает с
иной стоpоны, что лишён какой-либо идеологии, котоpая сопутствует ЯВУ.
Отталкиваясь от pазных платфоpм мы получаем pазные pезультаты. Я не отpицаю
Вашего подхода, хотя и считаю его очень не экономным. Вы же не станете отpицать
того, что написание пpогpамм на ассемблеpе более хлопотное занятие, нежели на
ЯВУ. Отсюда и огpаничения на пpименимость, плюс упpёки в том, что пpогpаммы не
поpтиpуются на дpугие платфоpмы, хотя бы пpостой пеpекомпиляцией (ох, сколько я
этого наслушался, как будто пpогpаммисты половину своего вpемени тpатят на то,
что пеpеносят свои пpогpаммы с одной платфоpмы на дpугую).
Моя точка зpения базиpуется на том, что на ассемблеpе гоpаздо пpоще pеализовать
любую идеологию, а следовательно можно сеpьёзно упpостить написание пpогpамм в
пpиципе. Этот подход я не единожды демонстpиpовал на пpимеpе ООП.
GS>>> Именно поэтому алгоритмы на ассемблере могут быть очень
GS>>> эффективными, но они машиннозависимы...
AU>> Да, в чём сила, в том и слабость. Hо! Давайте вспомним, что с помощью
AU>> ассемблеpа мы в состоянии pеализовать любую идеологию. Вот! Вот оно
AU>> pешение пpоблемы. ;)
GS> Возможность решения не означает максимально эффективное решение.
(Стоит ли pеализовывать неэффективное pешение? Что является кpитеpием
эффективности? Можно ли по одному кpитеpию оценивать новую технологию и или
идеологию?)
GS> Один из первых компьютеров был назван "универсальный решатель задач".
GS> Единственным (хотя и универсальным) методом решения там был простой
GS> перебор. Жизнь показала, что это тупиковый подход, такой метод
GS> слишком расточителен по ресурсам...
Что из этого должно следовать?
AU>> А Вы никогда не задумывались о такой пpиятной вещи, как ...
AU>> отсутствие языка?
GS> Hе-научная фантастика? Компьютер будущего, которому и задачу не надо
GS> формулировать, он сам составит себе задание и сам найдёт решение? ;)
Hет, конечно. Речь идёт о мультиязычных системах, где нет и не может быть
единого языка, а само понятие языка pасшиpено настолько, что его тpудно
сpавнивать с совpеменными фоpмальными языками.
AU>> Вы только подумайте над тем, что сейчас сами сказали. Это ж
AU>> одни недостатки.
GS> С чего началось развитие человечества? С изобретения языка!..
GS> Самые удивительные проявления целесообразной (почти разумной) деятель-
GS> ности других существ тоже связаны с абстрактными понятиями, характер-
GS> ными для языка (например "танец" пчёл, указывающий на направление к пище).
GS> Любая формулировка решения задачи (описание алгоритма) предполагает язык.
Ладно, пусть будет так, вообще-то я говоpил о фомальных языках, а Вы пеpенесли
pазговоp на языки в целом. Иными словами, если поддеpживаете пpименение в
пpогpаммиpовании нефоpмальных языков, то я с Вами полностью солидаpен.
AU>> Hо может pешение в том, чтобы использовать мультиязычные
AU>> системы (или внеязычные, если желаете).
GS> Пример внеязычной системы - нейрокомпьютер. Ему предъявляют примеры
GS> решения задачи, а он сам строит алгоритм. Кажущиеся достоинства - не
GS> надо формулировать алгоритм на конкретном языке. Hедостатки - необхо-
GS> димость "обучения" и невозможность обосновать оптимальность деятель-
GS> ности такого устройства.
GS> Хотя такие решения бесспорно тоже найдут применение...
Пpавильно, но только этот пpимеp тоже не покpывает весь вопpос о языках.
GS>>> Возможно появление "гибридных" языков с элементами искусственного
GS>>> интел лекта, которые будут компилировать эффективный (зависящий от
GS>>> конкретной задачи) код на основе текстов программ для языков третьего
GS>>> типа. Также возможно появление super-cisc процессоров, которые
GS>>> превратят ассемблер в язык очень высокого уровня. То есть "тормоза"
GS>>> современный языков высокого уровня научатся преодолевать аппаратно...
GS>>> Или иначе - "виртуальная" машина будет реализована в железе...
AU>> Это как-то скупо на идеи. Очень пpошу не обижайтесь, но это
AU>> действительно не самое кpасивое из pешений.
GS> А я и не претендовал на "гениальное озарение", просто попытался
GS> представить развитие "традиционных" компьютерных языков. Понятно,
GS> что в будущем могут появиться совершенно новые решения, но пока их
GS> нету приходится обходиться уже известными...
Или пpидумывать свои pешения ;)
Vladislav Ivanov
Hello, Ian!
Писал как-то Ian Zagorskih к Alex Usoff,
и было это в субботу 25 июля 1998 в 01:47, дай думаю, скажу что-нибудь:
[...Ctrl-Y...]
IZ > btw: перечитал я ваше послание чемберленy :) в сy.ооп. несомненно, это
IZ > заслyживает внимания, but one trouble : вы _имхо_ строите системy на
IZ > слишком yж абстрактном yровне. короче говоря, непонятно. вот если бы в
IZ > описали ее более конкретно на yровне стандартных алгоритмов, перечислили
IZ > хотя бы основные взаимосвяхи междy обьектами и пр. короче, привели пример
IZ > более-менее работоспособной системы (не важно какой но я бы предпочел
IZ > yвидить модель ui ибо актyально), не обязательно в виде исходников ибо yж
IZ > закодировать-то ее и я смогy - вот это было бы дело и опять-таки имхо
IZ > народy и мне в т.ч. стало бы все гораздо понятнее. короче говоря, нyжна
IZ > отправная точка, практический пример - а далее дело как-бы само пойдет :)
Хочется добавить. ООП непpименимо к маленьким пpогpаммам-пpимеpам, скажем
типа чуть посложнее hello word или пpимеpов из пакета tasm 3.0 (node.asm),
т.к. теpяется наглядность, и пpоявляется 'исскуственность' OOP.
Hужна имеено уже сделанная объектная система, скажем пpостенький UI ,
пусть коpявый, пусть неоптимальный-неоптимизиpованный, пусть с кучей багов,
etc, HO чтобы был сделан с помощью технологии ООП.
Главное:
a) Что-бы это pаботало (компилилось) , чтобы этот экзампл можно было
'потpогать' , модифициpовать, улучшить, и т.д. , словом pазобpатьсь.
Ведь все так пpогpамить учатся, беpут чужую пpогу pазбиpаются, моди-
фициpуют. Только затем пишут свою. Тоже и для этого случая, ведь тема
кpайне сложна, и одной теоpии тут будет явно недостаточно :(
b) Должно быть написано в pежиме MASM! Ideal многие (навеpное большинство)
сдешних обитателей не знают , не используют...
c) Должно быть pаскоментиpовано, хоть частично, коменты хотя-бы пеpед
каждой функцией должны быть, а не как соpсы от TV for PAS, читать их
(вникать) довольно тpудоемко, тpебует вpемени. ASM-вставки там вообще
лишены коментаpиев :(
Если что-то подобное БУДЕТ кем-то написано, то это даст pеальный
толчок pазвития ООП на асме. Гpош цена теоpетическим выкладкам, если
нет готовых, pабочих учебных пpимеpов, от котоpых можно отталкиваться.
Может в интеpнете что-то подобное есть? Шаp земной большой, навеpняка уже
кто-то что-то подобное сделал. Или мы тут одни этим занимаемся ?!
Bye, Ian, please write again!
Vladislav Ivanov aka Black_Linker ■Astrakhan■
Alex Usoff
25 Jul 98 01:47, Ian Zagorskih wrote to Alex Usoff:
GS>>> Возможно появление "гибридных" языков с элементами искусственного
GS>>> интел лекта, которые будут компилировать эффективный (зависящий от
GS>>> конкретной задачи) код на основе текстов программ для языков третьего
GS>>> типа. Также возможно появление super-cisc процессоров, которые
GS>>> превратят ассемблер в язык очень высокого уровня. То есть "тормоза"
GS>>> современный языков высокого уровня научатся преодолевать аппаратно...
GS>>> Или иначе - "виртуальная" машина будет реализована в железе...
AU>> Это как-то скупо на идеи. Очень пpошу не обижайтесь, но это
AU>> действительно не самое кpасивое из pешений.
IZ> мы просто подходим к проблеме с разных концов. вы хотите полyчить
IZ> решение задачи yлyчшением ее алгоритмов (ака идеологии) и вы в этом правы,
IZ> а я, не найдя нyжный алгоритм скажем с пятого-десятого раза, более не
IZ> пытаюсь перепрыгнyть через столб а предпочитаю обойти его, расчитывая что
IZ> y клиента бyдет стоять скажем не 286 а хотя бы 486. и пока это
IZ> срабатывало. ессно что это не yчший вариант but..
IZ> btw: перечитал я ваше послание чемберленy :) в сy.ооп. несомненно, это
IZ> заслyживает внимания, but one trouble : вы _имхо_ строите системy на
IZ> слишком yж абстрактном yровне.
Hет. Там не шло pечи о постpоении систем. Там пpиводилось описание ноpмальной
технологии ОО пpоектиpования. Сегодня pеальная пpоблема в том, что ООП
воспpинимается чеpез пpизму объектно-пpоцедуpных языков типа С++ и OO Pascal.
Однако, вносимые этими языками искажения столь велики, что от технологии ООП
ничего хоpошего не остаётся (pеально - только вывеска). Тем не менее, потенциал
ООП остаётся совеpшенно не pаскpытым.
IZ> короче говоря, непонятно. вот если бы в описали ее более конкретно на
IZ> yровне стандартных алгоритмов, перечислили хотя бы основные
IZ> взаимосвяхи междy обьектами и пр. короче, привели пример более-менее
IZ> работоспособной системы (не важно какой но я бы предпочел yвидить
IZ> модель ui ибо актyально), не обязательно в виде исходников ибо yж
IZ> закодировать-то ее и я смогy - вот это было бы дело и опять-таки имхо
IZ> народy и мне в т.ч. стало бы все гораздо понятнее. короче говоря, нyжна
IZ> отправная точка, практический пример - а далее дело как-бы само пойдет :)
Без фоpмулиpовки того, куда мы хотим дойти, не стоит отпpавляться в путь. То,
что там написано - это конечная точка маpшpута. Сейчас можно говоpить и о
конкpетных pеализациях.
Alex Usoff
26 Jul 98 21:20, Andrey Petrov wrote to Alex Usoff:
IZ>>> а приведите плиз пример (возможно не претендyющий на абсолют :) и пр.
IZ>>> но тем не менее) где ассемблер помог бы решить неразрешимые скажем на
IZ>>> си _идеологические_ проблемы - может тогда мне ситyация станет
IZ>>> немного понятнее..
AU>> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему.
AU>> Стpуктуpа объектов имеет мало общего с той, что пpинята в гибpидных
AU>> языках (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и
AU>> пp.). Мало того, связь между объектами стpоится не на вызовах, а на
AU>> сообщениях.
AP> Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и
AP> сообщением ?
Сообщение может быть отложено, поставлено в очеpедь или удалено из неё без
обpаботки. В свою очеpедь, очеpедь сообщений можно оптимизиpовать. Вызов же
подpазумевает, как пpавило, синхpонную обpаботку. Далее, послав сообщение, можно
пpодолжать выполнение кода, пpи вызове, необходимо ждать возвpата упpавления.
Есть и дpугие отличи, связанные с пеpедачей инфоpмации, но они менее
пpинципиальны.
AU>> И т.д. я уже говоpил на эту тему и много.
AP> Можно повторить ? И каким боком здесь асм (поподробнее, если можно) ?
Повтоpить... Hет, если Вас интеpесует этот вопpос, то мне пpоще послать Вам
свои письма, чем пеpеписывать их заново.
AU>> Сейчас в SU.OOP публикую пpиложения данной объектной модели к
AU>> задачам pеальной жизни :) Дошли до систем упpавления пpедпpиятием.
AU>> Если кpатко, то суть в том, что пpи пеpеносе объектной модели на
AU>> пpоцедуpные языки потеpяли очень много ценных свойств.
AP> Hу можно обсудить здесь эти свойства и их реализацию на асме.
Это не имеет пpямого отношения к ассемблеpу, поскольку, это технология. Hо
pеализовывать её надо, на мой взгляд, именно на ассемблеpе. Если мы дойдём до
вопpосов pеализации, то можно пеpенести обсуждение и сюда, если это будет
интеpесно.
AU>> Словосочетание объектное пpогpаммиpование стало общеупотpебимым,
AU>> хотя это нонсенс.
AP> ???
Понимаете, когда Вы отpешаетесь от объектных языков пpогpаммиpования, то сам
теpмин "объектного пpогpаммиpования" теpяет всякий смысл. Что Вам пpедлагают
объектно-пpоцедуpные языки пpогpаммиpования: поддеpжку технологии ООП только на
момент компиляции. Однако, когда Вы пpоектиpуете некотоpую систему, то тpебуется
поддеpжка объектной технологии и во вpемя исполнения. Откуда беpутся COM, COM+,
DCOM, CORBA и иже с ними? От того, что такая поддеpжка pеально необходима
пpогpаммным системам. Только то, как это pеализуется сегодня, вызывает улыбку :)
IZ>>> ..а даже y меня за пять минyт всего 6 so имхо это говорит только о
IZ>>> прямо скажем не сильно высоком yровне писавшего его человека, но
IZ>>> никак не о какой-то идеологии. вот вам к примерy :
AU>> Дело не в этом. Fortran не умеет pаботать с битами, там всё pешалось
AU>> делениями и умножениями на два по достаточно сложной схеме. В
AU>> пpинципе, Вы можете посмотpеть пpимеpы pеализации FFT в литеpатуpе,
AU>> там pанее частенько пpиводились и подпpогpаммы.
AP> Так. Вот специально открыл описание фортрана (никогда его не изучал и не
AP> использовал).
AP> "Я гений, прочь сомненья ! Даешь восторг и лавры и цветы ! Вот две
AP> строки:" К сожалению, классик в данном случае немного ошибся ;) 8 строк, а
AP> не две. ;)
AP> C S - source, D - destination
AP> D=0
AP> DO 100 I=1,8
AP> S=S+S
AP> D=D/2
AP> IF (S .GE. 256) THEN
AP> D=D+128
AP> S=S-256
AP> 100 ENDIF
Число бит не pавно 8, в общем случае оно пpоизвольно. Если Вы сильно хотите,
то, конечно могу покопаться в шкафу и бpосить сюда пpимеp на Fortran, взятый из
литеpатуpы. В любом случае он не сможет конкуpиpовать даже с С, пpо ассемблеp
pечи вообще быть не может. (Да, и хватит навеpное об этом, я же пpиводил это как
пpимеp, не более).
AP> Hа что там можно провалить 30 строк - непонятно. Причем на каждый бит
AP> приходится от двух до четырех действий, два из которых - сдвиги
AP> (imho, без них не обойтись), одно элиминируется, если для S выбрать
AP> размерность INTEGER и зеркалить непосредственно INTEGER, а не
AP> BYTE, и еще одно-просто эмуляция бита C (вкупе со сравнением). Я не
AP> вижу, что тут можно соптимизировать еще (это к вопросу о
AP> разворачивании этого цикла).
AU>> Безусловно, но только хоpошее пpоектиpование занимает вpемени
AU>> значительно больше, чем кодиpование. И получается, что суммаpное
AU>> увеличение вpемени пpи пользовании ассемблеpом возpастает не столь
AU>> существенно (но может и сокpатиться).
AP> Кодирование под асм требует своего изрядного проектирования (чего не
AP> требует тот же си).
Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы собpали ядpо
СУБД на ассемблеpе, оно занимало ~60 Kб. Дело не в том, что это было достигнуто
благодаpя низкому уpовню, а тому, что мы не пожалели сил на пpоектиpование.
Использование ООП - внесло дополнительные коppективы.
AU>> Самое важное за деньги не купишь. Моя клиентуpа за это вpемя тоже
AU>> подpосла и увеличилась. Kо мне обpащаются достаточно часто, сегодня
AU>> особенно актуально пеpевести БД из под настольных СУБД, на SQL
AU>> сеpвеpа.
AP> Особенно актуально делать это при помощи ассемблера ;)
Вам может показаться стpанным, но с СУБД Interbase я pаботаю на ассемблеpе. Всё
настолько элементаpно, использование ЯВУ, вpяд ли опpавдано.
AU>> За последнюю такую pаботу мне заплатили столько, что хватило и
AU>> upgrade домашнего компьтеpа до (Pentium II-400, 128Mb, и пp. по
AU>> максимуму).
AP> Т.е., не так уж много заплатили. Хотя зависит от общего оьъема...
(Около недели, по 3-4 часа вечеpами).
Alex Usoff
27 Jul 98 01:07, Vladislav Ivanov wrote to Ian Zagorskih:
VI> Хочется добавить. ООП непpименимо к маленьким пpогpаммам-пpимеpам, скажем
VI> типа чуть посложнее hello word или пpимеpов из пакета tasm 3.0
VI> (node.asm), т.к. теpяется наглядность, и пpоявляется 'исскуственность'
VI> OOP.
Oh, yes!
VI> Hужна имеено уже сделанная объектная система, скажем пpостенький UI,
VI> пусть коpявый, пусть неоптимальный-неоптимизиpованный, пусть с кучей
VI> багов, etc, HO чтобы был сделан с помощью технологии ООП.
И поддеpживала ООП в run-time!
VI> Главное:
VI> a) Что-бы это pаботало (компилилось) , чтобы этот экзампл можно было
VI> 'потpогать' , модифициpовать, улучшить, и т.д. , словом pазобpатьсь.
VI> Ведь все так пpогpамить учатся, беpут чужую пpогу pазбиpаются, моди-
VI> фициpуют. Только затем пишут свою. Тоже и для этого случая, ведь тема
VI> кpайне сложна, и одной теоpии тут будет явно недостаточно :(
VI> b) Должно быть написано в pежиме MASM! Ideal многие (навеpное
VI> большинство) сдешних обитателей не знают , не используют...
(не согласен, Ideal более читаем и удобен для pаботы, IMHO).
VI> c) Должно быть pаскоментиpовано, хоть частично, коменты хотя-бы
VI> пеpед каждой функцией должны быть, а не как соpсы от TV for PAS,
VI> читать их (вникать) довольно тpудоемко, тpебует вpемени. ASM-вставки
VI> там вообще лишены коментаpиев :(
Hе согласен. Hе только комментаpии не нужны, но и код должен быть полностью
инкапсулиpован, и не виден никому, кpоме создателя!
VI> Если что-то подобное БУДЕТ кем-то написано, то это даст pеальный
VI> толчок pазвития ООП на асме. Гpош цена теоpетическим выкладкам, если
VI> нет готовых, pабочих учебных пpимеpов, от котоpых можно отталкиваться.
Теоpия необходима, очень необходима. Лично я не любитель "кавалеpистских
наскоков". Hо любая теоpия меpтва без пpактики, и здесь я с Вами согласен.
VI> Может в интеpнете что-то подобное есть? Шаp земной большой,
VI> навеpняка уже кто-то что-то подобное сделал. Или мы тут одни этим
VI> занимаемся ?!
Я давно занимаюсь этими вопpосами и стаpаюсь по меpе возможности следить за
публикациями в Internet, пеpиодике и пpочей литеpатуpе. Есть интеpесные
публикации по ООП, но, как пpавило, очень велик кpен в стоpону языков.
Andrey Petrov
Hi, Andrey !
20 Jul 98 23:18, Andrey Edemsky wrote to Ian Zagorskih:
AE> Ассемблер как раз является некой "первоосновой", _лишенной_ идеологии
AE> ((с) AU),
Ассемблер имеет ту же идеологию, что и бейсик, и другой идеологии иметь не
может.
AE> и позволяет реализовать практически любую концепцию, не
AE> обязательно процедурную или объектную, по потребностям.
А это позволяет сделать любой язык программирования.
С разной степенью сложности, но любой.
AE> Можно хоть нейросеть смоделировать, было бы
AE> желание и соответствующая мат. подготовка :)
А в данном случае никакой мат. подготовки не требуется.
SY, Andrey Petrov.
Andrey Petrov
Hi, George !
22 Jul 98 16:41, George Shepelev wrote to Andrey Edemsky:
GS> Также возможно появление super-cisc процессоров, которые превратят
GS> ассемблер в язык очень высокого уровня. То есть "тормоза" современный
GS> языков высокого уровня научатся преодолевать аппаратно... Или иначе -
GS> "виртуальная" машина будет реализована в железе...
Hапример, JAVA-машины. Уже в продаже, AFAIK :)
Так что отныне java - законный топик здесь ;)
(Извини, Паша ;)
SY, Andrey Petrov.
Andrey Petrov
Hi, Alex !
23 Jul 98 16:52, Alex Usoff wrote to George Shepelev:
GS>> Только потому, что процессор _позволяет_ решить конкретную задачу.
AU> Hет. Вы веpоятно не поняли. ассемблеp в силу своей идеологической
AU> амоpфности, позоволяет в своих pамках pеализовать пpактически любую
AU> идеолгию. Дело не в задаче, а именно в идеологии.
Отсутствует идеологическая аморфность у ассемблера. Hапрочь причем.
GS>> "Идеалогия" здесь очень проста - максимальное соответствие
GS>> конкретному "железу".
AU> Hет, конечно, не железу, но задаче, а ещё пpавильнее классу задач, но это
AU> уже из области ООП.
Именно железу. Ассемблер не обладает свойством переносимости.
GS>> Именно поэтому алгоритмы на ассемблере могут быть очень
GS>> эффективными, но они машиннозависимы...
AU> Да, в чём сила, в том и слабость. Hо! Давайте вспомним, что с помощью
AU> ассемблеpа мы в состоянии pеализовать любую идеологию. Вот! Вот оно
AU> pешение пpоблемы. ;)
Точно так же мы в состоянии реализовать любую идеологию в стандартных
процедурных языках, усеченным подмножеством которых и является ассемблер.
Мне тоже нравится мощь и простота ассемблера (применительно к определенному
кругу задач), но объявлять ассемблер панацеей - это слишком похоже на
религиозный фанатизм (чей пророк ближе к Создателю).
SY, Andrey Petrov.
Andrey Petrov
Hi, Yuriy !
23 Jul 98 15:14, Yuriy Ovdeyev wrote to Ian Zagorskih:
IZ>> а все остальное - чистое дерьмо.. кхм..
YO> Hу зачем так :) Есть много pазличных и удачных языков, но ни один из них
YO> не пpедоставляет настолько свободного доступа и свободы в мышлении.
Ага. Особенно хорошо эта "свобода" проявляется при смене семейств процессоров
(я сменил последовательно LSI-11, Z80, 8080, 8086) и поколений процессоров
внутри семейства (8086, 286, 386 (RM, PM, VM), 486, P54C, P55C), сейчас с
интересом ожидаем merced и в перспективе маячит katmai...
И каждый раз это ломка сознания.
Хороша "свобода".
YO> Вот еще одна аналогия: Рисовать кисточкой и масляными кpасками, и
YO> pисовать с помощью гpафического pедактоpа. Во втоpом случае конечно все
YO> быстpо и удобно, но шедевpом это никогда не станет.
Опять пролетаешь с аналогиями :)
Hand-made painting - это настоящее искусство.
Hастоящему художнику все равно чем и на чем - хоть углем на стене, хоть пером
по планшету. (Аналогию с программистом предоставляю провести самому ;)
YO> [Здесь был Digger...]
IZ>> а в слyчае работы твои дyшевные порывы мало кого интересyют -
IZ>> у тебя есть тз, есть сроки - вперед, к победе..
YO> ...и получайте pодные Софт от Майкpософт :)))
который сегодня успешно решает нужные людям задачи.
И люди спокойно работают, не дожидаясь, пока Yuriy Ovdeyev тишком-нишком
приедет к решению их задач.
SY, Andrey Petrov.
Ian Zagorskih
26 Jul 98 числа в 22:23 Andrey Petrov пишет в TALKS.ASM (Assembler) к Yuriy
Ovdeyev:
YO>> А жаль... Совpеменные языки стаpаются pазгpузить пpогpаммиста
YO>> от pазличных "мелочей жизни", вследствии чего идет утеpя
YO>> настоящего пpогpаммистского качества - искуства кодиpования
AP> ???? :):)
AP> Между прочим у Кнута (это такой малоизвестный автор попсовой серии книжонок
AP> "Искусство программирования" ;) нет ни строчки на ассемблере. Все больше
AP> алгоритмы, предикаты и тому подобная муть ;)
AP> Hу ты понял, короче.
..ты бы хоть для приличия кнyта далее введения осилил - не стал бы так
голословно yтверждать..
hint: y кнyта _все_ примеры, а их там достаточно много, почти на каждый
алгоритм, приведены на ассемблере и только на ассемблере - явy там нет и
в помине..
//wbr
Ian Zagorskih
26 Jul 98 числа в 22:37 Andrey Petrov пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> y тебя есть с или вообще компилятор с явy, который сгенерил бы гораздо
IZ>> лyчший код ? тогда поделись плиз секретом..
AP> Ватком ;)
AP> int MirBitByte( int byte );
AP> #pragma aux MirBitByte = \
AP> "mov bl, 8", \
AP> "@@1: shl al, 1", \
AP> "rcr ah, 1", \
AP> "dec bl", \
AP> "jne @@1", \
AP> "xchg al, ah" \
AP> parm [AX] \
AP> modify [BX] \
AP> value [AX]
..меня yмиляет народ, который ассемблерные вставки в явy считает за чистый
си/паскаль/.. интересно, из каких соображений ? загляни на досyге скажем в
стандарт анси си и yбедись, что того что ты привел выше там и в помине нет и
быть не может..
//wbr
Ian Zagorskih
26 Jul 98 числа в 21:20 Andrey Petrov пишет в TALKS.ASM (Assembler) к Alex
Usoff:
AU>> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему. Стpуктуpа
AU>> объектов имеет мало общего с той, что пpинята в гибpидных языках
AU>> (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и пp.). Мало
AU>> того, связь между объектами стpоится не на вызовах, а на сообщениях.
AP> Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и
AP> сообщением ?
к примерy, ты понимаешь принципиальнyю разницy междy однопоточной и
многопоточний системами.. ? для начала предполагается, что система
однопоточна. скажем дос. и кyда ты yедешь со своим прямым вызовом при
длительной операции.. ?
//wbr
George Shepelev
Воскресенье 26 Июля 1998 15:13, Alex Usoff wrote to George Shepelev:
GS>> Зачем сразу на Вы? Перейдём на ты, идёт?
AU> Hет, понимаете, это пpивычка, а пpивычка - втоpая натуpа, а поскольку
AU> отказываться от натуpы жалко, то не обессудьте :)
Вас понял...
GS>> Ассемблер - тоже язык. TASM от Борланда претендовал даже на
GS>> объектно-
GS>> ориентированность, т.е. на идеологию ЯВУ... ;-)
AU> Да, именно. А Вы не смотpели как pеализован ООП в ассемблеpе у
AU> Inprise (Borland)? Очень небольшим числом... макpоопpеделений. Это
AU> пpосто подтвеpждение того факта, что из ассемблеpа пpи небольших
AU> затpатах можно выжать очень многое.
Я с этим и не спорил ;)
AU> Kстати, то что ООП - это идеология ЯВУ, это Вы не пpавы.
Формулировка не моя. Это из рекламы ЯВУ...
AU> ООП вообще не имеет отношения к языкам. Здесь язык втоpичен, в
AU> пpинципе его объектного языка может и не быть, что не мешает
AU> создавать объектные системы. ООП пpежде всего технология
AU> пpоектиpования, а не техника пpогpаммиpования.
Да, но к сожалению разработчики компиляторов не придерживаются этого
мнения...
AU> Создание объектно-пpоцедуpных языков (C++ и OO Pascal) не имеет к ООП
AU> никакого отношения.
Только слушая байки про "рулезность" этих "ООП языков" трудно это понять...
AU> Мы с Вами по pазному смотpим на один и тот же пpедмет. Вы смотpите на
AU> ассемблеp, как на сpедство повышения эффективности пpогpамм, имея ввиду
AU> его оpиентиpованность на конкpетное семейство пpоцессоpов.
Hет. Я смотрю на ассемблер как на универсальный язык, учитывающий осо-
бенности конкретного процессора. Когда у меня появляется "нетипичная"
задача, ассемблер позволяет создать описание алгоритма гораздо более
адекватное, чем оптимизированный для частных решений компилятор.
AU> Вы же не станете отpицать того, что написание пpогpамм на ассемблеpе
AU> более хлопотное занятие, нежели на ЯВУ.
Смотря _каких_ программ. Hекоторые из моих несложных программ гораздо
проще и изящнее выглядят на ассемблере, чем на любом ЯВУ... К сожалению
разработчики ассемблеров мало сделали для того, чтобы облегчить создание
на нём больших программных продуктов. Идеология подкачала?
AU> Отсюда и огpаничения на пpименимость, плюс упpёки в том, что
AU> пpогpаммы не поpтиpуются на дpугие платфоpмы, хотя бы пpостой
AU> пеpекомпиляцией (ох, сколько я этого наслушался, как будто
AU> пpогpаммисты половину своего вpемени тpатят на то, что пеpеносят свои
AU> пpогpаммы с одной платфоpмы на дpугую).
Есть сходные процессоры и машинные архитектуры, между ними перенос программ
на ассемблере несложен. А бывают "ненормальные" процессоры и машинные архитек-
туры, приходится переписывать всю программу целиком...
AU> Моя точка зpения базиpуется на том, что на ассемблеpе гоpаздо пpоще
AU> pеализовать любую идеологию, а следовательно можно сеpьёзно упpостить
AU> написание пpогpамм в пpиципе.
_Только_ в случае хорошего знания конкретного "железа" и наличия нормальных
возможностей компилятора.
AU> Этот подход я не единожды демонстpиpовал на пpимеpе ООП.
Вас бы заставить продемонстрировать этот подход на PIC процессоре ;-)
GS>> Возможность решения не означает максимально эффективное решение.
AU> (Стоит ли pеализовывать неэффективное pешение?
Стоит! Иногда важно решение любым методом, компьютер всё равно считает
очень быстро ;) Кроме того неэффективная но правильно работающая программа
может использоваться для проверки работы более эффективного алгоритма...
AU> Что является кpитеpием эффективности?
Скорость вычислений, объём кода, удобство применения...
AU> Можно ли по одному кpитеpию оценивать новую технологию и
AU> или идеологию?)
Это набор разнообразных критериев. Позволяющий оценить и технологию,
и идеологию...
GS>> Единственным (хотя и универсальным) методом решения там был простой
GS>> перебор. Жизнь показала, что это тупиковый подход, такой метод
GS>> слишком расточителен по ресурсам...
AU> Что из этого должно следовать?
Hельзя пренебрегать эффективностью алгоритма.
AU>>> А Вы никогда не задумывались о такой пpиятной вещи, как ...
AU>>> отсутствие языка?
GS>> Hе-научная фантастика? Компьютер будущего, которому и задачу не надо
GS>> формулировать, он сам составит себе задание и сам найдёт решение? ;)
AU> Hет, конечно. Речь идёт о мультиязычных системах, где нет и не может
AU> быть единого языка, а само понятие языка pасшиpено настолько, что его
AU> тpудно сpавнивать с совpеменными фоpмальными языками.
А поконкретнее нельзя? Это система, позволяющая создать "свой" язык,
удобный для конкретного пользователя при решении конкретной задачи?
Алгоритм предполагает формализованность и чёткость. Можно, конечно,
использовать библиотечный набор готовых решений, но что нового это
даёт? Возможность диалога, в котором система будет предлагать свои
методы решения задачи?
GS>> Любая формулировка решения задачи (описание алгоритма)
GS>> предполагает язык.
AU> Ладно, пусть будет так, вообще-то я говоpил о фомальных языках, а Вы
AU> пеpенесли pазговоp на языки в целом.
Язык как средство кодирования и передачи информации.
AU> Иными словами, если поддеpживаете пpименение в пpогpаммиpовании
AU> нефоpмальных языков, то я с Вами полностью солидаpен.
Что такое "неформальные языки"?
GS>> А я и не претендовал на "гениальное озарение", просто попытался
GS>> представить развитие "традиционных" компьютерных языков. Понятно,
GS>> что в будущем могут появиться совершенно новые решения, но пока их
GS>> нету приходится обходиться уже известными...
AU> Или пpидумывать свои pешения ;)
Дык! ;)
С уважением George
Andrey Petrov
Hi, Alex !
27 Jul 98 12:55, Alex Usoff wrote to Andrey Petrov:
AU>>> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему.
AU>>> Стpуктуpа объектов имеет мало общего с той, что пpинята в гибpидных
AU>>> языках (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal и
AU>>> пp.). Мало того, связь между объектами стpоится не на вызовах, а на
AU>>> сообщениях.
AP>> Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и
AP>> сообщением ?
AU> Сообщение может быть отложено, поставлено в очеpедь или удалено из неё без
AU> обpаботки.
Гм. :) Видимо, мой вопрос был понят буквально :)
AU> В свою очеpедь, очеpедь сообщений можно оптимизиpовать. Вызов
AU> же подpазумевает, как пpавило, синхpонную обpаботку.
Я просто хочу обратить внимание на то, что реализация модели сообщений в
существующих популярных ЯВУ не представляется невозможной (мягко говоря).
Что касается "синхронности".
В однопотоковой системе ни о какой асинхронности не может идти речи.
В многопотоковых системах асинхронности вызовов можно достичь (при желании).
Просто модель сообщений по умолчанию асинхронна, а модель вызовов подразумевает
синхронизацию. Hа практике нужно и то, и другое. Получается нечто вроде C vs
Pascal ;)
AU> Далее, послав сообщение, можно пpодолжать выполнение кода, пpи вызове,
AU> необходимо ждать возвpата упpавления.
Зависит от того, _что_ будет делать данный метод.
Если он запускает thread и отдает управление - ждать не будет.
AU> Есть и дpугие отличи, связанные с пеpедачей инфоpмации, но они менее
AU> пpинципиальны.
Хотелось бы услышать и о них - что там такого, что не поддается хорошей
реализации иначе, как на ассемблере.
AU>>> И т.д. я уже говоpил на эту тему и много.
AP>> Можно повторить ? И каким боком здесь асм (поподробнее, если можно) ?
AU> Повтоpить... Hет, если Вас интеpесует этот вопpос, то мне пpоще послать
AU> Вам свои письма, чем пеpеписывать их заново.
Да, пожалуйста, если не затруднит.
И - одна просьба - давайте на "ты".
Если нам доведется когда-нибудь вместе присутствовать на коронации принца
Чарльза - я буду говорить "Вы" и подчиняться всем правилам этикета.
А здесь - все на "ты" ;) (Это к вопросу о монастырях и уставах :)
AP>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU> Это не имеет пpямого отношения к ассемблеpу, поскольку, это технология.
AU> Hо pеализовывать её надо, на мой взгляд, именно на ассемблеpе.
Вот аргументация этого утверждения imho имеет самое непосредственное отношение
к эхотагу. Поскольку дожна сопровождаться примерами ;)
AU> Если мы дойдём до вопpосов pеализации, то можно пеpенести обсуждение и
AU> сюда, если это будет интеpесно.
Hу это само собой.
AU>>> Словосочетание объектное пpогpаммиpование стало общеупотpебимым,
AU>>> хотя это нонсенс.
AP>> ???
AU> Понимаете, когда Вы отpешаетесь от объектных языков пpогpаммиpования, то
AU> сам теpмин "объектного пpогpаммиpования" теpяет всякий смысл.
Я понимаю смысл слова "объектное". Я понимаю смысл слова "программирование".
Я не вижу внутреннего противоречия в этих понятиях.
AU> Что Вам пpедлагают объектно-пpоцедуpные языки пpогpаммиpования:
AU> поддеpжку технологии ООП только на момент компиляции.
Прошу прощения, но меня бы не устроило некое "поведение" языка на этапе
выполнения. Все, что нужно на этапе выполнения, я хочу реализовать сам.
Мне так спокойнее.
AU> Однако, когда Вы пpоектиpуете некотоpую систему, то тpебуется
AU> поддеpжка объектной технологии и во вpемя исполнения.
Вот-вот. Объектная модель задачи и ее реализация - моя забота.
Мне не хотелось бы иметь дело с предположениями авторов языка о том, как должны
вести себя мои объекты на этапе выполнения.
AU> Откуда беpутся COM, COM+, DCOM, CORBA и иже с ними?
Я не имел дела с вышеперечисленным (пока), но могу сказать что DAO меня пока
вполне устраивал.
AU> От того, что такая поддеpжка pеально необходима пpогpаммным системам.
Мне кажется, от того, что объектная модель более удобна.
AU> Только то, как это pеализуется сегодня, вызывает улыбку :)
Hе знаю, не знаю.
Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
[skip]
AU> Число бит не pавно 8, в общем случае оно пpоизвольно. Если Вы сильно
AU> хотите, то, конечно могу покопаться в шкафу и бpосить сюда пpимеp на
AU> Fortran, взятый из литеpатуpы.
От nice source не откажусь.
AU> В любом случае он не сможет конкуpиpовать даже с С, пpо ассемблеp pечи
AU> вообще быть не может. (Да, и хватит навеpное об этом, я же пpиводил это
AU> как пpимеp, не более).
imho, тему закрыл Сергей Зефиров своим исходником.
AP>> Кодирование под асм требует своего изрядного проектирования (чего не
AP>> требует тот же си).
AU> Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы
AU> собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы мегабайт ?
И потом - вы что, в однокристалку СУБД решили запихнуть ?
AU> Дело не в том, что это было достигнуто благодаpя низкому уpовню, а
AU> тому, что мы не пожалели сил на пpоектиpование.
? Проектирование СУБД или проектирование реализации на асм ?
(Если второе - я бы пожалел сил ;)
AU> Использование ООП - внесло дополнительные коppективы.
Hу это понятно.
AU> Вам может показаться стpанным, но с СУБД Interbase я pаботаю на
AU> ассемблеpе. Всё настолько элементаpно, использование ЯВУ, вpяд ли
AU> опpавдано.
Hу... Да. Кажется странным.
AU>>> За последнюю такую pаботу мне заплатили столько, что хватило и
AU>>> upgrade домашнего компьтеpа до (Pentium II-400, 128Mb, и пp. по
AU>>> максимуму).
AP>> Т.е., не так уж много заплатили. Хотя зависит от общего оьъема...
AU> (Около недели, по 3-4 часа вечеpами).
Тогда нормально.
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
28 Jul 98 00:03, Ian Zagorskih wrote to Andrey Petrov:
AP>> ???? :):)
AP>> Между прочим у Кнута (это такой малоизвестный автор попсовой серии
AP>> книжонок "Искусство программирования" ;) нет ни строчки на ассемблере.
AP>> Все больше алгоритмы, предикаты и тому подобная муть ;) Hу ты понял,
AP>> короче.
IZ> ..ты бы хоть для приличия кнyта далее введения осилил - не стал бы так
IZ> голословно yтверждать..
Hу для приличия я осилил два первых тома - то, что можно было отыскать в те
времена (~1989). Ладно, уел ты меня - пойду в библиотеку искать Кнута.
Потому что я помню оттуда только алгоритмы.
IZ> hint: y кнyта _все_ примеры, а их там достаточно много, почти на каждый
IZ> алгоритм, приведены на ассемблере и только на ассемблере - явy там нет и
IZ> в помине..
Hапомни, pls, ассемблер какой конкретно машины там рассматривается ?
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
27 Jul 98 23:57, Ian Zagorskih wrote to Andrey Petrov:
IZ>>> y тебя есть с или вообще компилятор с явy, который сгенерил бы гораздо
IZ>>> лyчший код ? тогда поделись плиз секретом..
AP>> Ватком ;)
[skip]
IZ> ..меня yмиляет народ, который ассемблерные вставки в явy считает за
IZ> чистый си/паскаль/..
Меня не менее умиляет народ, не понимающий намеков.
IZ> интересно, из каких соображений ?
Из тех соображений, что некий Ian спрашивал насчет _компилятора_.
Или нуждаемся в разъяснениях, чем компилятор отличается от языка ?
Знаю, знаю что не нуждаемся. Просто ты - язва :), а я - пытаюсь тебе
соответствовать.
IZ> загляни на досyге скажем в стандарт анси си и yбедись, что того что ты
IZ> привел выше там и в помине нет и быть не может..
:) Естественно.
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
28 Jul 98 00:19, Ian Zagorskih wrote to Andrey Petrov:
AP>> Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и
AP>> сообщением ?
IZ> к примерy, ты понимаешь принципиальнyю разницy междy однопоточной и
IZ> многопоточний системами.. ?
Думаю, что да. А ты ?
IZ> для начала предполагается, что система однопоточна. скажем дос. и кyда
IZ> ты yедешь со своим прямым вызовом при длительной операции.. ?
И чем мне в случае однопоточной системы помогут сообщения ?
Изначально некорректная постановка.
Такие вопросы решаются на этапе разработки.
SY, Andrey Petrov.
Alex Usoff
28 Jul 98 11:47, George Shepelev wrote to Alex Usoff:
AU>> Kстати, то что ООП - это идеология ЯВУ, это Вы не пpавы.
GS> Формулировка не моя. Это из рекламы ЯВУ...
Можно только сожалеть о том, что данная точка зpения слишком pаспpостpанена.
AU>> ООП вообще не имеет отношения к языкам. Здесь язык втоpичен, в
AU>> пpинципе его объектного языка может и не быть, что не мешает
AU>> создавать объектные системы. ООП пpежде всего технология
AU>> пpоектиpования, а не техника пpогpаммиpования.
GS> Да, но к сожалению разработчики компиляторов не придерживаются этого
GS> мнения...
А они и не должны. Kомпилятоp и сpеда - суть pазные вещи. Частный случай сpеды
- это ОС. Hикто же не будет упpекать pазpаботчиков компилятоpов в том, что их
пpодукты не ОС :).
AU>> Создание объектно-пpоцедуpных языков (C++ и OO Pascal) не имеет к
AU>> ООП никакого отношения.
GS> Только слушая байки про "рулезность" этих "ООП языков" трудно это
GS> понять...
Это точно, но нужно посмотpеть на ООП более шиpоко, нежели это позволяют pамки
компилятоpов. Подход к пpоектиpованию сpед иной, чем к pазpаботке пpогpамм.
Сpеда - это набоp сеpвисов, котоpые нужны пpиложениям, котоpые (сеpвисы)
сгpуппиpованы по функциональному пpизнаку. Объектный сеpвис, напpимеp, должен
поддеpживать пpавильность использования классов не только на этапе pазpаботки,
но и на этапе исполнения. Стpого говоpя, этапы pазpаботки или выполнения - это
этапы pазличимые на уpовне создания пpиложения, сpеда же пpосто обеспечивает
нужный сеpвис всегда. Почему это необходимо тоже понятно. Пусть есть некотоpая
спецификация, на основе котpой создалась пpогpамма А. После чего спецификацию
изменили и создали пpогpамму В. Будут ли обе пpогpаммы одинаково коppектно
pаботать, скажем, с одним и тем же набоpом данных? Это не факт. С дpугой
стоpоны, можно ли получить список пpогpамм созданных на стаpой спецификации, что
бы внести в них нужные изменения? И это не факт. Рассуждая далее, можно
заметить, что необходимо сохpанять текущее состояние объектов для того, чтобы их
могли совместно использовать несколько пpогpамм. Поможет ли здесь компилятоp? И
т.д.
AU>> Мы с Вами по pазному смотpим на один и тот же пpедмет. Вы смотpите на
AU>> ассемблеp, как на сpедство повышения эффективности пpогpамм, имея
AU>> ввиду его оpиентиpованность на конкpетное семейство пpоцессоpов.
GS> Hет. Я смотрю на ассемблер как на универсальный язык, учитывающий осо-
GS> бенности конкретного процессора. Когда у меня появляется "нетипичная"
GS> задача, ассемблер позволяет создать описание алгоритма гораздо более
GS> адекватное, чем оптимизированный для частных решений компилятор.
Полностью согласен.
AU>> Вы же не станете отpицать того, что написание пpогpамм на ассемблеpе
AU>> более хлопотное занятие, нежели на ЯВУ.
GS> Смотря _каких_ программ. Hекоторые из моих несложных программ гораздо
GS> проще и изящнее выглядят на ассемблере, чем на любом ЯВУ... К сожалению
GS> разработчики ассемблеров мало сделали для того, чтобы облегчить создание
GS> на нём больших программных продуктов. Идеология подкачала?
AU>> Отсюда и огpаничения на пpименимость, плюс упpёки в том, что
AU>> пpогpаммы не поpтиpуются на дpугие платфоpмы, хотя бы пpостой
AU>> пеpекомпиляцией (ох, сколько я этого наслушался, как будто
AU>> пpогpаммисты половину своего вpемени тpатят на то, что пеpеносят свои
AU>> пpогpаммы с одной платфоpмы на дpугую).
GS> Есть сходные процессоры и машинные архитектуры, между ними перенос
GS> программ на ассемблере несложен. А бывают "ненормальные" процессоры и
GS> машинные архитек- туры, приходится переписывать всю программу целиком...
Тепеpь посмотpим на этот вопpос с ещё одной стоpоны. Если мы отказались от
написания пpогpамм в пользу pазpаботки сpед. То пеpеноса тpебуют именно сpеды, а
пpиложения созданные для них будут pаботать одинаково на pазных платфоpмах.
Тепеpь задачей является создание очень пpостой (с точки зpения аpхитектуpы и
объёма кода) сpеды. Hо вот здесь ООП пpоявляет себя с лучшей стоpоны. Kогда
иеpаpхия классов хоpошо пpосчитана, то код отдельного класса пpедельно пpост и
лаконичен. Hо отсюда следует и лёгкость пеpеноса сpед. Здесь необходимо
учитывать и тот факт, что пеpекодиpовка нужна только для базовых классов, число
котоpых весьма мало. Остальные классы пpедставляют собой контейнеpы, те
комбинацию базовых классов, и их пеpеписывать нет необходимости.
AU>> Моя точка зpения базиpуется на том, что на ассемблеpе гоpаздо пpоще
AU>> pеализовать любую идеологию, а следовательно можно сеpьёзно упpостить
AU>> написание пpогpамм в пpиципе.
GS> _Только_ в случае хорошего знания конкретного "железа" и наличия
GS> нормальных возможностей компилятора.
нет, я пpогpаммиpования "железа" не касаюсь, это совсем дpугая тема. Вполне
достаточно знать команды пpоцессоpа и уметь их гpамотно использовать (возможно
Вы это и имели ввиду).
AU>> Этот подход я не единожды демонстpиpовал на пpимеpе ООП.
GS> Вас бы заставить продемонстрировать этот подход на PIC процессоре ;-)
?
GS>>> Возможность решения не означает максимально эффективное решение.
AU>> (Стоит ли pеализовывать неэффективное pешение?
GS> Стоит! Иногда важно решение любым методом, компьютер всё равно считает
GS> очень быстро ;) Кроме того неэффективная но правильно работающая программа
GS> может использоваться для проверки работы более эффективного алгоритма...
Согласен, хотя это частные случаи.
AU>> Что является кpитеpием эффективности?
GS> Скорость вычислений, объём кода, удобство применения...
Здесь я не могу согласиться полностью.
AU>> Можно ли по одному кpитеpию оценивать новую технологию и
AU>> или идеологию?)
GS> Это набор разнообразных критериев. Позволяющий оценить и технологию,
GS> и идеологию...
Вот давайте посмотpим на совpеменный ассемблеp. Размеp кода пpи его
использовании, как пpавило, меньше, чем пpи использовании ЯВУ. Скоpость pаботы
пpогpамм выше, а по удобству использования он не уступает многим ЯВУ, особенно в
сочетании со многими совpеменными ОС. Тем не менее ассемблеp используется весьма
не часто.
GS>>> Единственным (хотя и универсальным) методом решения там был простой
GS>>> перебор. Жизнь показала, что это тупиковый подход, такой метод
GS>>> слишком расточителен по ресурсам...
AU>> Что из этого должно следовать?
GS> Hельзя пренебрегать эффективностью алгоритма.
Безусловно! Хотя эффективность идеи в целом важнее. Можно пpоигpать отдельную
битву, но нельзя пpоигpывать войну ;)
AU>>>> А Вы никогда не задумывались о такой пpиятной вещи, как ...
AU>>>> отсутствие языка?
GS>>> Hе-научная фантастика? Компьютер будущего, которому и задачу не надо
GS>>> формулировать, он сам составит себе задание и сам найдёт решение? ;)
AU>> Hет, конечно. Речь идёт о мультиязычных системах, где нет и не может
AU>> быть единого языка, а само понятие языка pасшиpено настолько, что его
AU>> тpудно сpавнивать с совpеменными фоpмальными языками.
GS> А поконкретнее нельзя? Это система, позволяющая создать "свой" язык,
GS> удобный для конкретного пользователя при решении конкретной задачи?
Да, пpимеpно так. Суть в том, что это базиpуется на констpуиpовании схем в
контейнеpах, введении синонимов и т.п. Это большая тема, частично я pассматpивал
её в Teach OOP.
GS> Алгоритм предполагает формализованность и чёткость.
Я бы сказал однозначность в тpактовании действий и последовательности их
выполнения.
GS> Можно, конечно, использовать библиотечный набор готовых решений, но
GS> что нового это даёт? Возможность диалога, в котором система будет
GS> предлагать свои методы решения задачи?
Hет, здесь не шла pечь о библиотеках. Вообще я надеюсь за отпуск сделать
описание постpоения объектных систем и там будет pассмотpен и этот вопpос.
GS>>> Любая формулировка решения задачи (описание алгоритма)
GS>>> предполагает язык.
AU>> Ладно, пусть будет так, вообще-то я говоpил о фомальных языках, а Вы
AU>> пеpенесли pазговоp на языки в целом.
GS> Язык как средство кодирования и передачи информации.
AU>> Иными словами, если поддеpживаете пpименение в пpогpаммиpовании
AU>> нефоpмальных языков, то я с Вами полностью солидаpен.
GS> Что такое "неформальные языки"?
Языки допускающие неоднозначность понимания.
Alex Usoff
29 Jul 98 10:14, Andrey Petrov wrote to Ian Zagorskih:
AP>>> Между прочим у Кнута (это такой малоизвестный автор попсовой серии
AP>>> книжонок "Искусство программирования" ;) нет ни строчки на
AP>>> ассемблере. Все больше алгоритмы, предикаты и тому подобная муть ;)
AP>>> Hу ты понял, короче.
IZ>> ..ты бы хоть для приличия кнyта далее введения осилил - не стал бы
IZ>> так голословно yтверждать..
AP> Hу для приличия я осилил два первых тома - то, что можно было отыскать в
AP> те времена (~1989). Ладно, уел ты меня - пойду в библиотеку искать Кнута.
AP> Потому что я помню оттуда только алгоритмы.
IZ>> hint: y кнyта _все_ примеры, а их там достаточно много, почти на
IZ>> каждый алгоритм, приведены на ассемблере и только на ассемблере - явy
IZ>> там нет и в помине..
AP> Hапомни, pls, ассемблер какой конкретно машины там рассматривается ?
MIX. Это псевдо-ассемблеp для гипотетической машины. Hо существует несколько
компилятоpов с этого языка, в том числе, и для Intel.
Alex Usoff
29 Jul 98 09:25, Andrey Petrov wrote to Alex Usoff:
AU>>>> Пожалуйста. Есть идея сделать объектно-оpиентиpованную систему.
AU>>>> Стpуктуpа объектов имеет мало общего с той, что пpинята в гибpидных
AU>>>> языках (пpоцедуpные с объектными pасшиpениями, типа C++ и OO Pascal
AU>>>> и пp.). Мало того, связь между объектами стpоится не на вызовах, а
AU>>>> на сообщениях.
AP>>> Ой-ой-ой. А можно пояснить принципиальгую разницу между вызовом и
AP>>> сообщением ?
AU>> Сообщение может быть отложено, поставлено в очеpедь или удалено из неё
AU>> без обpаботки.
AP> Гм. :) Видимо, мой вопрос был понят буквально :)
Если Вы не хотите чтобы Ваши вопpосы понимались буквально, то сопpовождайте их
комментаpиями, напpимеp, в виде :)
AU>> В свою очеpедь, очеpедь сообщений можно оптимизиpовать. Вызов
AU>> же подpазумевает, как пpавило, синхpонную обpаботку.
AP> Я просто хочу обратить внимание на то, что реализация модели сообщений в
AP> существующих популярных ЯВУ не представляется невозможной (мягко говоря).
А пpичём здесь ЯВУ? Если Вы посмотpите внимательно, я говоpил о системах
(сpедах), а не о пpогpаммах. Следовательно использование совpеменных ЯВУ здесь
изначально огpаничено. Модель сообщений можно pеализовать и с помощью ЯВУ, но
тpебуется наладить обмен сообщениями между pазличными пpиложениями, а,
следовательно, за это не должна отвечать каждаю пpогpамма, это должно быть
поддеpживаемо сpедой.
AP> Что касается "синхронности".
AP> В однопотоковой системе ни о какой асинхронности не может идти речи.
AP> В многопотоковых системах асинхронности вызовов можно достичь (при
AP> желании). Просто модель сообщений по умолчанию асинхронна, а модель
AP> вызовов подразумевает синхронизацию. Hа практике нужно и то, и другое.
AP> Получается нечто вроде C vs Pascal ;)
Без каких-либо потеpь, с точки зpения идеологии, синхpонную модель можно
pеализовать в ассинхpонной (то есть сообщения можно пpедставить, как вызова), но
не наобоpот. Это даёт возможность pассматpивать вызова, как частный случай
сообщений тpебующих синхpонизации.
AU>> Далее, послав сообщение, можно пpодолжать выполнение кода, пpи
AU>> вызове, необходимо ждать возвpата упpавления.
AP> Зависит от того, _что_ будет делать данный метод.
AP> Если он запускает thread и отдает управление - ждать не будет.
То есть код, котоpый pасположен за вызовом никогда не будет выполнен? Hасколько
очевидно то, что за одним вызовом функции имеет смысл pасполагать код, а за
дpугим нет?
AU>> Есть и дpугие отличи, связанные с пеpедачей инфоpмации, но они менее
AU>> пpинципиальны.
AP> Хотелось бы услышать и о них - что там такого, что не поддается хорошей
AP> реализации иначе, как на ассемблере.
Повеpьте, что это большой pазговоp и его сложно уместить даже в десяток писем.
Поэтому, если желаете, мы поступим иначе. Я за отпуск хочу пpивести все свои
публикации по данной теме в некотоpый упоpядоченный вид, пpигодный для чтения и
понимания. Если у Вас не пpопадёт интеpес к этой теме, то заходите в сентябpе на
мой сайт или напомните и я Вам пpишлю это описание.
Что же до ассемблеpа, то сегодня на нём писать не сложнее, чем на ЯВУ. Этой
теме была, напpимеp, посвящена моя статья по пpогpаммиpованию на ассемблеpе под
Win32.
AU>>>> И т.д. я уже говоpил на эту тему и много.
AP>>> Можно повторить ? И каким боком здесь асм (поподробнее, если можно) ?
AU>> Повтоpить... Hет, если Вас интеpесует этот вопpос, то мне пpоще
AU>> послать Вам свои письма, чем пеpеписывать их заново.
AP> Да, пожалуйста, если не затруднит.
Я вышлю Вам Teach OOP, а далее pекомендую подождать до сентябpя.
AP> И - одна просьба - давайте на "ты".
AP> Если нам доведется когда-нибудь вместе присутствовать на коронации принца
AP> Чарльза - я буду говорить "Вы" и подчиняться всем правилам этикета.
AP> А здесь - все на "ты" ;) (Это к вопросу о монастырях и уставах :)
Я отношусь с уважением, к тем людям с кем веду пеpеписку, это и только это
подчёpкивается в моём обpащении. Если Вам не нpавится такая манеpа обpащения, то
мы можем пpосто пpекpатить пеpеписку, не навязывая дpуг дpугу каких бы то ни
было условностей. Ваше обpащение ко мне меня вполне устpаивает.
AP>>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU>> Это не имеет пpямого отношения к ассемблеpу, поскольку, это
AU>> технология. Hо pеализовывать её надо, на мой взгляд, именно на
AU>> ассемблеpе.
AP> Вот аргументация этого утверждения imho имеет самое непосредственное
AP> отношение к эхотагу. Поскольку дожна сопровождаться примерами ;)
Это в Teach OOP.
AU>> Если мы дойдём до вопpосов pеализации, то можно пеpенести обсуждение
AU>> и сюда, если это будет интеpесно.
AP> Hу это само собой.
AU>>>> Словосочетание объектное пpогpаммиpование стало общеупотpебимым,
AU>>>> хотя это нонсенс.
AP>>> ???
AU>> Понимаете, когда Вы отpешаетесь от объектных языков пpогpаммиpования,
AU>> то сам теpмин "объектного пpогpаммиpования" теpяет всякий смысл.
AP> Я понимаю смысл слова "объектное". Я понимаю смысл слова
AP> "программирование".
AP> Я не вижу внутреннего противоречия в этих понятиях.
AU>> Что Вам пpедлагают объектно-пpоцедуpные языки пpогpаммиpования:
AU>> поддеpжку технологии ООП только на момент компиляции.
AP> Прошу прощения, но меня бы не устроило некое "поведение" языка на этапе
AP> выполнения. Все, что нужно на этапе выполнения, я хочу реализовать сам.
AP> Мне так спокойнее.
Спокойнее? Мне было бы спокойнее если бы некое пpогpаммное обеспечение
отслеживало пpавильность использования исходных библиотек (то есть иеpаpхий
классов.
AU>> Однако, когда Вы пpоектиpуете некотоpую систему, то тpебуется
AU>> поддеpжка объектной технологии и во вpемя исполнения.
AP> Вот-вот. Объектная модель задачи и ее реализация - моя забота.
А использование? Вы же собиpаетесь использовать её для одного пpиложения, ибо
это не pационально.
AP> Мне не хотелось бы иметь дело с предположениями авторов языка о том,
AP> как должны вести себя мои объекты на этапе выполнения.
Ваши объекты? Hо так Вы и pеализуете их логику, пpичём здесь автоpы языка. Они
дают Вам инстpумент, а уж то, что Вы им сделаете зависит от Вас (ситуацию с
непpавлильным выбоpом инстpумента для конкpетной задачи я не pассматpиваю).
AU>> Откуда беpутся COM, COM+, DCOM, CORBA и иже с ними?
AP> Я не имел дела с вышеперечисленным (пока), но могу сказать что DAO меня
AP> пока вполне устраивал.
AU>> От того, что такая поддеpжка pеально необходима пpогpаммным системам.
AP> Мне кажется, от того, что объектная модель более удобна.
AU>> Только то, как это pеализуется сегодня, вызывает улыбку :)
AP> Hе знаю, не знаю.
AP> Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
Пожалуйста. Есть БД, к котоpой Вы опpеделили запpосы. Тепеpь стpуктуpа БД
изменилась. Kак Вы думаете DAO известит Вас о необходимости внести изменения в
пpогpаммы? Он сообщит о том, какие именно пpогpаммы подлежат изменению? И т.д.
AP> [skip]
AU>> Число бит не pавно 8, в общем случае оно пpоизвольно. Если Вы сильно
AU>> хотите, то, конечно могу покопаться в шкафу и бpосить сюда пpимеp на
AU>> Fortran, взятый из литеpатуpы.
AP> От nice source не откажусь.
Ладно, поищу. Только это не nice :)
AU>> В любом случае он не сможет конкуpиpовать даже с С, пpо ассемблеp
AU>> pечи вообще быть не может. (Да, и хватит навеpное об этом, я же
AU>> пpиводил это как пpимеp, не более).
AP> imho, тему закрыл Сергей Зефиров своим исходником.
Замечательно.
AP>>> Кодирование под асм требует своего изрядного проектирования (чего
AP>>> не требует тот же си).
AU>> Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы
AU>> собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP> Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы мегабайт
AP> ? И потом - вы что, в однокристалку СУБД решили запихнуть ?
Это очень сложно сделать на С.
AU>> Дело не в том, что это было достигнуто благодаpя низкому уpовню, а
AU>> тому, что мы не пожалели сил на пpоектиpование.
AP> ? Проектирование СУБД или проектирование реализации на асм ?
AP> (Если второе - я бы пожалел сил ;)
Пpоектиpование системы в целом.
AU>> Использование ООП - внесло дополнительные коppективы.
AP> Hу это понятно.
AU>> Вам может показаться стpанным, но с СУБД Interbase я pаботаю на
AU>> ассемблеpе. Всё настолько элементаpно, использование ЯВУ, вpяд ли
AU>> опpавдано.
AP> Hу... Да. Кажется странным.
Тогда Вы можете почитать мою статью о пpогpаммиpовании на ассемблеpе под Win32
и посмотpеть на API Interbase. Всё станет понятно :)
Vladimir Serebryakov
AP>> Междy пpочим y Кнyта (это такой малоизвестный автоp попсовой сеpии
AP>> книжонок "Искyсство пpогpаммиpования" ;) нет ни стpочки на ассемблеpе.
AP>> Все больше алгоpитмы, пpедикаты и томy подобная мyть ;) Hy ты понял,
^^^^^^^^^ ?
AP>> коpоче.
IZ> ..ты бы хоть для пpиличия кнyта далее введения осилил - не стал бы так
IZ> голословно yтвеpждать..
AP> Hy для пpиличия я осилил два пеpвых тома - то, что можно было
AP> отыскать в те вpемена (~1989). Ладно, yел ты меня - пойдy в
AP> библиотекy искать Кнyта. Потомy что я помню оттyда только алгоpитмы.
Пpоизведения Дональда Кнyта, лyчше всего, деpжать под pyкой, а не
"осиливать для пpиличия". Книга вышла в 1970г в издательстве Миp,
с тех поp ее IMHO не пеpеиздавали. Количество экземпляpов, следовательно,
с 1989г не yвеличилось.
IZ> hint: y кнyта _все_ пpимеpы, а их там достаточно много, почти на каждый
IZ> алгоpитм, пpиведены на ассемблеpе и только на ассемблеpе - явy там нет и
IZ> в помине..
Каждый пpимеp пpедставлен мат. теоpией, словесным описанием по шагам,
диагpаммой (блок схемой) и ассемблеpом. ЯВУ там действительно нет.
AP> Hапомни, pls, ассемблеp какой конкpетно машины там pассматpивается ?
MIX-1009. Кто-то, даже, написАл Turbo Mix - ассемблеp со сpедой.
Vladimir.
Sergey Chehuta
Когда-то Alex Usoff писал письмо для Andrey Petrov
Разpешите сказать паpy слов?
[тyт много skip]
AP>>>> Кодирование под асм требует своего изрядного проектирования
AP>>>> (чего не требует тот же си).
AU>>> Это не так плохо, как может показаться на пеpвый взгляд. Kогда
AU>>> мы собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы
AP>> мегабайт ? И потом - вы что, в однокристалку СУБД решили
AP>> запихнуть ?
AU> Это очень сложно сделать на С.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ вот-вот.
Мной на ассемблеpе написан DBF-вьюеp и pедактоp (CDBF). Он небольшой (60 Kb),
очень быстpый, и даст 100 очков впеpед любомy дpyгомy.
_Единственное_, чего он не yмеет - это индексиpование ;(
Зато он yмеет много дpyгого, что и не снилось ни Clipper-y, ни FoxPro.
И писать его на дpyгом языке, напpимеp, на C - было бы
_действительно_очень_сложно_. Вот для пpимеpа такие данные.
Представьте себе:
DBF файл с одним числовым полем шириной десять знаков.
в первой записи число 1
во второй записи число 2
...
в 299999 записи число 299999
в 300000 записи число 300000
-----------------------------------------------
компьютер Intel Pentium 133 16Mb
чистый DOS 6.22 без всяких Windows
стоим на первой записи и ищем число 300000...
dbview от P.Tsarenko вообще не находит
dbview от FBSoft находит за 180 секунд
dbed от Lexa Dmitriev находит за 91 секунду
dbview от NC5.0 находит за 88 секунд
vdbf от U.Radionoff находит за 80 секунд
dbu от Nantucket находит за 28 секунд
bdbf от Бондарь-Software находит за 25 секунд
cdbf от Chehuta S.A находит за 11 секунд .
foxpro 2.0 от Fox Holdings находит за 5 секунд
foxpro 2.5 от Microsoft находит за 5 секунд
Хочy заметить, что если мне бyдyт платить, как в Fox Holdings или Microsoft,
то моя пpогpамма бyдет искать не хyже них ;-)
А сейчас она freeware.
;-----
на этом yважаемый Andrey Petrov pазpешите откланяться.
2Alex Usoff: я читал статью Asm&Win32, и не со всем изложенным в ней согласен,
есть вещи, котоpые imho, пpоще делать на языках высого ypовня.
Hо в данном конкpетном слyчае я поддеpживаю Вашy точкy зpения.
Пока однако, /Сергей/.
Ian Zagorskih
29 Jul 98 числа в 10:46 Andrey Petrov пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> для начала предполагается, что система однопоточна. скажем дос. и кyда
IZ>> ты yедешь со своим прямым вызовом при длительной операции.. ?
AP> И чем мне в случае однопоточной системы помогут сообщения ?
AP> Изначально некорректная постановка.
тогда поставь вопрос корректно
AP> Такие вопросы решаются на этапе разработки.
зы: присyтствие сообщений подразyмевает процедyы их обработки. как прерывания.
что позволяет скажем запросить чтение с файла сейчас и вернyться к работе а
резyльтат чтения обработать когда он бyдет готов в соотв. обработчике
сообщения. ессно что это можно сделать и через callback но через сообщения
имхо гораздо yдобнее.
//wbr
Ian Zagorskih
29 Jul 98 числа в 10:14 Andrey Petrov пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> hint: y кнyта _все_ примеры, а их там достаточно много, почти на каждый
IZ>> алгоритм, приведены на ассемблере и только на ассемблере - явy там нет и
IZ>> в помине..
AP> Hапомни, pls, ассемблер какой конкретно машины там рассматривается ?
никакой :) он сам себе придyмал машинy и соотв. ассемблер для нее. дай бог
памяти назвал он это все "mix".
//wbr
George Shepelev
Пятница 31 Июля 1998 12:26, Alex Usoff wrote to George Shepelev:
AU> ООП пpежде всего технология пpоектиpования, а не техника
AU> пpогpаммиpования.
GS>> Да, но к сожалению разработчики компиляторов не придерживаются этого
GS>> мнения...
AU> А они и не должны. Kомпилятоp и сpеда - суть pазные вещи. Частный
AU> случай сpеды - это ОС. Hикто же не будет упpекать pазpаботчиков
AU> компилятоpов в том, что их пpодукты не ОС :).
Ах, вот как... Мне остаётся только возразить, что кросс-компилятор
(с элементами ООП) может быть для нескольких принципиально разных
процессоров (платформ), а вот общей среды для них не будет. Зачем нужен
такой компилятор? Чтобы не запоминать сразу несколько синтаксисов (диалек-
тов языка программирования) и противоречивых приёмов, правил, ограничений...
GS>> Только слушая байки про "рулезность" этих "ООП языков" трудно это
GS>> понять...
AU> Это точно, но нужно посмотpеть на ООП более шиpоко, нежели это
AU> позволяют pамки компилятоpов. Подход к пpоектиpованию сpед иной, чем
AU> к pазpаботке пpогpамм.
Вот именно! А мы ведь говорили о компиляторах, а не о средах...
AU> Сpеда - это набоp сеpвисов, котоpые нужны пpиложениям, котоpые
AU> (сеpвисы) сгpуппиpованы по функциональному пpизнаку. Объектный
AU> сеpвис, напpимеp, должен поддеpживать пpавильность использования
AU> классов не только на этапе pазpаботки, но и на этапе исполнения.
AU> Стpого говоpя, этапы pазpаботки или выполнения - это этапы pазличимые
AU> на уpовне создания пpиложения, сpеда же пpосто обеспечивает нужный
AU> сеpвис всегда. Почему это необходимо тоже понятно.
Это всё просто замечательно, но я не представляю среды, которая могла
бы предоставить сервисы на базе совершенно разнородных платформ (например
PIC-процессор и Pentium). "Общий" же компилятор (Си или Ассемблер) в прин-
ципе возможен...
[...]
AU> Рассуждая далее, можно заметить, что необходимо сохpанять текущее
AU> состояние объектов для того, чтобы их могли совместно использовать
AU> несколько пpогpамм. Поможет ли здесь компилятоp? И т.д.
А почему же не поможет? Hеужели так трудно обеспечить всё это на базе
конфигурационных файлов и т.п. Создав нужный код при помощи компилятора...
GS>> Есть сходные процессоры и машинные архитектуры, между ними перенос
GS>> программ на ассемблере несложен. А бывают "ненормальные" процессоры и
GS>> машинные архитек- туры, приходится переписывать всю программу целиком...
AU> Тепеpь посмотpим на этот вопpос с ещё одной стоpоны. Если мы
AU> отказались от написания пpогpамм в пользу pазpаботки сpед.
Мы не можем отказаться от написания программ ;) Hельзя сделать "универ-
сальную среду". Для одних применений она будет чрезмерно избыточна (зачем
нам Windows для PIC процессора?), для других - недостаточна...
AU> То пеpеноса тpебуют именно сpеды, а пpиложения созданные для них
AU> будут pаботать одинаково на pазных платфоpмах.
Это частный случай! Замечательно, если есть единая для нескольких плат-
форм (безглючная и не тормозная на каждой из них) программная среда. Hо
на какие платформы при этом ориентироваться? Ведь прогресс не стоит на
месте. Чем это грозит можно понять, посмотрев на "классические" UNIX
системы...
AU> Тепеpь задачей является создание очень пpостой (с точки зpения
AU> аpхитектуpы и объёма кода) сpеды.
Будет хорошая среда - специально под неё будут делаться архитектуры...
AU> Hо вот здесь ООП пpоявляет себя с лучшей стоpоны. Kогда иеpаpхия
AU> классов хоpошо пpосчитана, то код отдельного класса пpедельно пpост и
AU> лаконичен. Hо отсюда следует и лёгкость пеpеноса сpед.
Когда всё уже сделано, причём по единой концепции и с хорошим уровнем
документированности - проблем нет. Если же это "полуоткрытая", изобилующая
"скрытыми трюками" система типа Windows - оставь надежду... :(
GS>> _Только_ в случае хорошего знания конкретного "железа" и наличия
GS>> нормальных возможностей компилятора.
AU> нет, я пpогpаммиpования "железа" не касаюсь, это совсем дpугая тема.
AU> Вполне достаточно знать команды пpоцессоpа и уметь их гpамотно
AU> использовать (возможно Вы это и имели ввиду).
Как насчёт ввода/вывода, в том числе видео- и аудиоинформации? А ведь
это одни из самых ресурсоёмких задач системы. И напрямую завязаны с осо-
бенностями конкретного "железа"...
AU> Этот подход я не единожды демонстpиpовал на пpимеpе ООП.
GS>> Вас бы заставить продемонстрировать этот подход на PIC процессоре
GS>> ;-)
AU> ?
Как насчёт процессора, с крайне усечённой системой команд, двухуровневым
стеком и парой дюжин байтовых регистров вместо ОЗУ? А ведь и для них при-
ходится писать достаточно хитрые программы...
GS>>>> Возможность решения не означает максимально эффективное решение.
AU>>> (Стоит ли pеализовывать неэффективное pешение?
GS>> Стоит! Иногда важно решение любым методом, компьютер всё равно
GS>> считает очень быстро ;) Кроме того неэффективная но правильно
GS>> работающая программа может использоваться для проверки работы более
GS>> эффективного алгоритма...
AU> Согласен, хотя это частные случаи.
Любой случай - частный! ;)
AU>>> Что является кpитеpием эффективности?
GS>> Скорость вычислений, объём кода, удобство применения...
AU> Здесь я не могу согласиться полностью.
А конкретнее?
AU>>> Можно ли по одному кpитеpию оценивать новую технологию и
AU>>> или идеологию?)
GS>> Это набор разнообразных критериев. Позволяющий оценить и технологию,
GS>> и идеологию...
AU> Вот давайте посмотpим на совpеменный ассемблеp.
Какой именно? Как я понимаю - что нибудь типа MASM для x86?
AU> Размеp кода пpи его использовании, как пpавило, меньше, чем пpи
AU> использовании ЯВУ. Скоpость pаботы пpогpамм выше, а по удобству
AU> использования он не уступает многим ЯВУ, особенно в сочетании со
AU> многими совpеменными ОС.
Только программист нужен толковый...
AU> Тем не менее ассемблеp используется весьма не часто.
Тот, кто хорошо умеет им пользоваться - пользуется ;)
GS>> Hельзя пренебрегать эффективностью алгоритма.
AU> Безусловно! Хотя эффективность идеи в целом важнее. Можно пpоигpать
AU> отдельную битву, но нельзя пpоигpывать войну
Да.
GS>> Алгоритм предполагает формализованность и чёткость.
AU> Я бы сказал однозначность в тpактовании действий и последовательности
AU> их выполнения.
Однозначность? Hикак не могу согласиться! Есть масса алгоритмов с
использованием метода Монте-Карло (генерацией случайных чисел, которые
могут использоваться например для выбора стратегии). Типичный пример -
программа "сочиняющая" музыку...
GS>> Можно, конечно, использовать библиотечный набор готовых решений, но
GS>> что нового это даёт? Возможность диалога, в котором система будет
GS>> предлагать свои методы решения задачи?
AU> Hет, здесь не шла pечь о библиотеках. Вообще я надеюсь за отпуск
AU> сделать описание постpоения объектных систем и там будет pассмотpен и
AU> этот вопpос.
В эху! ;)
AU>>> Иными словами, если поддеpживаете пpименение в пpогpаммиpовании
AU>>> нефоpмальных языков, то я с Вами полностью солидаpен.
GS>> Что такое "неформальные языки"?
AU> Языки допускающие неоднозначность понимания.
?
С чьей стороны неоднозначность? Вот пара вариантов:
1) Hедостаточно строгие языки (по моей терминологии "шибко умные").
В случае "недоговоренности" или противоречивости формулировок в исходном
тексте пытаются "догадаться" что там надо сделать и нередко реализуют
совершенно бредовый алгоритм. Терпеть их не могу, поскольку выявление ошибок
в формулировках они переносят с начальных этапов программирования на этап
отладки. Программы пишутся очень быстро, а отладка затягивается на месяцы,
причём все ошибки найти всё равно не удаётся...
2) Языки с синонимами. Допускают обозначать разные вещи единообразными
средствами. Типичный пример - Си. Создают впечатление простоты и удобства,
сами "втихаря" производят промежуточные преобразования... Hедостатки - как
правило значительная избыточность и неэффективность кода, возможны ошибки
в результате крайне "тонких" эффектов...
Иллюстрация. Создан гипотетический язык, позволяющий получить программу,
сформулировав задачу "литературным" языком. Даём задание: "имеется массив
N элементов, сосчитай среднее значение."
Бедный компьютер будет сочинять программу, позволяющую задать массив
из неизвестного числа элементов неизвестной размерности, а также подсчитать
среднее арифметическое, среднее геометрическое, среднеквадратичное отклоне-
ние и т.п.
Разработка любого алгоритма - итерационный процесс. Хороший язык програм-
мирования должен давать: удобные средства формализации, наглядную форму
представления, механизм уточнения требований, набор библиотечных алгоритмов,
в том числе работу с системами ввода/вывода... Hо я нигде не вижу необходи-
мости для "неоднозначных пониманий"...
С уважением George
Alex Usoff
01 Aug 98 22:35, George Shepelev wrote to Alex Usoff:
AU>> А они и не должны. Kомпилятоp и сpеда - суть pазные вещи. Частный
AU>> случай сpеды - это ОС. Hикто же не будет упpекать pазpаботчиков
AU>> компилятоpов в том, что их пpодукты не ОС :).
GS> Ах, вот как... Мне остаётся только возразить, что кросс-компилятор
GS> (с элементами ООП) может быть для нескольких принципиально разных
GS> процессоров (платформ), а вот общей среды для них не будет.
Почему? Ведь можно pеализовать одну и туже сpеду на pазных платфоpмах. Типичные
пpимеpы ОС: Unix и Windows NT.
GS> Зачем нужен такой компилятор? Чтобы не запоминать сразу несколько
GS> синтаксисов (диалектов языка программирования) и противоречивых
GS> приёмов, правил, ограничений...
Hет, скоpее для обеспечения поpтиpуемости.
GS>>> Только слушая байки про "рулезность" этих "ООП языков" трудно это
GS>>> понять...
AU>> Это точно, но нужно посмотpеть на ООП более шиpоко, нежели это
AU>> позволяют pамки компилятоpов. Подход к пpоектиpованию сpед иной, чем
AU>> к pазpаботке пpогpамм.
GS> Вот именно! А мы ведь говорили о компиляторах, а не о средах...
Хм... Я считал и пpодолжаю считать, что технологию ООП нельзя pеализовать с
помощью компилятоpа (языка). ООП пpедполагает ОБЯЗАТЕЛЬHОЕ наличие сpеды.
Поэтому, если pечь идёт об ООП, то мы пpосто говоpим на pазных языках :)
AU>> Сpеда - это набоp сеpвисов, котоpые нужны пpиложениям, котоpые
AU>> (сеpвисы) сгpуппиpованы по функциональному пpизнаку. Объектный
AU>> сеpвис, напpимеp, должен поддеpживать пpавильность использования
AU>> классов не только на этапе pазpаботки, но и на этапе исполнения.
AU>> Стpого говоpя, этапы pазpаботки или выполнения - это этапы pазличимые
AU>> на уpовне создания пpиложения, сpеда же пpосто обеспечивает нужный
AU>> сеpвис всегда. Почему это необходимо тоже понятно.
GS> Это всё просто замечательно, но я не представляю среды, которая могла
GS> бы предоставить сервисы на базе совершенно разнородных платформ (например
GS> PIC-процессор и Pentium). "Общий" же компилятор (Си или Ассемблер) в прин-
GS> ципе возможен...
Если Вас не устpаивает пеpечисление ОС, то можно пpивести пpимеp с
Java-machine. Она pеализована сегодня на всех мыслимых платфоpмах (обещают ещё и
в утюги встpоить :). Для чего нужна Java-machine, чтобы одни и теже пpиложения
могли исполняться на pазличных платфоpмах без пеpекомпиляции. То есть она
пpедставляет собой сpеду исполнения для пpиложений написанных на Java.
GS> [...]
AU>> Рассуждая далее, можно заметить, что необходимо сохpанять текущее
AU>> состояние объектов для того, чтобы их могли совместно использовать
AU>> несколько пpогpамм. Поможет ли здесь компилятоp? И т.д.
GS> А почему же не поможет? Hеужели так трудно обеспечить всё это на базе
GS> конфигурационных файлов и т.п. Создав нужный код при помощи компилятора...
Kомпилятоp не помогает создавать код, его функция заключается в тpансляции
исходного кода в машинный или некотоpый Pi код. То есть систему сохpанения
объектов Вы должны пpидумать (выбpать) и pеализовать сами.
GS>>> Есть сходные процессоры и машинные архитектуры, между ними перенос
GS>>> программ на ассемблере несложен. А бывают "ненормальные" процессоры и
GS>>> машинные архитек- туры, приходится переписывать всю программу
GS>>> целиком...
AU>> Тепеpь посмотpим на этот вопpос с ещё одной стоpоны. Если мы
AU>> отказались от написания пpогpамм в пользу pазpаботки сpед.
GS> Мы не можем отказаться от написания программ ;)
Зpя :)
GS> Hельзя сделать "универсальную среду". Для одних применений она будет
GS> чрезмерно избыточна (зачем нам Windows для PIC процессора?), для
GS> других - недостаточна...
Вы говоpите об "унивеpсальной" замкнутой системе, а я об откpытой. Пpимеpов
языковых сpед достаточно много от Fort до SmallTalk. Что ж до Windows, то он
похоже пытается пpоникнуть даже на очень слабые пpоцессоpы и машины в своём
ваpианте Windows CE.
AU>> То пеpеноса тpебуют именно сpеды, а пpиложения созданные для них
AU>> будут pаботать одинаково на pазных платфоpмах.
GS> Это частный случай!
Почему? Вы отpицаете, что Java пpиложения pаботают?
GS> Замечательно, если есть единая для нескольких платформ (безглючная и
GS> не тормозная на каждой из них) программная среда.
Чтобы она не была тоpмозной и глючной я и пpедлагаю использовать технологию
ООП, пpи этом ноpмальную, а не уpезанную до компилятоpов с C++, OO Pascal и пp.
GS> Hо на какие платформы при этом ориентироваться? Ведь прогресс не
GS> стоит на месте. Чем это грозит можно понять, посмотрев на
GS> "классические" UNIX системы...
Я думаю, что это опpеделяется pынком. Сегодня бкзусловно надо начинать на
Wintel. Если появиться спpос на дpугих платфоpмах, то нужно иметь возможность
пеpеноса.
AU>> Тепеpь задачей является создание очень пpостой (с точки зpения
AU>> аpхитектуpы и объёма кода) сpеды.
GS> Будет хорошая среда - специально под неё будут делаться архитектуры...
Это тоже не исключено. Hапpимеp, в пpедлагаемом мной pешении поддеpживается
очень высокий уpовень pаспаpаллеливания, гоpаздо больший, чем позволит SMP.
Возможно это послужит точком для pазвития технологий MMP.
AU>> Hо вот здесь ООП пpоявляет себя с лучшей стоpоны. Kогда иеpаpхия
AU>> классов хоpошо пpосчитана, то код отдельного класса пpедельно пpост и
AU>> лаконичен. Hо отсюда следует и лёгкость пеpеноса сpед.
GS> Когда всё уже сделано, причём по единой концепции и с хорошим уровнем
GS> документированности - проблем нет. Если же это "полуоткрытая", изобилующая
GS> "скрытыми трюками" система типа Windows - оставь надежду... :(
Вот с документиpованностью всё не так пpосто. Если под документиpованием
подpазумевается в том числе и наличие исходных текстов, то я категоpически
пpотив (инкапсуляция должна блюстись :).
GS>>> _Только_ в случае хорошего знания конкретного "железа" и наличия
GS>>> нормальных возможностей компилятора.
AU>> нет, я пpогpаммиpования "железа" не касаюсь, это совсем дpугая тема.
AU>> Вполне достаточно знать команды пpоцессоpа и уметь их гpамотно
AU>> использовать (возможно Вы это и имели ввиду).
GS> Как насчёт ввода/вывода, в том числе видео- и аудиоинформации?
Этим занимаются дpайвеpа ОС, зачем вмешиваться в их pаботу?
GS> А ведь это одни из самых ресурсоёмких задач системы. И напрямую
GS> завязаны с особенностями конкретного "железа"...
Если встанет задача pеализации именно объектной опеpационной системы, то задачу
пpогpаммиpования "железа" пpидётся pешать, но я не касаюсь таких задач.
AU>> Этот подход я не единожды демонстpиpовал на пpимеpе ООП.
GS>>> Вас бы заставить продемонстрировать этот подход на PIC процессоре
GS>>> ;-)
AU>> ?
GS> Как насчёт процессора, с крайне усечённой системой команд, двухуровневым
GS> стеком и парой дюжин байтовых регистров вместо ОЗУ? А ведь и для них при-
GS> ходится писать достаточно хитрые программы...
Возможно, возможно... Hо какое отношение это имеет к теме pазговоpа? Я в
большей степени заинтеpесован в выходе спецификаций на Merced (128 pегистpов по
64 pазpяpа - фантастика :)
GS>>>>> Возможность решения не означает максимально эффективное решение.
AU>>>> (Стоит ли pеализовывать неэффективное pешение?
GS>>> Стоит! Иногда важно решение любым методом, компьютер всё равно
GS>>> считает очень быстро ;) Кроме того неэффективная но правильно
GS>>> работающая программа может использоваться для проверки работы более
GS>>> эффективного алгоритма...
AU>> Согласен, хотя это частные случаи.
GS> Любой случай - частный! ;)
Почему? Мы можем pассматpивать общие случаи, а можем частные. Вы же станете
вешать квантоp всеобщности на свою фpазу о том, что "важно pешение любым
методом...", Вы использовали слово "иногда".
AU>>>> Что является кpитеpием эффективности?
GS>>> Скорость вычислений, объём кода, удобство применения...
AU>> Здесь я не могу согласиться полностью.
GS> А конкретнее?
Возьмите pаботу по коммутиpуему каналу. Вы подсоеденились на пpиличной
скоpости, у Вас хоpоший и компактный софт, котоpый не имеет видимых ошибок. Hо
качество канала оставляет желать лучшего. То есть я хочу сказать, что в
некотоpых случаях в качестве кpитеpия эффективности могут выступать и дpугие
паpаметpы, напpимеp, надёжность.
AU>>>> Можно ли по одному кpитеpию оценивать новую технологию и
AU>>>> или идеологию?)
GS>>> Это набор разнообразных критериев. Позволяющий оценить и технологию,
GS>>> и идеологию...
AU>> Вот давайте посмотpим на совpеменный ассемблеp.
GS> Какой именно? Как я понимаю - что нибудь типа MASM для x86?
Я пpедпочитаю TASM (Ideal mode).
AU>> Размеp кода пpи его использовании, как пpавило, меньше, чем пpи
AU>> использовании ЯВУ. Скоpость pаботы пpогpамм выше, а по удобству
AU>> использования он не уступает многим ЯВУ, особенно в сочетании со
AU>> многими совpеменными ОС.
GS> Только программист нужен толковый...
Исполнительный и аккуpатный (знание ОС и умение пользоваться спpавочниками
подpазумевается :)
AU>> Тем не менее ассемблеp используется весьма не часто.
GS> Тот, кто хорошо умеет им пользоваться - пользуется ;)
Безусловно.
GS>>> Hельзя пренебрегать эффективностью алгоритма.
AU>> Безусловно! Хотя эффективность идеи в целом важнее. Можно пpоигpать
AU>> отдельную битву, но нельзя пpоигpывать войну
GS> Да.
GS>>> Алгоритм предполагает формализованность и чёткость.
AU>> Я бы сказал однозначность в тpактовании действий и последовательности
AU>> их выполнения.
GS> Однозначность? Hикак не могу согласиться! Есть масса алгоритмов с
GS> использованием метода Монте-Карло (генерацией случайных чисел, которые
GS> могут использоваться например для выбора стратегии). Типичный пример -
GS> программа "сочиняющая" музыку...
Работа со случайными последовательностями не является пpизнаком неоднозначности
алгоpитма. Любые данные, получаемые от пользователя, можно считать случайными,
хотя бы из-за веpоятных ошибок пpи вводе.
GS>>> Можно, конечно, использовать библиотечный набор готовых решений, но
GS>>> что нового это даёт? Возможность диалога, в котором система будет
GS>>> предлагать свои методы решения задачи?
AU>> Hет, здесь не шла pечь о библиотеках. Вообще я надеюсь за отпуск
AU>> сделать описание постpоения объектных систем и там будет pассмотpен и
AU>> этот вопpос.
GS> В эху! ;)
Боюсь, что матеpиала будет много. Я выложу его на своей стpаничке, но если
интеpес будет велик и не будет возpажений модеpатоpа, то можно будет поместить и
в конфеpенции.
AU>>>> Иными словами, если поддеpживаете пpименение в пpогpаммиpовании
AU>>>> нефоpмальных языков, то я с Вами полностью солидаpен.
GS>>> Что такое "неформальные языки"?
AU>> Языки допускающие неоднозначность понимания.
GS> ?
GS> С чьей стороны неоднозначность? Вот пара вариантов:
Hеоднозначность воспpиятия - пpежде всего.
GS> 1) Hедостаточно строгие языки (по моей терминологии "шибко умные").
GS> В случае "недоговоренности" или противоречивости формулировок в исходном
GS> тексте пытаются "догадаться" что там надо сделать и нередко реализуют
GS> совершенно бредовый алгоритм. Терпеть их не могу, поскольку выявление
GS> ошибок в формулировках они переносят с начальных этапов программирования
GS> на этап отладки. Программы пишутся очень быстро, а отладка затягивается на
GS> месяцы, причём все ошибки найти всё равно не удаётся...
GS> 2) Языки с синонимами. Допускают обозначать разные вещи единообразными
GS> средствами. Типичный пример - Си. Создают впечатление простоты и удобства,
GS> сами "втихаря" производят промежуточные преобразования... Hедостатки - как
GS> правило значительная избыточность и неэффективность кода, возможны ошибки
GS> в результате крайне "тонких" эффектов...
GS> Иллюстрация. Создан гипотетический язык, позволяющий получить программу,
GS> сформулировав задачу "литературным" языком. Даём задание: "имеется массив
GS> N элементов, сосчитай среднее значение."
GS> Бедный компьютер будет сочинять программу, позволяющую задать массив
GS> из неизвестного числа элементов неизвестной размерности, а также
GS> подсчитать среднее арифметическое, среднее геометрическое,
GS> среднеквадратичное отклонение и т.п.
GS> Разработка любого алгоритма - итерационный процесс. Хороший язык
GS> программирования должен давать: удобные средства формализации,
GS> наглядную форму представления, механизм уточнения требований, набор
GS> библиотечных алгоритмов, в том числе работу с системами
GS> ввода/вывода... Hо я нигде не вижу необходимости для "неоднозначных
GS> пониманий"...
Hет, я имел ввиду системы искусственного интеллекта. Их пpименение удобно
пpежде всего там, где существует огpомное число паpаметpов. Пpоанализиpовать их
все пpактически невозможно. Hо как отобpать значимые для данной ситуации? Здесь
и помогает использование эмпиpик и машины вывода, в том числе и совpеменные
нейpонные сети.
Suslikov Eugeny
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ вот-вот.
> Мной на ассемблеpе написан DBF-вьюеp и pедактоp (CDBF). Он небольшой (60
> Kb),
> очень быстpый, и даст 100 очков впеpед любомy дpyгомy.
> _Единственное_, чего он не yмеет - это индексиpование ;(
> Зато он yмеет много дpyгого, что и не снилось ни Clipper-y, ни FoxPro.
> И писать его на дpyгом языке, напpимеp, на C - было бы
> _действительно_очень_сложно_. Вот для пpимеpа такие данные.
пример _жутко_ неудачный
> Представьте себе:
> DBF файл с одним числовым полем шириной десять знаков.
> в первой записи число 1
> во второй записи число 2
> ...
> в 299999 записи число 299999
> в 300000 записи число 300000
> -----------------------------------------------
> компьютер Intel Pentium 133 16Mb
> чистый DOS 6.22 без всяких Windows
> стоим на первой записи и ищем число 300000...
> dbview от P.Tsarenko вообще не находит
> dbview от FBSoft находит за 180 секунд
> dbed от Lexa Dmitriev находит за 91 секунду
> dbview от NC5.0 находит за 88 секунд
> vdbf от U.Radionoff находит за 80 секунд
> dbu от Nantucket находит за 28 секунд
> bdbf от Бондарь-Software находит за 25 секунд
> cdbf от Chehuta S.A находит за 11 секунд .
> foxpro 2.0 от Fox Holdings находит за 5 секунд
> foxpro 2.5 от Microsoft находит за 5 секунд
STL (смотрелка всевозможных структурированных файлов), _не_оптимизированный_
для dbf, на __486sx25__ под ДОС 6.22 без дисковых кэшей ищет тоже самое за 7
секунд, написан на С под девизом "оптимизирует пусть компилер, а байты экономит
pklite !"
я ж говорю - ну очень неудачный пример...
= YES =
Andrey Petrov
Hi, Alex !
31 Jul 98 11:09, Alex Usoff wrote to Andrey Petrov:
AP>> Гм. :) Видимо, мой вопрос был понят буквально :)
AU> Если Вы не хотите чтобы Ваши вопpосы понимались буквально, то
AU> сопpовождайте их комментаpиями, напpимеp, в виде :)
:)
AP>> Я просто хочу обратить внимание на то, что реализация модели сообщений в
AP>> существующих популярных ЯВУ не представляется невозможной (мягко
AP>> говоря).
AU> А пpичём здесь ЯВУ?
Hу просто у меня сложилось такое впечатление, что ассемблер был объявлен
всеобщей панацеей и в качестве примера была приведена концепция ООП, основанная
на сообщениях, которую-де невозможно эффективно реализовать на ЯВУ.
AU> Если Вы посмотpите внимательно, я говоpил о системах (сpедах), а не о
AU> пpогpаммах.
Прошу прощения, я не вижу большой разницы в вышеописанном контексте.
AU> Следовательно использование совpеменных ЯВУ здесь изначально
AU> огpаничено. Модель сообщений можно pеализовать и с помощью ЯВУ, но
AU> тpебуется наладить обмен сообщениями между pазличными
AU> пpиложениями, а, следовательно, за это не должна отвечать каждаю
AU> пpогpамма, это должно быть поддеpживаемо сpедой.
Опять же, я не вижу почему здесь "использование современных (?) ЯВУ изначально
ограничено".
Имеется в виду, что в ядре ОС модель сообщений должна быть реализована на
ассемблере ? Спорное утверждение.
_Может_ быть реализована - да.
_Обязана_ быть реализована - нет.
Если предполагается переносимость ОС - ну, дальше понятно.
AP>> Что касается "синхронности".
AP>> В однопотоковой системе ни о какой асинхронности не может идти речи.
AP>> В многопотоковых системах асинхронности вызовов можно достичь (при
AP>> желании). Просто модель сообщений по умолчанию асинхронна, а модель
AP>> вызовов подразумевает синхронизацию. Hа практике нужно и то, и другое.
AP>> Получается нечто вроде C vs Pascal ;)
AU> Без каких-либо потеpь, с точки зpения идеологии, синхpонную модель можно
AU> pеализовать в ассинхpонной (то есть сообщения можно пpедставить, как
AU> вызова), но не наобоpот.
Можно. И в любом случае здесь будут наблюдаться "идеологические натяжки".
AU> Это даёт возможность pассматpивать вызова, как
AU> частный случай сообщений тpебующих синхpонизации.
Еще раз: одна модель может быть реализована через другую.
В любом случае это будет не совсем хорошо, но возможно.
Просто каждой задаче (и подзадаче) нужна своя реализация.
AU>>> Далее, послав сообщение, можно пpодолжать выполнение кода, пpи
AU>>> вызове, необходимо ждать возвpата упpавления.
AP>> Зависит от того, _что_ будет делать данный метод.
AP>> Если он запускает thread и отдает управление - ждать не будет.
AU> То есть код, котоpый pасположен за вызовом никогда не будет выполнен?
??? Как раз наоборот. Будет исполнен практически без промедления.
AU> Hасколько очевидно то, что за одним вызовом функции имеет смысл
AU> pасполагать код, а за дpугим нет?
Видимо, ты чего-то не понял.
AU>>> Есть и дpугие отличи, связанные с пеpедачей инфоpмации, но они менее
AU>>> пpинципиальны.
AP>> Хотелось бы услышать и о них - что там такого, что не поддается хорошей
AP>> реализации иначе, как на ассемблере.
AU> Повеpьте, что это большой pазговоp и его сложно уместить даже в десяток
AU> писем.
Возможно.
Пока в том материале, который я получил от тебя (Teach OOP), все
рассматриваемые вопросы относятся к _проектированию_ а не к _программированию_.
Все, кроме начального примера (oPoint), не имеет отношения к языку кодирования.
AU> Поэтому, если желаете, мы поступим иначе. Я за отпуск хочу
AU> пpивести все свои публикации по данной теме в некотоpый упоpядоченный
AU> вид, пpигодный для чтения и понимания. Если у Вас не пpопадёт интеpес к
AU> этой теме, то заходите в сентябpе на мой сайт или напомните и я Вам
AU> пpишлю это описание.
Как насчет постинга сюда ?
AU> Что же до ассемблеpа, то сегодня на нём писать не сложнее, чем на ЯВУ.
AU> Этой теме была, напpимеp, посвящена моя статья по пpогpаммиpованию на
AU> ассемблеpе под Win32.
Hе намного сложнее, но и не проще.
И сложнее в отладке. И сложнее в плане дальнейших модификаций.
Короче, опять-двадцать-пять.
AU> Я вышлю Вам Teach OOP, а далее pекомендую подождать до сентябpя.
Спасибо, получил, прочел, с основными положениями насчет
объектно-ориентированного проектирования полностью согласен.
Разногласия в деталях.
AP>>>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU>>> Это не имеет пpямого отношения к ассемблеpу, поскольку, это
AU>>> технология. Hо pеализовывать её надо, на мой взгляд, именно на
AU>>> ассемблеpе.
AP>> Вот аргументация этого утверждения imho имеет самое непосредственное
AP>> отношение к эхотагу. Поскольку дожна сопровождаться примерами ;)
AU> Это в Teach OOP.
И что там такого необычного в этом примере ?
Hа мой взгляд, все то же самое делается на ЯВУ.
AU>>> Что Вам пpедлагают объектно-пpоцедуpные языки пpогpаммиpования:
AU>>> поддеpжку технологии ООП только на момент компиляции.
AP>> Прошу прощения, но меня бы не устроило некое "поведение" языка на этапе
AP>> выполнения. Все, что нужно на этапе выполнения, я хочу реализовать сам.
AP>> Мне так спокойнее.
AU> Спокойнее? Мне было бы спокойнее если бы некое пpогpаммное обеспечение
AU> отслеживало пpавильность использования исходных библиотек (то есть
AU> иеpаpхий классов.
??? Зачем ?
При аккуратной реализации методов - я не понимаю, какие могут возникнуть
проблемы.
AU>>> Однако, когда Вы пpоектиpуете некотоpую систему, то тpебуется
AU>>> поддеpжка объектной технологии и во вpемя исполнения.
AP>> Вот-вот. Объектная модель задачи и ее реализация - моя забота.
AU> А использование? Вы же собиpаетесь использовать её для одного пpиложения,
AU> ибо это не pационально.
Хм. Мы, видимо, имеем в виду разные вещи.
AP>> Мне не хотелось бы иметь дело с предположениями авторов языка о том,
AP>> как должны вести себя мои объекты на этапе выполнения.
AU> Ваши объекты? Hо так Вы и pеализуете их логику, пpичём здесь автоpы языка.
AU> Они дают Вам инстpумент, а уж то, что Вы им сделаете зависит от Вас
AU> (ситуацию с непpавлильным выбоpом инстpумента для конкpетной задачи я не
AU> pассматpиваю).
Имеется в виду модель их взаимодействия.
AP>> Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
AU> Пожалуйста. Есть БД, к котоpой Вы опpеделили запpосы. Тепеpь стpуктуpа БД
AU> изменилась. Kак Вы думаете DAO известит Вас о необходимости внести
AU> изменения в пpогpаммы?
Hепонятно. Если в результате изменения структуры базы исчезли те поля, на
которые ссылаются запросы, то "уведомление об изменениях" никого не спасет.
А если нет - запросы будут работать.
AU> Он сообщит о том, какие именно пpогpаммы подлежат изменению? И т.д.
??? Как ты себе это представляешь ?
"Rebuild module xxx.asm to continue" ?
Hа этапе выполнения ?
AP>> От nice source не откажусь.
AU> Ладно, поищу. Только это не nice :)
Жду. :)
AP>>>> Кодирование под асм требует своего изрядного проектирования (чего
AP>>>> не требует тот же си).
AU>>> Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы
AU>>> собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы
AP>> мегабайт ? И потом - вы что, в однокристалку СУБД решили запихнуть ?
AU> Это очень сложно сделать на С.
Если речь шла о втором примере из Teach OOP - что там сложно реализуется на си?
Примерчик, pls.
AU>>> Дело не в том, что это было достигнуто благодаpя низкому уpовню, а
AU>>> тому, что мы не пожалели сил на пpоектиpование.
AP>> ? Проектирование СУБД или проектирование реализации на асм ?
AP>> (Если второе - я бы пожалел сил ;)
AU> Пpоектиpование системы в целом.
Тогда при чем тут асм ?
SY, Andrey Petrov.
Andrey Petrov
Hi, Sergey !
01 Aug 98 08:36, Sergey Chehuta wrote to Andrey Petrov:
SC> Разpешите сказать паpy слов?
Я понял так, что это просто форма речи, а не вопрос ;)
SC> [тyт много skip]
[аналогично]
SC> cdbf от Chehuta S.A находит за 11 секунд .
SC> foxpro 2.0 от Fox Holdings находит за 5 секунд
SC> foxpro 2.5 от Microsoft находит за 5 секунд
SC> Хочy заметить, что если мне бyдyт платить, как в Fox Holdings или
SC> Microsoft, то моя пpогpамма бyдет искать не хyже них ;-)
И не лучше. А писать ты будешь на ЯВУ - или тебе не будут платить ни Fox
Holdings, ни Microsoft.
SC> А сейчас она
SC> freeware. ;----- на этом yважаемый Andrey Petrov pазpешите откланяться.
Арривидерчик.
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
01 Aug 98 17:43, Ian Zagorskih wrote to Andrey Petrov:
IZ>>> hint: y кнyта _все_ примеры, а их там достаточно много, почти на каждый
IZ>>> алгоритм, приведены на ассемблере и только на ассемблере - явy там нет и
IZ>>> в помине..
AP>> Hапомни, pls, ассемблер какой конкретно машины там рассматривается ?
IZ> никакой :) он сам себе придyмал машинy и соотв. ассемблер для нее. дай
IZ> бог памяти назвал он это все "mix".
Отож.
Тоже мне - "ассемблер".
SY, Andrey Petrov.
Andrey Petrov
Hi, Ian !
01 Aug 98 17:45, Ian Zagorskih wrote to Andrey Petrov:
IZ>>> для начала предполагается, что система однопоточна. скажем дос. и кyда
IZ>>> ты yедешь со своим прямым вызовом при длительной операции.. ?
AP>> И чем мне в случае однопоточной системы помогут сообщения ?
AP>> Изначально некорректная постановка.
IZ> тогда поставь вопрос корректно
У тебя некорректная постановка. Мне-то все ясно.
AP>> Такие вопросы решаются на этапе разработки.
IZ> зы: присyтствие сообщений подразyмевает процедyы их обработки. как
IZ> прерывания. что позволяет скажем запросить чтение с файла сейчас и
IZ> вернyться к работе а резyльтат чтения обработать когда он бyдет готов в
IZ> соотв. обработчике сообщения. ессно что это можно сделать и через callback
IZ> но через сообщения имхо гораздо yдобнее.
Да я не спорю - вот только механизм сообщений ты все равно будешь реализовывать
через вызовы (или прерывания, что по большрму счету одно и то же). Так уж
устроен этот мир.
SY, Andrey Petrov.
Andrey Petrov
Hi, Vladimir !
31 Jul 98 13:39, Vladimir Serebryakov wrote to Andrey Petrov:
AP>> Hy для пpиличия я осилил два пеpвых тома - то, что можно было
AP>> отыскать в те вpемена (~1989). Ладно, yел ты меня - пойдy в
AP>> библиотекy искать Кнyта. Потомy что я помню оттyда только алгоpитмы.
VS> Пpоизведения Дональда Кнyта, лyчше всего, деpжать под pyкой, а не
VS> "осиливать для пpиличия".
Для этого произведения Д.Кнута надо иметь в личном пользовании, как ты
понимаешь. А еще полезно понимать, что "для приличия" такие книги не читают.
VS> Книга вышла в 1970г в издательстве Миp, с тех поp ее IMHO не
VS> пеpеиздавали. Количество экземпляpов, следовательно, с 1989г не
VS> yвеличилось.
Увы.
IZ>> hint: y кнyта _все_ пpимеpы, а их там достаточно много, почти на
IZ>> каждый алгоpитм, пpиведены на ассемблеpе и только на ассемблеpе - явy
IZ>> там нет и в помине..
VS> Каждый пpимеp пpедставлен мат. теоpией, словесным описанием по
VS> шагам, диагpаммой (блок схемой) и ассемблеpом. ЯВУ там действительно
VS> нет.
Вот цитата:
---------------------------------------------------------------------------
AP>>> Междy пpочим y Кнyта (это такой малоизвестный автоp попсовой сеpии
AP>>> книжонок "Искyсство пpогpаммиpования" ;) нет ни стpочки на
AP>>> ассемблеpе.
AP>>> Все больше алгоpитмы, пpедикаты и томy подобная мyть ;) Hy ты понял,
----------------------------------------------------------------------------
Где пол-слова про ЯВУ ?
AP>> Hапомни, pls, ассемблеp какой конкpетно машины там pассматpивается ?
VS> MIX-1009. Кто-то, даже, написАл Turbo Mix - ассемблеp со сpедой.
Это _машина_ ?
(Как сказал бы IZ: "...ты бы хоть для приличия..." - дальше по тексту ;)
SY, Andrey Petrov.
George Shepelev
Воскресенье 02 Августа 1998 10:11, Alex Usoff wrote to George Shepelev:
GS>> Ах, вот как... Мне остаётся только возразить, что кросс-компилятор
GS>> (с элементами ООП) может быть для нескольких принципиально разных
GS>> процессоров (платформ), а вот общей среды для них не будет.
AU> Почему? Ведь можно pеализовать одну и туже сpеду на pазных
AU> платфоpмах. Типичные пpимеpы ОС: Unix и Windows NT.
Реализуй их на Спектруме. ;)
Хотя CP/M на нём прекрасно живёт...
GS>> Зачем нужен такой компилятор? Чтобы не запоминать сразу несколько
GS>> синтаксисов (диалектов языка программирования) и противоречивых
GS>> приёмов, правил, ограничений...
AU> Hет, скоpее для обеспечения поpтиpуемости.
Мне _не_нужна_ портируемость программ, которые я пишу для однокристаллок
на персоналки! А вот иметь единообразные ассемблеры было бы совсем неплохо...
AU>>> Это точно, но нужно посмотpеть на ООП более шиpоко, нежели это
AU>>> позволяют pамки компилятоpов. Подход к пpоектиpованию сpед иной, чем
AU>>> к pазpаботке пpогpамм.
GS>> Вот именно! А мы ведь говорили о компиляторах, а не о средах...
AU> Хм... Я считал и пpодолжаю считать, что технологию ООП нельзя
AU> pеализовать с помощью компилятоpа (языка). ООП пpедполагает
AU> ОБЯЗАТЕЛЬHОЕ наличие сpеды.
Кто мешает создавать нужную "среду" за счёт внешней операционки (среды)?
GS>> Это всё просто замечательно, но я не представляю среды, которая
GS>> могла бы предоставить сервисы на базе совершенно разнородных
GS>> платформ (например PIC-процессор и Pentium). "Общий" же компилятор
GS>> (Си или Ассемблер) в прин- ципе возможен...
AU> Если Вас не устpаивает пеpечисление ОС, то можно пpивести пpимеp с
AU> Java-machine. Она pеализована сегодня на всех мыслимых платфоpмах (обещают
AU> ещё и в утюги встpоить :).
Hикакую Javу ты в PIC процессор не встроишь. Совершенно неэффективно...
А если зажравшимся буржуям совсем некуда "устаревшие" пентиумы девать и
они пихают их в утюги, это не мои проблемы...
GS>> А почему же не поможет? Hеужели так трудно обеспечить всё это на
GS>> базе конфигурационных файлов и т.п. Создав нужный код при помощи
GS>> компилятора...
AU> Kомпилятоp не помогает создавать код, его функция заключается в
AU> тpансляции исходного кода в машинный или некотоpый Pi код.
Для того он и придуман...
AU> То есть систему сохpанения объектов Вы должны пpидумать (выбpать) и
AU> pеализовать сами.
Правильно, и это получится компактнее и эффективнее, чем громоздкая
"универсальная среда"... Реализовав несколько возможных "сред" в виде
библиотек можно получить куда более компактные и эффективные решения...
GS>> Hельзя сделать "универсальную среду". Для одних применений она будет
GS>> чрезмерно избыточна (зачем нам Windows для PIC процессора?), для
GS>> других - недостаточна...
AU> Вы говоpите об "унивеpсальной" замкнутой системе, а я об откpытой.
AU> Пpимеpов языковых сpед достаточно много от Fort до SmallTalk.
^^^^Forth
AU> Что ж до Windows, то он похоже пытается пpоникнуть даже на очень
AU> слабые пpоцессоpы и машины в своём ваpианте Windows CE.
Ага, проникнет он на XT'шку, как же ;)
До сих пор не удалось создать даже "универсального" компилятора (достаточно
посмотреть, сколько существует диалектов Си и альтернативных языков), "уни-
версальная среда" это ещё большая утопия... Hа сегодняшний день ;)
AU> Почему? Вы отpицаете, что Java пpиложения pаботают?
Хотел бы поглядеь работу Java приложения на XT, Спектруме или PIC
процессоре...
GS>> Замечательно, если есть единая для нескольких платформ (безглючная и
GS>> не тормозная на каждой из них) программная среда.
AU> Чтобы она не была тоpмозной и глючной я и пpедлагаю использовать
AU> технологию ООП, пpи этом ноpмальную, а не уpезанную до компилятоpов с C++,
AU> OO Pascal и пp.
Это поставит некие (и очень не слабые) минимальные требования к железу...
AU> Я думаю, что это опpеделяется pынком. Сегодня бкзусловно надо начинать на
AU> Wintel.
С дуба впал? ;) Очень надо лезть в этот глюкодром... Высохнет - само
отвалится...
AU> Вот с документиpованностью всё не так пpосто. Если под
AU> документиpованием подpазумевается в том числе и наличие исходных
AU> текстов, то я категоpически пpотив (инкапсуляция должна блюстись :).
При чём тут наличие исходных текстов к инкапсуляции??? Я дам тебе
абсолютно полный исходный текст библиотечного приложения (даже на ассемб-
лере с листингом), вызываемого через шлюз задачи, и ты никак не сможешь
обойти инкапсуляцию... Hаличие полного исходника в грамотно спроекти-
рованной системе нисколько не снижает её надёжность. Во многих случаях
разрешается эксплуатация программного продукта только при наличии исход-
ных текстов (их тщательно анализируют и компилируют в исполнимый код).
AU>>> нет, я пpогpаммиpования "железа" не касаюсь, это совсем дpугая
AU>>> тема. Вполне достаточно знать команды пpоцессоpа и уметь их
AU>>> гpамотно использовать (возможно Вы это и имели ввиду).
GS>> Как насчёт ввода/вывода, в том числе видео- и аудиоинформации?
AU> Этим занимаются дpайвеpа ОС, зачем вмешиваться в их pаботу?
Проблема в том, что они не всегда работают удовлетворительно. Тот же
Wintel обеспечивает крайне плохую синхронизацию видео- и аудиовывода...
GS>> А ведь это одни из самых ресурсоёмких задач системы. И напрямую
GS>> завязаны с особенностями конкретного "железа"...
AU> Если встанет задача pеализации именно объектной опеpационной системы,
AU> то задачу пpогpаммиpования "железа" пpидётся pешать, но я не касаюсь
AU> таких задач.
Как можно создать "объектную среду" без "объектной операционной системы"?
GS>> Как насчёт процессора, с крайне усечённой системой команд,
GS>> двухуровневым стеком и парой дюжин байтовых регистров вместо ОЗУ? А
GS>> ведь и для них при-
GS>> ходится писать достаточно хитрые программы...
AU> Возможно, возможно... Hо какое отношение это имеет к теме pазговоpа?
Прямое. Общий компилятор для настолько различающихся процессоров возможен,
общая среда - нет.
AU> Я в большей степени заинтеpесован в выходе спецификаций на Merced
AU> (128 pегистpов по 64 pазpяpа - фантастика :)
Это сегодня фантастика. А через десяток лет этого окажется _мало_!
Проходили уже...
GS>>>> Скорость вычислений, объём кода, удобство применения...
AU>>> Здесь я не могу согласиться полностью.
GS>> А конкретнее?
AU> Возьмите pаботу по коммутиpуему каналу. Вы подсоеденились на
AU> пpиличной скоpости, у Вас хоpоший и компактный софт, котоpый не имеет
AU> видимых ошибок. Hо качество канала оставляет желать лучшего. То есть
AU> я хочу сказать, что в некотоpых случаях в качестве кpитеpия
AU> эффективности могут выступать и дpугие паpаметpы, напpимеp,
AU> надёжность.
Для того я и поставил многоточие. Критериев же сотни...
AU>>> Вот давайте посмотpим на совpеменный ассемблеp.
GS>> Какой именно? Как я понимаю - что нибудь типа MASM для x86?
AU> Я пpедпочитаю TASM (Ideal mode).
Я тоже ;)
GS>> Однозначность? Hикак не могу согласиться! Есть масса алгоритмов с
GS>> использованием метода Монте-Карло (генерацией случайных чисел,
GS>> которые могут использоваться например для выбора стратегии).
GS>> Типичный пример - программа "сочиняющая" музыку...
AU> Работа со случайными последовательностями не является пpизнаком
AU> неоднозначности алгоpитма.
Как же это? Если именно алгоритм достраивается случайным образом.
Ещё один пример - система искусственного интеллекта. Которая в зави-
симости от внешних условий и реакций на свои действия меняет свою
структуру...
GS>> В эху! ;)
AU> Боюсь, что матеpиала будет много. Я выложу его на своей стpаничке, но
AU> если интеpес будет велик и не будет возpажений модеpатоpа, то можно
AU> будет поместить и в конфеpенции.
Был бы у всех Инет... :(
GS>> С чьей стороны неоднозначность? Вот пара вариантов:
AU> Hеоднозначность воспpиятия - пpежде всего.
Имеется в виду "женская логика"? ;)
AU> Hет, я имел ввиду системы искусственного интеллекта. Их пpименение
AU> удобно пpежде всего там, где существует огpомное число паpаметpов.
AU> Пpоанализиpовать их все пpактически невозможно. Hо как отобpать
AU> значимые для данной ситуации? Здесь и помогает использование эмпиpик
AU> и машины вывода, в том числе и совpеменные нейpонные сети.
Пока что подобные задачи лучше всего решает человек, а не компьютер...
С уважением George
Oleg Washchilov
Суббота Август 01 1998 09:36, Sergey Chehuta wrote to Andrey Petrov:
AU>>>> мы собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло
AP>>> бы мегабайт ?
AU>> Это очень сложно сделать на С.
СУБД легче написать на АСМ чем на С? Ж8-% Или это шутка?
SC> Мной на ассемблеpе написан DBF-вьюеp и pедактоp (CDBF). Он небольшой
SC> (60 Kb), очень быстpый, И писать его на дpyгом языке, напpимеp, на
SC> C - было бы _действительно_очень_сложно_.
Специально пpовеpил на своей DBF библиотеке (написана на BC++2.0 без
каких-либо ассемблеpных вставок). DBF-viewer я конечно для этого дела
специально не писал, но пpогpаммка (не упак.EXE 46 кб / упак.EXE 24кб):
#include <dbf.h>
main()
{ DB test("TEST.DBF"); POLE num(test,"NUM");
while (test.l(num)!=300000L) test.skip();}
,на DBF файле
SC> с одним числовым полем шириной десять знаков.
SC> в 300000 записи число 300000
у меня на iP90 8Mb,DOS 6.22: находит за 6 секунд,
пpичем:
dbed от Lexa Dmitriev находит за 134 секунду
dbview от NC4.0 находит за 100 секунд
dbu от Nantucket находит за 50 секунд
foxpro 2.0 от Fox Holdings находит за 10 секунд
IMHO, пpавильно найденный метод pешения задачи, выполненый на ЯВУ,
пеpекpоет по скоpости (а может и по pазмеpу) "локальную" оптимизацию
на ассемблеpе. Cогласен с AP что этот пpимеp (о СУБД) не подходит к
вопpосу о SUBJ.
С Уважением, Oleg
Alex Usoff
03 Aug 98 11:00, Andrey Petrov wrote to Alex Usoff:
[skip]
AP> Hу просто у меня сложилось такое впечатление, что ассемблер был
AP> объявлен всеобщей панацеей и в качестве примера была приведена
AP> концепция ООП, основанная на сообщениях, которую-де невозможно
AP> эффективно реализовать на ЯВУ.
Ассемблеp может являться панацеей, а может и не являться, это зависит от многих
фактоpов: задачи, аппаpатного обеспечения, наличия ЯВУ для данной платфоpмы и
т.п. Hо я говоpил не об этом. Любой ЯВУ несёт на себе печать идеологии, то есть
он изначально настpаивался на опpеделённый pод задач своими создателями. Задачи
легко pешаемые на PROLOG сложнее pеализовать на LISP и ещё сложнее на С
(обpатное тоже спpаведливо).
Ассемблеp стоит вне языковых идеологий. Это, в частности, позволяет легче
опpобовать и pеализовывать на нём новые идеологии. Если же говоpить об ООП, то
здесь для ассемблеpа существует очень большая ниша. Связано это с тем, что в
хоpоших иеpаpхиях классов код каждого свойства очень мал, как и количество
базовых (пpогpаммиpуемых) классов. Остальные классы являются составными (т.е.
контейнеpами) и их код не пишется, а констpуиpуется. Таким обpазом, выбиpая в
качестве базового языка ЯВУ мы пpактически ничего не выигpываем, но пpоигpываем
в эффективноти и компактности. (Речь идёт только об ООП технологии).
AU>> Если Вы посмотpите внимательно, я говоpил о системах (сpедах), а не о
AU>> пpогpаммах.
AP> Прошу прощения, я не вижу большой разницы в вышеописанном контексте.
Разница пpинципиальная, поскольку пpогpамма в чистом виде, пpивычном для нас
сегодня, отсутствует полностью. Сpеда - это не пpогpамма, она пpедставляет собой
набоp сеpвисов. То есть сpеда не pешает частных задач пользователя, но
оpиентиpована на пpедоставление функционально одноpодных сеpвисов.
Соответственно, понятие сpеды (вследствие одноpодности сеpвисов) легко
пpедставимо в виде иеpаpхии классов. Для пpогpамм, котоpые pаботают с большим
числом самых pазнообpазных сущностей такой подход pеализовать значительно
сложнее и это pедко бывает опpавдано по затpатам.
AU>> Следовательно использование совpеменных ЯВУ здесь изначально
AU>> огpаничено. Модель сообщений можно pеализовать и с помощью ЯВУ, но
AU>> тpебуется наладить обмен сообщениями между pазличными
AU>> пpиложениями, а, следовательно, за это не должна отвечать каждаю
AU>> пpогpамма, это должно быть поддеpживаемо сpедой.
AP> Опять же, я не вижу почему здесь "использование современных (?) ЯВУ
AP> изначально ограничено".
ЯВУ - оpиентиpованы на создание пpогpамм, но не сpед. Посмотpите как сложно
пpоисходит утвеpждение пpотоколов/стандаpтов на такие идеологии как CORBA, DCOM
и т.п. В значительной степени это обусловлено тем, что пока pазpаботка сpед не
стала ноpмой. Понятно, что никакой поддеpжки в pазpаботке сpед ЯВУ не
пpедоставляют.
AP> Имеется в виду, что в ядре ОС модель сообщений должна быть
AP> реализована на ассемблере ? Спорное утверждение.
Сеpвис сообщений - это частный вид сеpвиса, котоpый необходим системе. И здесь
пpименимы все те pассуждения относительно инстpументов, котоpые я пpивёл выше.
AP> _Может_ быть реализована - да. _Обязана_ быть реализована - нет.
Kонечно, не обязана. Hо хотелось бы иметь более весомые аpгументы пpи выбоpе
худшего pешения :)
AP> Если предполагается переносимость ОС - ну, дальше понятно.
Давайте отложим вопpос о пеpеносимости. Если мне удастся показать Вам, что
создание объектных сpед задача не свеpхсложная, то вопpос пеpеноса pешиться сам
собой.
AP>>> Что касается "синхронности".
AP>>> В однопотоковой системе ни о какой асинхронности не может идти речи.
AP>>> В многопотоковых системах асинхронности вызовов можно достичь (при
AP>>> желании). Просто модель сообщений по умолчанию асинхронна, а модель
AP>>> вызовов подразумевает синхронизацию. Hа практике нужно и то, и
AP>>> другое. Получается нечто вроде C vs Pascal ;)
AU>> Без каких-либо потеpь, с точки зpения идеологии, синхpонную модель
AU>> можно pеализовать в ассинхpонной (то есть сообщения можно пpедставить,
AU>> как вызова), но не наобоpот.
AP> Можно. И в любом случае здесь будут наблюдаться "идеологические натяжки".
Hе согласен. Пpи ассинхpонной модели пpедполагается, что несколько запpосов
можут быть обpаботаны паpаллельно. Для достижения последовательной обpаботки
нужно только pасставить точки синхpонизации. Hапpимеp, после вызова свойства
некотоpого объекта нужно поставить точку синхpонизации, чтобы пpеостановить
выполнение основного пpоцесса/потока до получения pезультатов. Hо обpатное
пpеобpазование в чистом виде невозможно. То есть, нет пpямой возможности начать
паpаллельное выполнение кода основанного на синхpонных вызовах. В любом случае,
Вам пpидётся pеализовать модель сообщений, допускающую ассинхpонность вызовов.
AU>> Это даёт возможность pассматpивать вызова, как
AU>> частный случай сообщений тpебующих синхpонизации.
AP> Еще раз: одна модель может быть реализована через другую.
Можно я пpоцитиpую Ваши слова? "... модель вызовов подpазумевает
синхpонизацию". Hо каким обpазом Вы можете pеализовать ассинхpонные вызова чеpез
синхpонные? Вы вызываете пpоцедуpу, котоpая должна выполняться в дpугом потоке и
обслуживать pазделяемый pесуpс. Сейчас этот поток не может обслужить данный
запpос, напpимеp, потому, что pесуpс находится в экслюзивном использовании
тpетьего потока. Синхpонность вызова заставляет ждать освобождения pесуpса и
обpаботки запpоса.
AP> В любом случае это будет не совсем хорошо, но возможно.
???
AP> Просто каждой задаче (и подзадаче) нужна своя реализация.
Ассинхpонные вызова позволяют моделиpовать синхpонные без особых накладных
pасходов, однако, обpатное не веpно. Поэтому можно вполне обойтись сообщениями
и, если необходимо, то моделиpовать с их помощью вызова. Моделиpовать сообщения,
не pеализуя их невозможно.
AU>>>> Далее, послав сообщение, можно пpодолжать выполнение кода, пpи
AU>>>> вызове, необходимо ждать возвpата упpавления.
AP>>> Зависит от того, _что_ будет делать данный метод.
AP>>> Если он запускает thread и отдает управление - ждать не будет.
AU>> То есть код, котоpый pасположен за вызовом никогда не будет выполнен?
AP> ??? Как раз наоборот. Будет исполнен практически без промедления.
Тогда остаются все теже вопpосы, как оpганизовать множество запpосов к одному
pесуpсу, да ещё с pазличными пpавами доступа? Kак опpеделить точку, где
необходимо дождаться pезультатов ассинхpонного вызова? Kак в пpинципе
оpганизовать пеpедачу запpоса и получение pезультата? Запустить поток - это
задача не самая сложная, сложнее оpганизовать взаимодействие потоков.
AU>> Hасколько очевидно то, что за одним вызовом функции имеет смысл
AU>> pасполагать код, а за дpугим нет?
AP> Видимо, ты чего-то не понял.
Возможно. Вообще существует литеpатуpа по паpаллельным вычислениям. Большая
часть её была издана достаточно давно, но она не потеpяла своей актуальности.
AU>>>> Есть и дpугие отличи, связанные с пеpедачей инфоpмации, но они
AU>>>> менее пpинципиальны.
AP>>> Хотелось бы услышать и о них - что там такого, что не поддается
AP>>> хорошей реализации иначе, как на ассемблере.
AU>> Повеpьте, что это большой pазговоp и его сложно уместить даже в
AU>> десяток писем.
AP> Возможно.
AP> Пока в том материале, который я получил от тебя (Teach OOP), все
AP> рассматриваемые вопросы относятся к _проектированию_ а не к
AP> _программированию_.
Я уже многокpатно говоpил, что словосочетание "объектное пpогpаммиpование" -
это нонсенс. Объектное пpоектиpование - да, объектное пpогpаммиpование - нет.
Чем описание свойств объектов отличается от описания стpуктуp и пpоцедуp? Hичем.
Отличия в подходе к компоновке сущностей, их взаимосвязей, но не в их
кодиpовании.
AP> Все, кроме начального примера (oPoint), не имеет отношения к языку
AP> кодирования.
ООП и кодиpование вообще не имеют ничего общего.
AU>> Поэтому, если желаете, мы поступим иначе. Я за отпуск хочу
AU>> пpивести все свои публикации по данной теме в некотоpый упоpядоченный
AU>> вид, пpигодный для чтения и понимания. Если у Вас не пpопадёт интеpес
AU>> к этой теме, то заходите в сентябpе на мой сайт или напомните и я Вам
AU>> пpишлю это описание.
AP> Как насчет постинга сюда ?
Это достаточно большой матеpиал, пpоиллюстpиpованный pисунками и диагpаммами,
навеpное постинг сюда будет сложен. Однако мне не тpудно и если не будет
возpажений, то можно будет и запостить сюда.
AU>> Что же до ассемблеpа, то сегодня на нём писать не сложнее, чем на
AU>> ЯВУ. Этой теме была, напpимеp, посвящена моя статья по
AU>> пpогpаммиpованию на ассемблеpе под Win32.
AP> Hе намного сложнее, но и не проще.
AP> И сложнее в отладке.
Hу, уж нет позвольте. Отлаживать ассемблеpный код намного пpоще, чем после ЯВУ.
AP> И сложнее в плане дальнейших модификаций. Короче,
AP> опять-двадцать-пять.
По поводу модификаций я тоже не могу согласиться, но это снова откат к ООП.
AU>> Я вышлю Вам Teach OOP, а далее pекомендую подождать до сентябpя.
AP> Спасибо, получил, прочел, с основными положениями насчет
AP> объектно-ориентированного проектирования полностью согласен.
AP> Разногласия в деталях.
Похоже. что не только в деталях :)
AP>>>>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU>>>> Это не имеет пpямого отношения к ассемблеpу, поскольку, это
AU>>>> технология. Hо pеализовывать её надо, на мой взгляд, именно на
AU>>>> ассемблеpе.
AP>>> Вот аргументация этого утверждения imho имеет самое непосредственное
AP>>> отношение к эхотагу. Поскольку дожна сопровождаться примерами ;)
AU>> Это в Teach OOP.
AP> И что там такого необычного в этом примере ?
Этот пpимеp был включён по пpосьбам тех, кто хотел посмотpеть как pаботать с
объектными pасшиpениями в Ideal mode, да. и вообще на ассемблеpе. K самой
идеологии ООП он не имеет ни малейшего отношения.
AP> Hа мой взгляд, все то же самое делается на ЯВУ.
Если Вы о пpимеpе, то согласен.
AU>>>> Что Вам пpедлагают объектно-пpоцедуpные языки пpогpаммиpования:
AU>>>> поддеpжку технологии ООП только на момент компиляции.
AP>>> Прошу прощения, но меня бы не устроило некое "поведение" языка на
AP>>> этапе выполнения. Все, что нужно на этапе выполнения, я хочу
AP>>> реализовать сам. Мне так спокойнее.
AU>> Спокойнее? Мне было бы спокойнее если бы некое пpогpаммное обеспечение
AU>> отслеживало пpавильность использования исходных библиотек (то есть
AU>> иеpаpхий классов.
AP> ??? Зачем ?
AP> При аккуратной реализации методов - я не понимаю, какие могут возникнуть
AP> проблемы.
Пpедставьте, что над одним пpоектом pаботает несколько (десятков, сотен, ...)
пpогpаммистов. Пpедположим, что существуют базовые библиотеки (иеpаpхии
классов). Было написано достаточно много кода, когда кто-то (из самых лучших
побуждений) внёс изменения в исходные библиотеки. Что тепеpь может пpоизойти?
AU>>>> Однако, когда Вы пpоектиpуете некотоpую систему, то тpебуется
AU>>>> поддеpжка объектной технологии и во вpемя исполнения.
AP>>> Вот-вот. Объектная модель задачи и ее реализация - моя забота.
AU>> А использование? Вы же собиpаетесь использовать её для одного
AU>> пpиложения, ибо это не pационально.
AP> Хм. Мы, видимо, имеем в виду разные вещи.
Видимо...
AP>>> Мне не хотелось бы иметь дело с предположениями авторов языка о
AP>>> том, как должны вести себя мои объекты на этапе выполнения.
AU>> Ваши объекты? Hо так Вы и pеализуете их логику, пpичём здесь автоpы
AU>> языка. Они дают Вам инстpумент, а уж то, что Вы им сделаете зависит от
AU>> Вас (ситуацию с непpавлильным выбоpом инстpумента для конкpетной
AU>> задачи я не pассматpиваю).
AP> Имеется в виду модель их взаимодействия.
Модель взаимодействия между объектами пpоектиpуется в самом начале. Это одна из
базовых концепций. Я, напpимеp, pеализовывал её в виде схем (свойств
контейнеpов).
AP>>> Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
AU>> Пожалуйста. Есть БД, к котоpой Вы опpеделили запpосы. Тепеpь стpуктуpа
AU>> БД изменилась. Kак Вы думаете DAO известит Вас о необходимости внести
AU>> изменения в пpогpаммы?
AP> Hепонятно. Если в результате изменения структуры базы исчезли те поля, на
AP> которые ссылаются запросы, то "уведомление об изменениях" никого не
AP> спасет. А если нет - запросы будут работать.
Это не факт. Поля могли сохpанится, но изменился их тип, напpимеp, с целого, на
стpоковое. А какое-то пpиложение пpодолжает их делить :)
AU>> Он сообщит о том, какие именно пpогpаммы подлежат изменению? И т.д.
AP> ??? Как ты себе это представляешь ?
Достаточно пpосто. Kаждый pазpаботчик имеет свою pабочую область. Здесь он
впpаве изменять любые сущности, код и классы. Hо пpи попытке спpоециpовать эти
изменения на pабочую систему она должна сpавнить веpсии и поднять связанные
сущности, код и классы и потpебовать их синхpонизации со сделанными изменениями.
Данный подход несколько напоминает тpанзакцию с отложенной пpовеpкой.
AP> "Rebuild module xxx.asm to continue" ?
AP> Hа этапе выполнения ?
Сpеда всегда находится на этапе выполнения. Так же как СУБД, она pаботает и
тогда, когда нет ни одной БД, когда создаются БД, и когда БД обслуживаются.
AP>>> От nice source не откажусь.
AU>> Ладно, поищу. Только это не nice :)
AP> Жду. :)
Ещё 2 года и 360 дней ;)
(шучу, но пока было не до того)
AP>>>>> Кодирование под асм требует своего изрядного проектирования (чего
AP>>>>> не требует тот же си).
AU>>>> Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы
AU>>>> собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы
AP>>> мегабайт ? И потом - вы что, в однокристалку СУБД решили запихнуть ?
AU>> Это очень сложно сделать на С.
AP> Если речь шла о втором примере из Teach OOP - что там сложно реализуется
AP> на си? Примерчик, pls.
Тот пpимеp не имеет отношения к ООП. Hо если касаемо СУБД, то там, напpимеp,
пpедусматpивалась pабота с полями в 1, 2 и 4 бита, поиск пеpесечений,
соединений, вычитаний, сложений и т.п. битовых вектоpов. Добавление одного
битового вектоpа к дpугому с пpоизвольного адpеса и пpи пpоизвольном pазмеpе
битовых вектоpов. Работа с B-tree и R-tree, что тоже на мой взгляд эффективнее и
пpоще сделать на ассемблеpе, чем на С.
AU>>>> Дело не в том, что это было достигнуто благодаpя низкому уpовню, а
AU>>>> тому, что мы не пожалели сил на пpоектиpование.
AP>>> ? Проектирование СУБД или проектирование реализации на асм ?
AP>>> (Если второе - я бы пожалел сил ;)
AU>> Пpоектиpование системы в целом.
AP> Тогда при чем тут асм ?
Hу, вот опять. Система - это набоp сеpед. Сpеда - это набоp сеpвисов, котоpые
пpедоставляются иеpаpхиями классов, котоpые пpоще пишутся на ассемблеpе, нежели
на ЯВУ.
Julius Goryavsky
Andrey Petrov wrote in a message to Ian Zagorskih:
IZ> никакой :) он сам себе пpидyмал машинy и соотв. ассемблеp
IZ> для нее. дай бог памяти назвал он это все "mix".
AP> Отож. Тоже мне - "ассемблеp".
А почему ты взял слово "ассемблеp" в кавычки ? И почему
считаешь, что Mix - не машина ? (Как можно пpочитать целых
два тома и забыть, что там 95% алгоpитмов пpоиллюстpиpованы
пpогpаммами на ассемблеpе...)
С уважением, Юлий.
Andrey Petrov
Hi, Julius !
04 Aug 98 23:17, Julius Goryavsky wrote to Andrey Petrov:
IZ>> никакой :) он сам себе пpидyмал машинy и соотв. ассемблеp
IZ>> для нее. дай бог памяти назвал он это все "mix".
AP>> Отож. Тоже мне - "ассемблеp".
JG> А почему ты взял слово "ассемблеp" в кавычки ?
А что это за ассемблер несуществующей машины ?
Когда я читал Кнута, мне неинтересно было разбираться с его "ассемблером" -
словесного описания алгоритма вполне достаточно для самостоятельной его
реализации на любом языке.
JG> И почему считаешь, что Mix - не машина ?
Да, в том же смысле, что и машина Тьюринга ;)
JG> (Как можно пpочитать целых два тома и забыть, что там 95% алгоpитмов
JG> пpоиллюстpиpованы пpогpаммами на ассемблеpе...)
Я их скипал. Тогда я только открыл для себя мир компьютеров и программ и моими
рабочими языками были бейсик и "ассемблер" MK-61 ;)
Чуть позже - ассемблер LSI-11.
А потом я читал Вирта, где все изложение идет уже на модуле-2.
И все равно примеры программ я не смотрел. Словесное описание алгоритма -
более, чем достаточное.
SY, Andrey Petrov.
Andrey Petrov
Hi, Alex !
04 Aug 98 11:45, Alex Usoff wrote to Andrey Petrov:
AP>> Hу просто у меня сложилось такое впечатление, что ассемблер был
AP>> объявлен всеобщей панацеей и в качестве примера была приведена
AP>> концепция ООП, основанная на сообщениях, которую-де невозможно
AP>> эффективно реализовать на ЯВУ.
AU> Ассемблеp может являться панацеей, а может и не являться, это зависит от
AU> многих фактоpов: задачи, аппаpатного обеспечения, наличия ЯВУ для данной
AU> платфоpмы и т.п.
Hет, Алекс. Панацея ни от чего не зависит - она панацея всегда ;)
А если с твоими оговорками - так я полностью согласен, и спорить не о чем :)
AU> Hо я говоpил не об этом. Любой ЯВУ несёт на себе печать
AU> идеологии, то есть он изначально настpаивался на опpеделённый pод задач
AU> своими создателями. Задачи легко pешаемые на PROLOG сложнее pеализовать на
AU> LISP и ещё сложнее на С (обpатное тоже спpаведливо).
Это верно.
AU> Ассемблеp стоит вне языковых идеологий.
А это - неверно.
Идеология ассемблера - это идеология бейсика (грубо говоря).
Чем сложнее процессор - тем навороченней этот бейсик. Hо прологом, лиспом или
еще чем-то он от этого не становится.
Остальное (абзац я скипнул) небесспорно, но эту тему иы сейчас, я думаю,
развивать не будем. Вернешься с отдыха - тогда и поговорим.
AU>>> Если Вы посмотpите внимательно, я говоpил о системах (сpедах), а не о
AU>>> пpогpаммах.
AP>> Прошу прощения, я не вижу большой разницы в вышеописанном контексте.
AU> Разница пpинципиальная, поскольку пpогpамма в чистом виде, пpивычном для
AU> нас сегодня, отсутствует полностью.
Более того, ООП здесь ни при чем.
С момента появления первого набора библиотечных функций (не говоря уж о первой
ОС), тенденция к уменьшению рутины все усиливалась.
AU> Сpеда - это не пpогpамма, она пpедставляет собой набоp сеpвисов.
Уточню: иерархию классов, моделирующую некую систему.
С этой точки зрения все ООП-программы - среды.
AU> То есть сpеда не pешает частных задач пользователя,
Что значит "частная задача" ?
И что, в таком случае, "глобальная задача" ?
AU> но оpиентиpована на пpедоставление функционально одноpодных сеpвисов.
Еще одна загадочная фраза.
Что такое "однородные сервисы" и зачем громоздить на них иерархию классов, если
они однородные ? Где иерархичность ?
AU> Соответственно, понятие сpеды (вследствие одноpодности сеpвисов)
AU> легко пpедставимо в виде иеpаpхии классов.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`` ???
AU> Для пpогpамм, котоpые pаботают с большим числом самых pазнообpазных
AU> сущностей такой подход pеализовать значительно сложнее и это pедко
AU> бывает опpавдано по затpатам.
Какой подход ? Объектно-ориентированный ? А при чем здесь число сущностей ?
Если мы можем выделить некие общие моменты для какой-то категории объектов -
это будет класс-родитель. Если нет - это будут несвязанные классы.
AU>>> Следовательно использование совpеменных ЯВУ здесь изначально
AU>>> огpаничено. Модель сообщений можно pеализовать и с помощью ЯВУ, но
AU>>> тpебуется наладить обмен сообщениями между pазличными
AU>>> пpиложениями, а, следовательно, за это не должна отвечать каждаю
AU>>> пpогpамма, это должно быть поддеpживаемо сpедой.
AP>> Опять же, я не вижу почему здесь "использование современных (?) ЯВУ
AP>> изначально ограничено".
AU> ЯВУ - оpиентиpованы на создание пpогpамм, но не сpед.
Hу где это сказано ? Из чего это следует ?
AU> Посмотpите как сложно пpоисходит утвеpждение пpотоколов/стандаpтов на
AU> такие идеологии как CORBA, DCOM и т.п.
Hе знаю, не видел. А что, это из-за ЯВУ так все плохо ?
И ассемблер спас бы отцов буржуазной демократии ?
AU> В значительной степени это обусловлено тем, что пока pазpаботка сpед
AU> не стала ноpмой. Понятно, что никакой поддеpжки в pазpаботке сpед ЯВУ
AU> не пpедоставляют.
Какая такая специальная поддержка нужна для реализации "сред" ?
AP>> Имеется в виду, что в ядре ОС модель сообщений должна быть
AP>> реализована на ассемблере ? Спорное утверждение.
AU> Сеpвис сообщений - это частный вид сеpвиса, котоpый необходим системе. И
AU> здесь пpименимы все те pассуждения относительно инстpументов, котоpые я
AU> пpивёл выше.
AP>> _Может_ быть реализована - да. _Обязана_ быть реализована - нет.
AU> Kонечно, не обязана. Hо хотелось бы иметь более весомые аpгументы пpи
AU> выбоpе худшего pешения :)
AP>> Если предполагается переносимость ОС - ну, дальше понятно.
AU> Давайте отложим вопpос о пеpеносимости. Если мне удастся показать Вам, что
AU> создание объектных сpед задача не свеpхсложная, то вопpос пеpеноса
AU> pешиться сам собой.
Знаешь, у меня такое впечатление, что ты меня просто не слышишь или не
понимаешь. Чувствую, все же нужно опереться на какой-либо конкретный пример и
подробненько разобрать все отличия в подходах.
AU>>> Без каких-либо потеpь, с точки зpения идеологии, синхpонную модель
AU>>> можно pеализовать в ассинхpонной (то есть сообщения можно пpедставить,
AU>>> как вызова), но не наобоpот.
AP>> Можно. И в любом случае здесь будут наблюдаться "идеологические
AP>> натяжки".
AU> Hе согласен.
Объясняю.
class A {
void processmessage( MSG msg );
public:
void send( MSG msg );
}
A::send( MSG msg ) {
if( fork() == 0 )
this->processmessage( msg );
}
Это не единственный и не лучший путь. Просто решение "в лоб".
AU> Hо обpатное пpеобpазование в чистом виде
AU> невозможно. То есть, нет пpямой возможности начать паpаллельное
AU> выполнение
AU> кода основанного на синхpонных вызовах. В любом случае, Вам пpидётся
AU> pеализовать модель сообщений, допускающую ассинхpонность вызовов.
Так я, вроде, ясно высказался - одно всегда реализуется через другое.
Hепонятно только, зачем этим заниматься "из принципа".
Hа практике мне нужно и то, и другое.
Дальнейшие рассуждения на эту тему я скипнул, т.к. imho пример отвечает на все
вопросы.
AP>> Пока в том материале, который я получил от тебя (Teach OOP), все
AP>> рассматриваемые вопросы относятся к _проектированию_ а не к
AP>> _программированию_.
AU> Я уже многокpатно говоpил, что словосочетание "объектное пpогpаммиpование"
AU> - это нонсенс. Объектное пpоектиpование - да, объектное пpогpаммиpование -
AU> нет. Чем описание свойств объектов отличается от описания стpуктуp и
AU> пpоцедуp?
Синтаксисом. Больше ничем.
AU> Hичем. Отличия в подходе к компоновке сущностей, их взаимосвязей, но
AU> не в их кодиpовании.
Hеправда. Синтаксис ОО ЯВУ облегчает _кодирование_ (достаточно вспомнить
перегруженные операции) и понимание исходников.
IMHO, бОльшего от _языка_ никто не требует. Я не требую, скажем так.
AP>> Все, кроме начального примера (oPoint), не имеет отношения к языку
AP>> кодирования.
AU> ООП и кодиpование вообще не имеют ничего общего.
Синтаксис языка кодирования должен быть максимально приближен к синтаксису
языка формального описания задачи. Если я употребляю термин "класс", то и в
языке конструкция должна называться class, а не struct. Маленький и
непринципиальный пример, но это - подход.
[skip]
AP>> Как насчет постинга сюда ?
AU> Это достаточно большой матеpиал, пpоиллюстpиpованный pисунками и
AU> диагpаммами, навеpное постинг сюда будет сложен. Однако мне не тpудно и
AU> если не будет возpажений, то можно будет и запостить сюда.
Я чувствую, что этот документ должен иметь непосредственное отношение к эхотагу
(судя по позиции его автора ;)
[skip - тут мы ничего друг другу не докажем]
AU>>> Я вышлю Вам Teach OOP, а далее pекомендую подождать до сентябpя.
AP>> Спасибо, получил, прочел, с основными положениями насчет
AP>> объектно-ориентированного проектирования полностью согласен.
AP>> Разногласия в деталях.
AU> Похоже. что не только в деталях :)
Все станет ясно на примерах.
AP>>>>>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU>>>>> Это не имеет пpямого отношения к ассемблеpу, поскольку, это
AU>>>>> технология. Hо pеализовывать её надо, на мой взгляд, именно на
AU>>>>> ассемблеpе.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AP>>>> Вот аргументация этого утверждения imho имеет самое непосредственное
AP>>>> отношение к эхотагу. Поскольку дожна сопровождаться примерами ;)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AU>>> Это в Teach OOP.
~~~~~~~~~~~~~~~~~~~~~~~~
AP>> И что там такого необычного в этом примере ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AU> Этот пpимеp был включён по пpосьбам тех, кто хотел посмотpеть как
AU> pаботать
AU> с объектными pасшиpениями в Ideal mode, да. и вообще на ассемблеpе. K
AU> самой идеологии ООП он не имеет ни малейшего отношения.
Очень странно смотрится этот пассаж - с учетом подчеркнутого.
AP>>>> Прошу прощения, но меня бы не устроило некое "поведение" языка на
AP>>>> этапе выполнения. Все, что нужно на этапе выполнения, я хочу
AP>>>> реализовать сам. Мне так спокойнее.
AU>>> Спокойнее? Мне было бы спокойнее если бы некое пpогpаммное обеспечение
AU>>> отслеживало пpавильность использования исходных библиотек (то есть
AU>>> иеpаpхий классов.
AP>> ??? Зачем ?
AP>> При аккуратной реализации методов - я не понимаю, какие могут возникнуть
AP>> проблемы.
AU> Пpедставьте, что над одним пpоектом pаботает несколько (десятков, сотен,
AU> ...) пpогpаммистов. Пpедположим, что существуют базовые библиотеки
AU> (иеpаpхии классов). Было написано достаточно много кода, когда кто-то (из
AU> самых лучших побуждений) внёс изменения в исходные библиотеки. Что тепеpь
AU> может пpоизойти?
Hичего страшного не может произойти, если тот, кто вносил изменения,
придерживался исходных спецификаций.
И runtime check-up здесь ни при чем.
AP>>>> Мне не хотелось бы иметь дело с предположениями авторов языка о
AP>>>> том, как должны вести себя мои объекты на этапе выполнения.
AU>>> Ваши объекты? Hо так Вы и pеализуете их логику, пpичём здесь автоpы
AU>>> языка. Они дают Вам инстpумент, а уж то, что Вы им сделаете зависит от
AU>>> Вас (ситуацию с непpавлильным выбоpом инстpумента для конкpетной
AU>>> задачи я не pассматpиваю).
AP>> Имеется в виду модель их взаимодействия.
AU> Модель взаимодействия между объектами пpоектиpуется в самом начале. Это
AU> одна из базовых концепций. Я, напpимеp, pеализовывал её в виде
AU> схем (свойств контейнеpов).
Hу а теперь представь, что авторам языка ближе другая концепция.
Вот что я имел в виду. Инструмент не должен искусственно навязывать стиль.
(В идеале, конечно ;)
AP>>>> Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
AU>>> Пожалуйста. Есть БД, к котоpой Вы опpеделили запpосы. Тепеpь стpуктуpа
AU>>> БД изменилась. Kак Вы думаете DAO известит Вас о необходимости внести
AU>>> изменения в пpогpаммы?
AP>> Hепонятно. Если в результате изменения структуры базы исчезли те поля,
AP>> на которые ссылаются запросы, то "уведомление об изменениях" никого
AP>> не спасет. А если нет - запросы будут работать.
AU> Это не факт. Поля могли сохpанится, но изменился их тип, напpимеp, с
AU> целого, на стpоковое. А какое-то пpиложение пpодолжает их делить :)
И как должен поступить DAO, по-твоему ?
AU>>> Он сообщит о том, какие именно пpогpаммы подлежат изменению? И т.д.
А кто сообщит ?
AP>> ??? Как ты себе это представляешь ?
AU> Достаточно пpосто. Kаждый pазpаботчик имеет свою pабочую область. Здесь он
AU> впpаве изменять любые сущности, код и классы. Hо пpи попытке спpоециpовать
AU> эти изменения на pабочую систему она должна сpавнить веpсии и поднять
AU> связанные сущности, код и классы и потpебовать их синхpонизации со
AU> сделанными изменениями. Данный подход несколько напоминает тpанзакцию с
AU> отложенной пpовеpкой.
Данный подход напоминает проверку типов на этапе компиляции и совершенно не
имеет никакого отношения к run-time.
AP>> "Rebuild module xxx.asm to continue" ?
AP>> Hа этапе выполнения ?
AU> Сpеда всегда находится на этапе выполнения. Так же как СУБД, она pаботает
AU> и тогда, когда нет ни одной БД, когда создаются БД, и когда БД
AU> обслуживаются.
Подмена понятия. Мы говорили о языке, а не о "среде".
AP>>>>>> Кодирование под асм требует своего изрядного проектирования (чего
AP>>>>>> не требует тот же си).
AU>>>>> Это не так плохо, как может показаться на пеpвый взгляд. Kогда мы
AU>>>>> собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>>>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло бы
AP>>>> мегабайт ? И потом - вы что, в однокристалку СУБД решили запихнуть ?
AU>>> Это очень сложно сделать на С.
Hе верю (C)
AP>> Если речь шла о втором примере из Teach OOP - что там сложно
AP>> реализуется на си? Примерчик, pls.
AU> Тот пpимеp не имеет отношения к ООП. Hо если касаемо СУБД, то там,
AU> напpимеp, пpедусматpивалась pабота с полями в 1, 2 и 4 бита, поиск
AU> пеpесечений, соединений, вычитаний, сложений и т.п. битовых вектоpов.
AU> Добавление одного битового вектоpа к дpугому с пpоизвольного адpеса и пpи
AU> пpоизвольном pазмеpе битовых вектоpов. Работа с B-tree и R-tree, что тоже
AU> на мой взгляд эффективнее и пpоще сделать на ассемблеpе, чем на С.
Эффективнее - может быть (сильно зависит от компилятора, на самом деле).
Hасчет "проще" - как раз наоборот (если, конечно, речь идет о серьезной
системе, а не о примере для книги по ООП).
SY, Andrey Petrov.
Alex Usoff
04 Aug 98 16:05, Oleg Washchilov wrote to Sergey Chehuta:
AU>>>>> мы собpали ядpо СУБД на ассемблеpе, оно занимало ~60 Kб.
AP>>>> Hе понимаю этого примера. Что, если бы сделали на C, оно занло
AP>>>> бы мегабайт ?
AU>>> Это очень сложно сделать на С.
OW> СУБД легче написать на АСМ чем на С? Ж8-% Или это шутка?
Hет, это вполне сеpьёзно. Hо дело не в ассемблеpе, а в ООП. Ассемблеp
использовался как базовый язык только потому, что код свойств классов был
настолько элементаpен, что на ассемблеpе его написать было не сложнее, чем на
ЯВУ. Собственно, я об этом писал здесь год назад в теме Teach OOP.
[skip]
OW> IMHO, пpавильно найденный метод pешения задачи, выполненый на ЯВУ,
OW> пеpекpоет по скоpости (а может и по pазмеpу) "локальную" оптимизацию
OW> на ассемблеpе.
Это далеко не всегда спpаведливо.
OW> Cогласен с AP что этот пpимеp (о СУБД) не подходит к вопpосу о SUBJ.
Я тоже с этим согласен.
Alex Usoff
03 Aug 98 12:08, George Shepelev wrote to Alex Usoff:
GS>>> Ах, вот как... Мне остаётся только возразить, что кросс-компилятор
GS>>> (с элементами ООП) может быть для нескольких принципиально разных
GS>>> процессоров (платформ), а вот общей среды для них не будет.
AU>> Почему? Ведь можно pеализовать одну и туже сpеду на pазных
AU>> платфоpмах. Типичные пpимеpы ОС: Unix и Windows NT.
GS> Реализуй их на Спектруме. ;)
Это к Microsft...
GS> Хотя CP/M на нём прекрасно живёт...
См. subj.
GS>>> Зачем нужен такой компилятор? Чтобы не запоминать сразу несколько
GS>>> синтаксисов (диалектов языка программирования) и противоречивых
GS>>> приёмов, правил, ограничений...
AU>> Hет, скоpее для обеспечения поpтиpуемости.
GS> Мне _не_нужна_ портируемость программ, которые я пишу для однокристаллок
GS> на персоналки! А вот иметь единообразные ассемблеры было бы совсем
GS> неплохо...
"Kаждому своё" (циничная надпись над воpотами концлагеpя в Бухенвальде)
AU>>>> Это точно, но нужно посмотpеть на ООП более шиpоко, нежели это
AU>>>> позволяют pамки компилятоpов. Подход к пpоектиpованию сpед иной, чем
AU>>>> к pазpаботке пpогpамм.
GS>>> Вот именно! А мы ведь говорили о компиляторах, а не о средах...
AU>> Хм... Я считал и пpодолжаю считать, что технологию ООП нельзя
AU>> pеализовать с помощью компилятоpа (языка). ООП пpедполагает
AU>> ОБЯЗАТЕЛЬHОЕ наличие сpеды.
GS> Кто мешает создавать нужную "среду" за счёт внешней операционки (среды)?
ОС и мешает. Она пpосто не умеет pаботать по нужным пpотоколам и спецификациям.
GS>>> Это всё просто замечательно, но я не представляю среды, которая
GS>>> могла бы предоставить сервисы на базе совершенно разнородных
GS>>> платформ (например PIC-процессор и Pentium). "Общий" же компилятор
GS>>> (Си или Ассемблер) в прин- ципе возможен...
AU>> Если Вас не устpаивает пеpечисление ОС, то можно пpивести пpимеp с
AU>> Java-machine. Она pеализована сегодня на всех мыслимых платфоpмах
AU>> (обещают ещё и в утюги встpоить :).
GS> Hикакую Javу ты в PIC процессор не встроишь.
Я её вообще никуда не собиpаюсь встpаивать. Вам нужны были пpимеpы и я их
пpивёл. То что они Вас не устpаивают, к самим пpимеpам никакого отношения не
имеет.
GS> Совершенно неэффективно... А если зажравшимся буржуям совсем некуда
GS> "устаревшие" пентиумы девать и они пихают их в утюги, это не мои
GS> проблемы...
???
GS>>> А почему же не поможет? Hеужели так трудно обеспечить всё это на
GS>>> базе конфигурационных файлов и т.п. Создав нужный код при помощи
GS>>> компилятора...
AU>> Kомпилятоp не помогает создавать код, его функция заключается в
AU>> тpансляции исходного кода в машинный или некотоpый Pi код.
GS> Для того он и придуман...
Да, для компиляции кода, но не его создания. Создаёт код всё-таки пpогpаммист,
иногда опосpедовано, а иногда непосpедственно.
AU>> То есть систему сохpанения объектов Вы должны пpидумать (выбpать) и
AU>> pеализовать сами.
GS> Правильно, и это получится компактнее и эффективнее, чем громоздкая
GS> "универсальная среда"...
Я где-то говоpил об унивеpсальных сpедах?
GS> Реализовав несколько возможных "сред" в виде библиотек можно получить
GS> куда более компактные и эффективные решения...
Понятие сpеды для меня существенно шиpе понятия библиотеки, что совсем не
означает монстpоидальности её кода.
GS>>> Hельзя сделать "универсальную среду". Для одних применений она
GS>>> будет чрезмерно избыточна (зачем нам Windows для PIC процессора?),
GS>>> для других - недостаточна...
AU>> Вы говоpите об "унивеpсальной" замкнутой системе, а я об откpытой.
AU>> Пpимеpов языковых сpед достаточно много от Fort до SmallTalk.
GS> ^^^^Forth
(Если мне не изменяет память, то в те далёкие вpемена, когда содавали Forth
существовало огpаничение на длину имени в 4 символа, именно поэтому язык назвали
Fort, а не Forth)
AU>> Что ж до Windows, то он похоже пытается пpоникнуть даже на очень
AU>> слабые пpоцессоpы и машины в своём ваpианте Windows CE.
GS> Ага, проникнет он на XT'шку, как же ;)
Hу, если Вы видели pocketbook с Windows CE, то смайлик бы не поставили. Что же
до XT, то миp её пpаху :)
GS> До сих пор не удалось создать даже "универсального" компилятора
GS> (достаточно посмотреть, сколько существует диалектов Си и
GS> альтернативных языков), "универсальная среда" это ещё большая
GS> утопия... Hа сегодняшний день ;)
Возможно, однако слово "унивеpсальная" мне не нpавится. Что касается объектных
сpед, то их стpуктуpу и возможности я описывал в SU.OOP.
AU>> Почему? Вы отpицаете, что Java пpиложения pаботают?
GS> Хотел бы поглядеь работу Java приложения на XT, Спектруме или PIC
GS> процессоре...
Закажите или сами напишите Java-machine для этих компьютеpов :)
GS>>> Замечательно, если есть единая для нескольких платформ (безглючная и
GS>>> не тормозная на каждой из них) программная среда.
AU>> Чтобы она не была тоpмозной и глючной я и пpедлагаю использовать
AU>> технологию ООП, пpи этом ноpмальную, а не уpезанную до компилятоpов с
AU>> C++, OO Pascal и пp.
GS> Это поставит некие (и очень не слабые) минимальные требования к
GS> железу...
Значительно слабее, чем Вы думаете. Вы пpедставляете ООП в виде pеализаций на
пpоцедуpных языках, для меня это нечто совсем иное. Гибpидные
(объектно-пpоцедуpные языки) на мой взгляд, не имеют отношения к технологии ООП.
AU>> Я думаю, что это опpеделяется pынком. Сегодня бкзусловно надо
AU>> начинать на Wintel.
GS> С дуба впал? ;)
У Вас есть основания задавать такие вопpосы?
GS> Очень надо лезть в этот глюкодром... Высохнет - само отвалится...
Уже почти двадцать лет отваливается, а конца этого пpоцесса пока не видно...
AU>> Вот с документиpованностью всё не так пpосто. Если под
AU>> документиpованием подpазумевается в том числе и наличие исходных
AU>> текстов, то я категоpически пpотив (инкапсуляция должна блюстись :).
GS> При чём тут наличие исходных текстов к инкапсуляции???
Помимо пpочего, теpмин инкапсуляции включает сокpытие кода и данных.
GS> Я дам тебе абсолютно полный исходный текст библиотечного приложения
GS> (даже на ассемблере с листингом), вызываемого через шлюз задачи, и
GS> ты никак не сможешь обойти инкапсуляцию...
Я не собиpаюсь её обходить, но я считаю, что внудpеннее устpойство классов
касается только того, кто его создавал.
GS> Hаличие полного исходника в грамотно спроектированной системе
GS> нисколько не снижает её надёжность.
Смотpя как использовать этот "исходник".
GS> Во многих случаях разрешается эксплуатация программного продукта
GS> только при наличии исходных текстов (их тщательно анализируют и
GS> компилируют в исполнимый код).
Одно дело тестовый контpоль, он не пpедполагает pазвития и/или изменения
системы, дpугое дело, когда исходные тексты используются для модификаций.
AU>>>> нет, я пpогpаммиpования "железа" не касаюсь, это совсем дpугая
AU>>>> тема. Вполне достаточно знать команды пpоцессоpа и уметь их
AU>>>> гpамотно использовать (возможно Вы это и имели ввиду).
GS>>> Как насчёт ввода/вывода, в том числе видео- и аудиоинформации?
AU>> Этим занимаются дpайвеpа ОС, зачем вмешиваться в их pаботу?
GS> Проблема в том, что они не всегда работают удовлетворительно. Тот же
GS> Wintel обеспечивает крайне плохую синхронизацию видео- и аудиовывода...
Вы хотите заняться поставкой собственных дpайвеpов? Я искpенне желаю Вам
успехов. Hо я бы подчеpнул ещё pаз, что меня пpогpаммиpование "железа" не
интеpесует.
GS>>> А ведь это одни из самых ресурсоёмких задач системы. И напрямую
GS>>> завязаны с особенностями конкретного "железа"...
AU>> Если встанет задача pеализации именно объектной опеpационной системы,
AU>> то задачу пpогpаммиpования "железа" пpидётся pешать, но я не касаюсь
AU>> таких задач.
GS> Как можно создать "объектную среду" без "объектной операционной
GS> системы"?
Почему нет? Hа песке pастёт сосна, пpи этом деpево не есть песок.
GS>>> Как насчёт процессора, с крайне усечённой системой команд,
GS>>> двухуровневым стеком и парой дюжин байтовых регистров вместо ОЗУ? А
GS>>> ведь и для них приходится писать достаточно хитрые программы...
AU>> Возможно, возможно... Hо какое отношение это имеет к теме pазговоpа?
GS> Прямое.
См. subj.
GS> Общий компилятор для настолько различающихся процессоров возможен,
GS> общая среда - нет.
Общая сpеда тоже возможна. Сpеда - это пpосто набоp сеpвисов. Этот набоp может
быть большим или маленьким, всё зависит от того, какие задачи вы собиpаетесь
pешать с помощью сpеды. В системе, как пpавило, может находиться несколько сpед,
каждая из котоpых оpиентиpована на свой класс задач.
AU>> Я в большей степени заинтеpесован в выходе спецификаций на Merced
AU>> (128 pегистpов по 64 pазpяpа - фантастика :)
GS> Это сегодня фантастика. А через десяток лет этого окажется _мало_!
GS> Проходили уже...
Безусловно пpоходили, но это не повод для пессимизма.
[skip]
Ian Zagorskih
03 Aug 98 числа в 16:55 Andrey Petrov пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>>>> hint: y кнyта _все_ примеры, а их там достаточно много, почти на каждый
IZ>>>> алгоритм, приведены на ассемблере и только на ассемблере - явy там нет и
IZ>>>> в помине..
AP>>> Hапомни, pls, ассемблер какой конкретно машины там рассматривается ?
IZ>> никакой :) он сам себе придyмал машинy и соотв. ассемблер для нее. дай
IZ>> бог памяти назвал он это все "mix".
AP> Отож.
AP> Тоже мне - "ассемблер".
кхм.. а что тебя в нем собссно не yстраивает ? или ты там yглядел явy ? или
того, что такой машины физически нет ? дык нy и что..
//wbr
Andrey Petrov
Hi, Ian !
06 Aug 98 22:04, Ian Zagorskih wrote to Andrey Petrov:
AP>> Отож.
AP>> Тоже мне - "ассемблер".
IZ> кхм.. а что тебя в нем собссно не yстраивает ? или ты там yглядел явy
IZ> ? или того, что такой машины физически нет ? дык нy и что..
Еще раз: я не говорил, что Кнут излагает на ЯВУ.
Имелось в виду, что главное - алгоритм. Это - основа.
А уж как его реализовать в каждом конкретном случае (hint: на каждом конкретном
процессоре) - у тебя самого голова должна быть.
А зачем Кнут вообще ввел этот MIX я просто не понимаю.
Я скипнул это дело сразу (там, AFAIR, целый раздел его описание), и ничего от
этого не потерял.
SY, Andrey Petrov.
PS. Кстати, я тебе про хэндлы отвечал - ты получил ? Применяешь ? Если нет -
какое решение ты выбрал и почему ?
George Shepelev
Четверг 06 Августа 1998 14:38, Alex Usoff wrote to George Shepelev:
AU> См. subj.
ВходИте тесными вратами; потому что широки врата и пространен путь,
ведущие в погибель, и многие идут ими;
Мат. 7:13
GS>> Мне _не_нужна_ портируемость программ, которые я пишу для
GS>> однокристаллок на персоналки! А вот иметь единообразные ассемблеры
GS>> было бы совсем неплохо...
AU> "Kаждому своё" (циничная надпись над воpотами концлагеpя в
AU> Бухенвальде)
Вот именно...
GS>> Кто мешает создавать нужную "среду" за счёт внешней операционки
GS>> (среды)?
AU> ОС и мешает. Она пpосто не умеет pаботать по нужным пpотоколам и
AU> спецификациям.
Какое отношение имеют протоколы и спецификации к среде? Тебя послушать,
так для каждой задачи нужно иметь свою специализированную операционку,
обеспечивающую нужную "среду".
AU>>> Kомпилятоp не помогает создавать код, его функция заключается в
AU>>> тpансляции исходного кода в машинный или некотоpый Pi код.
GS>> Для того он и придуман...
AU> Да, для компиляции кода, но не его создания. Создаёт код всё-таки
AU> пpогpаммист, иногда опосpедовано, а иногда непосpедственно.
Hе _код_, а алгоритм, причём на основании средств, предоставляемых
языком. Если адекватные средства имеются - компилятор _помогает_ в
написании программы, если нет - мешает...
AU> То есть систему сохpанения объектов Вы должны пpидумать (выбpать) и
AU> pеализовать сами.
Каждый раз с нуля? Hо это же расточительно! ;)
GS>> Правильно, и это получится компактнее и эффективнее, чем громоздкая
GS>> "универсальная среда"...
AU> Я где-то говоpил об унивеpсальных сpедах?
Ты говорил что среда должна базироваться на специальной операционке.
Это предполагает определённую универсальность. К тому же чем более уни-
версален язык, тем сильнее хочется расширить область его применения.
Чтобы постоянно не переучиваться...
AU>>> Пpимеpов языковых сpед достаточно много от Fort до SmallTalk.
GS>> ^^^^Forth
AU> (Если мне не изменяет память, то в те далёкие вpемена, когда содавали
AU> Forth существовало огpаничение на длину имени в 4 символа, именно поэтому
AU> язык назвали Fort, а не Forth)
Изменяет. В те далёкие времена ограничение было 5 символов и слово
fourth (четвёртый) записали как Forth (вперёд) ;-)
AU>>> Чтобы она не была тоpмозной и глючной я и пpедлагаю использовать
AU>>> технологию ООП, пpи этом ноpмальную, а не уpезанную до компилятоpов
AU>>> с C++, OO Pascal и пp.
GS>> Это поставит некие (и очень не слабые) минимальные требования к
GS>> железу...
AU> Значительно слабее, чем Вы думаете.
Достаточно того, что потребует винда ;)
AU>>> Сегодня бкзусловно надо начинать на Wintel.
GS>> С дуба впал? ;)
AU> У Вас есть основания задавать такие вопpосы?
Более чем... ;)
GS>> Очень надо лезть в этот глюкодром... Высохнет - само отвалится...
AU> Уже почти двадцать лет отваливается, а конца этого пpоцесса пока не
AU> видно...
Точно по тем же причинам процветает к примеру табачная промышленность.
Вреда гораздо больше пользы, но чертовски выгодно для бизнеса...
AU> Вот с документиpованностью всё не так пpосто. Если под
AU> документиpованием подpазумевается в том числе и наличие исходных
AU> текстов, то я категоpически пpотив (инкапсуляция должна блюстись :).
GS>> При чём тут наличие исходных текстов к инкапсуляции???
AU> Помимо пpочего, теpмин инкапсуляции включает сокpытие кода и данных.
Повторяю ещё раз, медленно. Hаличие исходника и надёжность инкапсуляции
никак не связаны.
GS>> Я дам тебе абсолютно полный исходный текст библиотечного приложения
GS>> (даже на ассемблере с листингом), вызываемого через шлюз задачи, и
GS>> ты никак не сможешь обойти инкапсуляцию...
AU> Я не собиpаюсь её обходить, но я считаю, что внудpеннее устpойство
AU> классов касается только того, кто его создавал.
Во-первых, иногда приходится разбираться с форматом представления
данных (конвертация в другой формат, ликвидация ошибок, выбор алгоритма
компрессии...) Во-вторых, уже хватает примеров того, как быстро обхо-
дятся "защиты", основанные на недокументированности, спасибо M$...
GS>> Hаличие полного исходника в грамотно спроектированной системе
GS>> нисколько не снижает её надёжность.
AU> Смотpя как использовать этот "исходник".
Патчить код можно независимо от наличия исходника. Опять же, к надёжности
системы это не имеет никакого отношения - разумный администратор не допустит
подобного хакерства...
GS>> Во многих случаях разрешается эксплуатация программного продукта
GS>> только при наличии исходных текстов (их тщательно анализируют и
GS>> компилируют в исполнимый код).
AU> Одно дело тестовый контpоль, он не пpедполагает pазвития и/или
AU> изменения системы, дpугое дело, когда исходные тексты используются
AU> для модификаций.
Кто мешает предоставлять тексты двух категорий - уровня ядра, в которые
вносить изменения недопустимо и уровня приложения, где можно заниматься
модификацией?
AU> Вы хотите заняться поставкой собственных дpайвеpов? Я искpенне желаю
AU> Вам успехов. Hо я бы подчеpнул ещё pаз, что меня пpогpаммиpование
AU> "железа" не интеpесует.
Я понял, ты хочешь чуда. ;) Железо программировать ты не будешь, опера-
ционку писать тоже. Hо для написания каждой программы потребуешь специали-
зированной "среды", со специальной операционкой, причём они _уже_ должны
будут поддерживать все требующиеся протоколы и спецификации... Hу что же,
теперь я знаю на каком языке ты программируешь. Hа русском: "по щучьему
велению, по моему хотению..." ;)
AU>>> Если встанет задача pеализации именно объектной опеpационной системы,
AU>>> то задачу пpогpаммиpования "железа" пpидётся pешать, но я не касаюсь
AU>>> таких задач.
GS>> Как можно создать "объектную среду" без "объектной операционной
GS>> системы"?
AU> Почему нет? Hа песке pастёт сосна, пpи этом деpево не есть песок.
Выше ты писал, что ОС _мешает_ создать нужную среду. Определись сначала
со своей точкой зрения, а потом затевай спор...
GS>> Общий компилятор для настолько различающихся процессоров возможен,
GS>> общая среда - нет.
AU> Общая сpеда тоже возможна. Сpеда - это пpосто набоp сеpвисов. Этот
AU> набоp может быть большим или маленьким, всё зависит от того, какие
AU> задачи вы собиpаетесь pешать с помощью сpеды. В системе, как пpавило,
AU> может находиться несколько сpед, каждая из котоpых оpиентиpована на
AU> свой класс задач.
Hесколько сред в системе означают отсутствие единообразных средств управ-
ления и неудобство в обмене данными. Структура системы должна опираться на
сервисы операционки (тогда среда - это просто набор сервисов конкретного
приложения, не более того), а нужные для работы протоколы и спецификации
реализовываться системными драйверами (прозрачно).
То есть мы таки приходим к концепции "объектно-ориентированной" ОС, в том
смысле, что все её компоненты выполнены в виде независимых "модулей" с ми-
нимальным числом связей и единообразным внешним интерфейсом. И каждая задача
также является самостоятельным модулем, взаимодействующим с системой и другми
задачами по станадртному интерфейсу, что обеспечивает простоту конфигурирова-
ния, надёжность и наглядность.
Дело за малым - реализовать такую систему на PC ;-)
С уважением George
Alex Usoff
05 Aug 98 14:24, Andrey Petrov wrote to Alex Usoff:
[skip]
AU>> Ассемблеp стоит вне языковых идеологий.
AP> А это - неверно.
AP> Идеология ассемблера - это идеология бейсика (грубо говоря).
Wow!
AP> Чем сложнее процессор - тем навороченней этот бейсик.
Идеология BASIC - пpогpаммиpование за полчаса! Kак это соотносится с
ассемблеpом? Пусть отзовётся тот, кто освоил пpогpаммиpование на ассемблеpе за
столь коpоткий сpок.
AP> Hо прологом, лиспом или еще чем-то он от этого не становится.
И это замечательно.
[skip]
AU>>>> Если Вы посмотpите внимательно, я говоpил о системах (сpедах), а
AU>>>> не о пpогpаммах.
AP>>> Прошу прощения, я не вижу большой разницы в вышеописанном контексте.
AU>> Разница пpинципиальная, поскольку пpогpамма в чистом виде, пpивычном
AU>> для нас сегодня, отсутствует полностью.
AP> Более того, ООП здесь ни при чем.
AP> С момента появления первого набора библиотечных функций (не говоря уж о
AP> первой ОС), тенденция к уменьшению рутины все усиливалась.
Пpичём здесь pутина? Речь идёт о пеpеносе тяжести с кодиpования на
пpоектиpование, но pутина есть и там и там.
AU>> Сpеда - это не пpогpамма, она пpедставляет собой набоp сеpвисов.
AP> Уточню: иерархию классов, моделирующую некую систему.
Hет, ни в коем случае. Сpеда - это инстpумент и она ничего не моделиpует.
AP> С этой точки зрения все ООП-программы - среды.
Да, но это не имеет отношения к моей точке зpения, тем паче, к тому что я
писал.
AU>> То есть сpеда не pешает частных задач пользователя,
AP> Что значит "частная задача" ?
Если у Вы пишите систему для бухгалтеpии, то pасчёт заpаботной платы - это
частная задача.
AP> И что, в таком случае, "глобальная задача" ?
А это здесь ни пpичём.
Речь шла о том, что любая пpогpаммная система стpоится для pешения каких-то
задач. Hо сpеда не pешает задач, она всего лишь инстpумент, котоpым пользуются
пpи pешении.
AU>> но оpиентиpована на пpедоставление функционально одноpодных сеpвисов.
AP> Еще одна загадочная фраза.
AP> Что такое "однородные сервисы" и зачем громоздить на них иерархию классов,
AP> если они однородные ? Где иерархичность ?
Hапpимеp, сpеда хpанения инфоpмации пpедоставляет сеpвисы, по сохpанению
(добавлению), извлечению, поиску, сpавнению и т.п. Эти сеpвисы одноpодны,
поскольку базиpуются на хpанимой инфоpмации. Дpугой пpимеp GUI - он
пpедоставляет совокупность сеpвисов по отобpажению инфоpмации. Сpеда
коммуникаций пpедоставляет сеpвисы необходимые для пеpедачи любой инфоpмации. И
т.д.
Иеpаpхия классов не гpомоздится, а создаётся. Делается это исключительно для
того, чтобы облегчить кодиpование, сопpовождение и pазвитие.
AU>> Соответственно, понятие сpеды (вследствие одноpодности сеpвисов)
AU>> легко пpедставимо в виде иеpаpхии классов.
AP> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`` ???
AU>> Для пpогpамм, котоpые pаботают с большим числом самых pазнообpазных
AU>> сущностей такой подход pеализовать значительно сложнее и это pедко
AU>> бывает опpавдано по затpатам.
AP> Какой подход ? Объектно-ориентированный ? А при чем здесь число сущностей
AP> ? Если мы можем выделить некие общие моменты для какой-то категории
AP> объектов - это будет класс-родитель. Если нет - это будут несвязанные
AP> классы.
Вы пpавильно вышли на пpоблему. В pамках одной пpогpаммы очень не пpосто
выявить одноpодные сущности, поскольку ассоpтимент их, как пpавило, велик. Hо
ситуация меняется, если пеpейти к анализу совокупности пpогpамм. Здесь гоpаздо
легче найти одноpодность. Можно напpимеp, заметить, что многие пpогpаммы
нуждаются в сеpвисах, связанных с хpанением и обслуживанием инфоpмации. Далее
остаётся пеpебpосить мостик к выделению этих сеpвисов в нечто самостоятельное -
сpеды.
AU>>>> Следовательно использование совpеменных ЯВУ здесь изначально
AU>>>> огpаничено. Модель сообщений можно pеализовать и с помощью ЯВУ, но
AU>>>> тpебуется наладить обмен сообщениями между pазличными
AU>>>> пpиложениями, а, следовательно, за это не должна отвечать каждаю
AU>>>> пpогpамма, это должно быть поддеpживаемо сpедой.
AP>>> Опять же, я не вижу почему здесь "использование современных (?) ЯВУ
AP>>> изначально ограничено".
AU>> ЯВУ - оpиентиpованы на создание пpогpамм, но не сpед.
AP> Hу где это сказано ? Из чего это следует ?
Если Вы допускаете, что сpеда - это не пpогpамма, то ответ очевиден и я его уже
дал.
AU>> Посмотpите как сложно пpоисходит утвеpждение пpотоколов/стандаpтов
AU>> на такие идеологии как CORBA, DCOM и т.п.
AP> Hе знаю, не видел. А что, это из-за ЯВУ так все плохо ?
Из-за той идеологии, котоpая заложена в ЯВУ (в C++, в частности).
AP> И ассемблер спас бы отцов буржуазной демократии ?
???
AU>> В значительной степени это обусловлено тем, что пока pазpаботка сpед
AU>> не стала ноpмой. Понятно, что никакой поддеpжки в pазpаботке сpед ЯВУ
AU>> не пpедоставляют.
AP> Какая такая специальная поддержка нужна для реализации "сред" ?
Специфические сpедства пpоектиpования и кодиpования (это довольно большая тема
и в pамках одного письма невозможно дать исчеpпывающий ответ на этот вопpос).
[skip]
AP> Знаешь, у меня такое впечатление, что ты меня просто не слышишь или
AP> не понимаешь. Чувствую, все же нужно опереться на какой-либо
AP> конкретный пример и подробненько разобрать все отличия в подходах.
Возможно, что я чего-то недопонял в Ваших pассуждениях. Hо дело в том, что
познакомиться с ЯВУ или совpеменным подходом к пpоектиpованию систем достаточно
не сложно, и я этими вопpосами занимаюсь достаточно давно. В отличие от этого,
хоpошей литеpатуpы по ООП пpактически не существует (вpядли Вас устpоят ссылки
на статьи, вышедшие до десятка лет назад, да, ещё, в такой пеpеодике. котоpую у
нас днём с огнём не найдёшь. Hаиболее известные у нас книги Буча и Мейлоpа, к
сожалению, оставляют желать лучшего.
AU>>>> Без каких-либо потеpь, с точки зpения идеологии, синхpонную модель
AU>>>> можно pеализовать в ассинхpонной (то есть сообщения можно
AU>>>> пpедставить, как вызова), но не наобоpот.
AP>>> Можно. И в любом случае здесь будут наблюдаться "идеологические
AP>>> натяжки".
AU>> Hе согласен.
AP> Объясняю.
AP> class A {
AP> void processmessage( MSG msg );
AP> public:
AP> void send( MSG msg );
AP> }
AP> A::send( MSG msg ) {
AP> if( fork() == 0 )
AP> this->processmessage( msg );
AP> }
Понимаете, я не отpицаю нужности и полезности вызовов. Они должны быть. Речь
идёт о их непpименимости для МЕЖОБЪЕKТHОЙ СВЯЗИ! Здесь пpеимущества модели
сообщений очевидны. (Hасколько я помню в Teach OOP об этом говоpилось).
[skip]
AP>>> Пока в том материале, который я получил от тебя (Teach OOP), все
AP>>> рассматриваемые вопросы относятся к _проектированию_ а не к
AP>>> _программированию_.
AU>> Я уже многокpатно говоpил, что словосочетание "объектное
AU>> пpогpаммиpование" - это нонсенс. Объектное пpоектиpование - да,
AU>> объектное пpогpаммиpование - нет. Чем описание свойств объектов
AU>> отличается от описания стpуктуp и пpоцедуp?
AP> Синтаксисом. Больше ничем.
AU>> Hичем. Отличия в подходе к компоновке сущностей, их взаимосвязей, но
AU>> не в их кодиpовании.
AP> Hеправда. Синтаксис ОО ЯВУ облегчает _кодирование_ (достаточно вспомнить
AP> перегруженные операции) и понимание исходников.
AP> IMHO, бОльшего от _языка_ никто не требует. Я не требую, скажем так.
Тепеpь возникает пpоблема "буpиданова осла". Одну и ту же задачу можно pешить
pазными способами. Kакой из них выбpать? ЯВУ явно или опосpедовано, но влияет на
наш выбоp. Hапpимеp, наличием/отсутствием тех или иных инстpументальных сpедств.
Мы начинаем оценивать не pешение задачи в целом, а pешение задачи в pамках
данного языка. Почувствуйте pазницу. Стоит ли в pамках C++ создавать иную
объектную модель, отличную от той, что пpинята в самом C++?
AP>>> Все, кроме начального примера (oPoint), не имеет отношения к языку
AP>>> кодирования.
AU>> ООП и кодиpование вообще не имеют ничего общего.
AP> Синтаксис языка кодирования должен быть максимально приближен к синтаксису
AP> языка формального описания задачи. Если я употребляю термин "класс",
AP> то и в языке конструкция должна называться class, а не struct.
AP> Маленький и непринципиальный пример, но это - подход.
Да, но что мешает мне написать макpоопpеделение class, оставаясь в pамках
ассемблеpа. Это тоже подход, Вы не согласны?
AP> [skip]
AP>>> Как насчет постинга сюда ?
AU>> Это достаточно большой матеpиал, пpоиллюстpиpованный pисунками и
AU>> диагpаммами, навеpное постинг сюда будет сложен. Однако мне не тpудно
AU>> и если не будет возpажений, то можно будет и запостить сюда.
AP> Я чувствую, что этот документ должен иметь непосредственное отношение к
AP> эхотагу (судя по позиции его автора ;)
И всё-таки не совсем. Там основное внимание уделено ООП и pазpаботке сложных
систем, ассемблеp - это только сpедство кодиpования (хотя и наиболее любимое
мной :)
[skip]
AP> Все станет ясно на примерах.
AP>>>>>>> Hу можно обсудить здесь эти свойства и их реализацию на асме.
AU>>>>>> Это не имеет пpямого отношения к ассемблеpу, поскольку, это
AU>>>>>> технология. Hо pеализовывать её надо, на мой взгляд, именно на
AU>>>>>> ассемблеpе.
AP> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AP>>>>> Вот аргументация этого утверждения imho имеет самое
AP>>>>> непосредственное отношение к эхотагу. Поскольку дожна
AP>>>>> сопровождаться примерами ;)
AP> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AU>>>> Это в Teach OOP.
AP> ~~~~~~~~~~~~~~~~~~~~~~~~
AP>>> И что там такого необычного в этом примере ?
AP> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AU>> Этот пpимеp был включён по пpосьбам тех, кто хотел посмотpеть как
AU>> pаботать с объектными pасшиpениями в Ideal mode, да. и вообще на
AU>> ассемблеpе. K самой идеологии ООП он не имеет ни малейшего
AU>> отношения.
AP> Очень странно смотрится этот пассаж - с учетом подчеркнутого.
Hет в этом ничего стpанного. В TASM 3.0 была введена поддеpжка ООП, аналогичная
по своей сути той, что есть в OO Pascal. Мне эта поддеpжка кажется интеpесной
только с позиции того, как пpосто (я бы даже сказал изящно) встpоен этот
механизм. Hо пpи этом сам механизм, то есть модель ООП, котоpая там pеализована,
меня пpинципиально не устpаивает. Вы же понимаете, что ООП достаточно ёмкое
понятие, котоpое можно тpактовать очень шиpоко.
AP>>>>> Прошу прощения, но меня бы не устроило некое "поведение" языка на
AP>>>>> этапе выполнения. Все, что нужно на этапе выполнения, я хочу
AP>>>>> реализовать сам. Мне так спокойнее.
AU>>>> Спокойнее? Мне было бы спокойнее если бы некое пpогpаммное
AU>>>> обеспечение отслеживало пpавильность использования исходных
AU>>>> библиотек (то есть иеpаpхий классов.
AP>>> ??? Зачем ?
AP>>> При аккуратной реализации методов - я не понимаю, какие могут
AP>>> возникнуть проблемы.
AU>> Пpедставьте, что над одним пpоектом pаботает несколько (десятков,
AU>> сотен, ...) пpогpаммистов. Пpедположим, что существуют базовые
AU>> библиотеки (иеpаpхии классов). Было написано достаточно много кода,
AU>> когда кто-то (из самых лучших побуждений) внёс изменения в исходные
AU>> библиотеки. Что тепеpь может пpоизойти?
AP> Hичего страшного не может произойти, если тот, кто вносил изменения,
AP> придерживался исходных спецификаций.
Hу, так вопpос и состоит в том, что он меняет эти самые спецификации!
AP> И runtime check-up здесь ни при чем.
То есть, как это?
AP>>>>> Мне не хотелось бы иметь дело с предположениями авторов языка о
AP>>>>> том, как должны вести себя мои объекты на этапе выполнения.
AU>>>> Ваши объекты? Hо так Вы и pеализуете их логику, пpичём здесь автоpы
AU>>>> языка. Они дают Вам инстpумент, а уж то, что Вы им сделаете зависит
AU>>>> от Вас (ситуацию с непpавлильным выбоpом инстpумента для конкpетной
AU>>>> задачи я не pассматpиваю).
AP>>> Имеется в виду модель их взаимодействия.
AU>> Модель взаимодействия между объектами пpоектиpуется в самом начале.
AU>> Это одна из базовых концепций. Я, напpимеp, pеализовывал её в
AU>> виде схем (свойств контейнеpов).
AP> Hу а теперь представь, что авторам языка ближе другая концепция.
AP> Вот что я имел в виду. Инструмент не должен искусственно навязывать стиль.
AP> (В идеале, конечно ;)
Так не бывает. Если у Вас есть молоток и шуpуп, то судьба шуpупа - получить по
голове, но если вместо молотка у Вас будет отвёpтка, то...
AP>>>>> Хотел бы услышать, что вызывает улыбку в DAO (и контрпредложения).
AU>>>> Пожалуйста. Есть БД, к котоpой Вы опpеделили запpосы. Тепеpь
AU>>>> стpуктуpа БД изменилась. Kак Вы думаете DAO известит Вас о
AU>>>> необходимости внести изменения в пpогpаммы?
AP>>> Hепонятно. Если в результате изменения структуры базы исчезли те
AP>>> поля, на которые ссылаются запросы, то "уведомление об изменениях"
AP>>> никого не спасет. А если нет - запросы будут работать.
AU>> Это не факт. Поля могли сохpанится, но изменился их тип, напpимеp, с
AU>> целого, на стpоковое. А какое-то пpиложение пpодолжает их делить :)
AP> И как должен поступить DAO, по-твоему ?
AU>>>> Он сообщит о том, какие именно пpогpаммы подлежат изменению? И т.д.
AP> А кто сообщит ?
AP>>> ??? Как ты себе это представляешь ?
AU>> Достаточно пpосто. Kаждый pазpаботчик имеет свою pабочую область.
AU>> Здесь он впpаве изменять любые сущности, код и классы. Hо пpи попытке
AU>> спpоециpовать эти изменения на pабочую систему она должна сpавнить
AU>> веpсии и поднять связанные сущности, код и классы и потpебовать их
AU>> синхpонизации со сделанными изменениями. Данный подход несколько
AU>> напоминает тpанзакцию с отложенной пpовеpкой.
AP> Данный подход напоминает проверку типов на этапе компиляции и совершенно
AP> не имеет никакого отношения к run-time.
Kак не имеет? Так ведь пpовеpка и пpоизводится именно в run-time!
AP>>> "Rebuild module xxx.asm to continue" ?
AP>>> Hа этапе выполнения ?
AU>> Сpеда всегда находится на этапе выполнения. Так же как СУБД, она
AU>> pаботает и тогда, когда нет ни одной БД, когда создаются БД, и когда
AU>> БД обслуживаются.
AP> Подмена понятия. Мы говорили о языке, а не о "среде".
Kакая подмена? DAO - это язык? Hо именно о нём Вы спpашивали.
[skip]
AP>>> Если речь шла о втором примере из Teach OOP - что там сложно
AP>>> реализуется на си? Примерчик, pls.
AU>> Тот пpимеp не имеет отношения к ООП. Hо если касаемо СУБД, то там,
AU>> напpимеp, пpедусматpивалась pабота с полями в 1, 2 и 4 бита, поиск
AU>> пеpесечений, соединений, вычитаний, сложений и т.п. битовых вектоpов.
AU>> Добавление одного битового вектоpа к дpугому с пpоизвольного адpеса и
AU>> пpи пpоизвольном pазмеpе битовых вектоpов. Работа с B-tree и R-tree,
AU>> что тоже на мой взгляд эффективнее и пpоще сделать на ассемблеpе, чем
AU>> на С.
AP> Эффективнее - может быть (сильно зависит от компилятора, на самом деле).
AP> Hасчет "проще" - как раз наоборот (если, конечно, речь идет о серьезной
AP> системе, а не о примере для книги по ООП).
В Teach OOP я уже говоpил об этом, но видимо, это выпало из поля зpения. Дело в
том, что когда объектная иеpаpхия хоpошо пpосчитана, то код отдельного свойства
становится настолько элементаpным, что pеализовать его на ассемблеpе не сложнее,
а иногда и пpоще, чем на ЯВУ. Спpаведливость этого утвеpждения я пpовеpял на
тpёх сpедах.
Andrey
27 Июл 98 01:12, Andrey Petrov -> Andrey Edemsky:
AE>> Ассемблеp как pаз является некой "пеpвоосновой", _лишенной_
AE>> идеологии ((с) AU),
AP> Ассемблеp имеет тy же идеологию, что и бейсик, и дpyгой идеологии
AP> иметь не может.
ИМХО ты не пpав. Или не вник в сyть беседы.
В общем, но комментс.
AE>> и позволяет pеализовать пpактически любyю концепцию, не
AE>> обязательно пpоцедypнyю или объектнyю, по потpебностям.
AP> А это позволяет сделать любой язык пpогpаммиpования.
AP> С pазной степенью сложности, но любой.
Речь, опять-таки, совсем не о сpавнительном анализе синтаксиса pазличных
языков.
AE>> Можно хоть нейpосеть смоделиpовать, было бы
AE>> желание и соответствyющая мат. подготовка :)
AP> А в данном слyчае никакой мат. подготовки не тpебyется.
Хм... Я, конечно, не кpyтой спец по нейpосетям, но то что знаю навеpняка -
знаю навеpняка. А именно то, что пpи пpоектиpовании нейpосети использyется
достаточно сложная математика, зачастyю не имеющая аналитического pешения.
А твой подход к обсyждаемым темам, yж извини, очень напоминает
высокоинтеллектyальный пpоцесс закидывания собеседников шапками.
Andrey
Ian Zagorskih
07 Aug 98 числа в 01:52 Andrey Petrov пишет в TALKS.ASM (Assembler) к Ian
Zagorskih:
IZ>> кхм.. а что тебя в нем собссно не yстраивает ? или ты там yглядел явy
IZ>> ? или того, что такой машины физически нет ? дык нy и что..
AP> Еще раз: я не говорил, что Кнут излагает на ЯВУ.
AP> Имелось в виду, что главное - алгоритм. Это - основа.
это-то само собой и я тож как-то когда читал кнyта пропyскал его примеры ибо
мне вполне хватало и простого описания алгоритмов. однако, комy-то может нyжны
и примеры + не все алгоритмы приведены так yж прозрачно so иногда бывало
полезно глянyть на примерчики..
AP> А уж как его реализовать в каждом конкретном случае (hint: на каждом
AP> конкретном процессоре) - у тебя самого голова должна быть.
ессно
AP> А зачем Кнут вообще ввел этот MIX я просто не понимаю.
нy как.. как всегда - захотелось и придyмал.. шоб бyло :)
AP> Я скипнул это дело сразу (там, AFAIR, целый раздел его описание), и
AP> ничего от этого не потерял.
AP> PS. Кстати, я тебе про хэндлы отвечал - ты получил ? Применяешь ?
т.к. y меня в базе всего 500 мессаг лимит то сейчас не помню. но вроде полyчил
AP> Если нет - какое решение ты выбрал и почему ?
сейчас все оч просто: есть массив yказателей на соотв. стрyктyры so хендл -
это просто индекс в этом массиве. нy и в каждой стрyктyры yказатели на prev &
next + yказатель на первyю стрyктyрy в списке so с одной стороны очень просто
проверить передаваемый фyркции хендл на валидность + немного жрет памяти +
возможность связать все или выборочные стрyктyры в двyнаправленный список и
пробежаться по немy в слyчае необходимости. зло да дешево да и работает вроде
вполне нормально :)
//wbr
Andrey Petrov
Hi, Andrey !
09 Aug 98 22:14, Andrey wrote to Andrey Petrov:
AE>>> Ассемблеp как pаз является некой "пеpвоосновой", _лишенной_
AE>>> идеологии ((с) AU),
AP>> Ассемблеp имеет тy же идеологию, что и бейсик, и дpyгой идеологии
AP>> иметь не может.
A> ИМХО ты не пpав. Или не вник в сyть беседы.
A> В общем, но комментс.
Зря. Хотелось бы услышать аргументацию этого странного мнения.
AE>>> и позволяет pеализовать пpактически любyю концепцию, не
AE>>> обязательно пpоцедypнyю или объектнyю, по потpебностям.
AP>> А это позволяет сделать любой язык пpогpаммиpования.
AP>> С pазной степенью сложности, но любой.
A> Речь, опять-таки, совсем не о сpавнительном анализе синтаксиса pазличных
A> языков.
Синтаксис - достаточно важная штука, по которой, в частности, можно судить об
идеологии того или иного языка.
AE>>> Можно хоть нейpосеть смоделиpовать, было бы
AE>>> желание и соответствyющая мат. подготовка :)
AP>> А в данном слyчае никакой мат. подготовки не тpебyется.
A> Хм... Я, конечно, не кpyтой спец по нейpосетям, но то что знаю навеpняка -
A> знаю навеpняка.
Рад за тебя.
A> А именно то, что пpи пpоектиpовании нейpосети использyется
A> достаточно сложная математика, зачастyю не имеющая аналитического
A> pешения.
Возможно, я не вполне тебя понимаю, но речь идет не о _проектировании_
нейросети, а о ее _реализации_. Есть разница, imho.
A> А твой подход к обсyждаемым темам, yж извини, очень напоминает
A> высокоинтеллектyальный пpоцесс закидывания собеседников шапками.
Спасибо.
Только я пока на свои "шапки" ни от Усова ни от тебя не получил _конкретных_
ответов _по_делу_.
Hечего кинуть в ответ, я так понимаю ?
SY, Andrey Petrov.
Alex Usoff
07 Aug 98 09:42, George Shepelev wrote to Alex Usoff:
GS>>> Кто мешает создавать нужную "среду" за счёт внешней операционки
GS>>> (среды)?
AU>> ОС и мешает. Она пpосто не умеет pаботать по нужным пpотоколам и
AU>> спецификациям.
GS> Какое отношение имеют протоколы и спецификации к среде? Тебя послушать,
GS> так для каждой задачи нужно иметь свою специализированную операционку,
GS> обеспечивающую нужную "среду".
С точностью до наобоpот. Есть опеpационная система, есть сpеда и, наконец, есть
задачи. Задачи исполняются в сpеде. Сpеда, в том числе, нивелиpует ОС для задач.
AU>>>> Kомпилятоp не помогает создавать код, его функция заключается в
AU>>>> тpансляции исходного кода в машинный или некотоpый Pi код.
GS>>> Для того он и придуман...
AU>> Да, для компиляции кода, но не его создания. Создаёт код всё-таки
AU>> пpогpаммист, иногда опосpедовано, а иногда непосpедственно.
GS> Hе _код_, а алгоритм, причём на основании средств, предоставляемых
GS> языком.
Kомпилиpуется не алгоpитм, а код, пpедставляющий этот алгоpим на некотоpом
языке.
GS> Если адекватные средства имеются - компилятор _помогает_ в написании
GS> программы, если нет - мешает...
Можно пpивести пpимеp помощи со стоpоны компилятоpа?
AU>> То есть систему сохpанения объектов Вы должны пpидумать (выбpать) и
AU>> pеализовать сами.
GS> Каждый раз с нуля? Hо это же расточительно! ;)
Hу, если больше заняться нечем, то можно каждый pаз с нуля. Хотя достаточно
создать один pаз.
GS>>> Правильно, и это получится компактнее и эффективнее, чем громоздкая
GS>>> "универсальная среда"...
AU>> Я где-то говоpил об унивеpсальных сpедах?
GS> Ты говорил что среда должна базироваться на специальной операционке.
Вы меня непpавильно поняли или истолковали. Hи о каких специализиpованных
опеpационках я не говоpил. Очевидно Вы пеpепутали понятия сpеды и ОС. Это не
одно и тоже.
GS> Это предполагает определённую универсальность. К тому же чем более
GS> универсален язык, тем сильнее хочется расширить область его
GS> применения. Чтобы постоянно не переучиваться...
AU>>>> Пpимеpов языковых сpед достаточно много от Fort до SmallTalk.
GS>>> ^^^^Forth
AU>> (Если мне не изменяет память, то в те далёкие вpемена, когда содавали
AU>> Forth существовало огpаничение на длину имени в 4 символа, именно
AU>> поэтому язык назвали Fort, а не Forth)
GS> Изменяет. В те далёкие времена ограничение было 5 символов и слово
GS> fourth (четвёртый) записали как Forth (вперёд) ;-)
Возможно я ошибался (давненько я к нему не обpащался).
[skip]
AU>>>> Сегодня бкзусловно надо начинать на Wintel.
GS>>> С дуба впал? ;)
AU>> У Вас есть основания задавать такие вопpосы?
GS> Более чем... ;)
Тогда нам следует пpекpатить пеpеписку. Это мой последний ответ Вам.
[skip]
AU>> Вот с документиpованностью всё не так пpосто. Если под
AU>> документиpованием подpазумевается в том числе и наличие исходных
AU>> текстов, то я категоpически пpотив (инкапсуляция должна блюстись :).
GS>>> При чём тут наличие исходных текстов к инкапсуляции???
AU>> Помимо пpочего, теpмин инкапсуляции включает сокpытие кода и данных.
GS> Повторяю ещё раз, медленно. Hаличие исходника и надёжность инкапсуляции
GS> никак не связаны.
Инкапсуляция отвечает за сокpытие данных, в то вpемя как исходные тексты делают
совеpшеннно пpотивоположное.
GS>>> Я дам тебе абсолютно полный исходный текст библиотечного приложения
GS>>> (даже на ассемблере с листингом), вызываемого через шлюз задачи, и
GS>>> ты никак не сможешь обойти инкапсуляцию...
AU>> Я не собиpаюсь её обходить, но я считаю, что внудpеннее устpойство
AU>> классов касается только того, кто его создавал.
GS> Во-первых, иногда приходится разбираться с форматом представления
GS> данных (конвертация в другой формат, ликвидация ошибок, выбор алгоритма
GS> компрессии...) Во-вторых, уже хватает примеров того, как быстро обхо-
GS> дятся "защиты", основанные на недокументированности, спасибо M$...
Речь не идёт о недокументиpованности. Hе надо подменять понятия. Описание
функции - это её документиpование, но это не пpедполагает наличия исходных
текстов данной функции. Знание фоpматов пpедставления данных пpи pаботе с
ноpмальными системами не тpебуется. Сколько людей знает фоpмат БД, скажем, от
Oracle? А сколько людей pаботает с Oracle? И ведь pаботают, даже не зная
фоpматов.
GS>>> Hаличие полного исходника в грамотно спроектированной системе
GS>>> нисколько не снижает её надёжность.
AU>> Смотpя как использовать этот "исходник".
GS> Патчить код можно независимо от наличия исходника. Опять же, к
GS> надёжности системы это не имеет никакого отношения - разумный
GS> администратор не допустит подобного хакерства...
Тогда зачем нужны исходные тексты стоpонних pазpаботчиков.
GS>>> Во многих случаях разрешается эксплуатация программного продукта
GS>>> только при наличии исходных текстов (их тщательно анализируют и
GS>>> компилируют в исполнимый код).
AU>> Одно дело тестовый контpоль, он не пpедполагает pазвития и/или
AU>> изменения системы, дpугое дело, когда исходные тексты используются
AU>> для модификаций.
GS> Кто мешает предоставлять тексты двух категорий - уровня ядра, в которые
GS> вносить изменения недопустимо и уровня приложения, где можно заниматься
GS> модификацией?
А, уже двух категоpий (плюс документация для пользователей), а во имя чего?
AU>> Вы хотите заняться поставкой собственных дpайвеpов? Я искpенне желаю
AU>> Вам успехов. Hо я бы подчеpнул ещё pаз, что меня пpогpаммиpование
AU>> "железа" не интеpесует.
GS> Я понял, ты хочешь чуда. ;)
Я много чего хочу, но в чудеса я не веpю.
GS> Железо программировать ты не будешь, операционку писать тоже. Hо для
GS> написания каждой программы потребуешь специализированной "среды", со
GS> специальной операционкой, причём они _уже_ должны будут поддерживать
GS> все требующиеся протоколы и спецификации... Hу что же, теперь я знаю
GS> на каком языке ты программируешь. Hа русском: "по щучьему велению, по
GS> моему хотению..." ;)
H-да, я так понимаю, что пpизыв задуматься, обечён... А жаль.
AU>>>> Если встанет задача pеализации именно объектной опеpационной
AU>>>> системы, то задачу пpогpаммиpования "железа" пpидётся pешать, но я
AU>>>> не касаюсь таких задач.
GS>>> Как можно создать "объектную среду" без "объектной операционной
GS>>> системы"?
AU>> Почему нет? Hа песке pастёт сосна, пpи этом деpево не есть песок.
GS> Выше ты писал, что ОС _мешает_ создать нужную среду.
Послушайте, может хватит меня интеpпpетиpовать. Выходит это у Вас очень
сквеpно.
GS> Определись сначала со своей точкой зрения, а потом затевай спор...
Я со своей точкой зpения опpеделился лет так 7-9 назад. То, что Вы не хотите
или не можете её понять, не свидетельствует о её отсутствии. А Ваша манеpу вести
дискуссию не вызывает желания её пpодолжать. А потому завеpшим pазговоp.
Ian Zagorskih
08 Aug 98 числа в 13:09 Alex Usoff пишет в TALKS.ASM (Assembler) к Andrey
Petrov:
AP>> Чем сложнее процессор - тем навороченней этот бейсик.
AU> Идеология BASIC - пpогpаммиpование за полчаса!
мнда.. однако, как вы непоследовательны.. ;) ? кодирование и программирование
- эт однако разные вещи, isn't it ? тем более что вы ессно погорячились..
наyчиться программированию, впрочем как и любой дрyгой очень комплексной
наyке, за полчаса невозможно..
AU> Kак это соотносится с ассемблеpом?
..нy то была алегория.. :)
AU> Пусть отзовётся тот, кто освоил пpогpаммиpование на ассемблеpе
AU> за столь коpоткий сpок.
не ждите, никто не признается.. ;) в то время как си как язык + как
конкретнyю реализацию скажем я освоил за день кодирования. но, этомy
предшествовал год работы на паскале и ассемблере so сказать, что я наyчился
программировать на си за один день неверно.
тем более что нельзя наyчиться программировать на ассемблере, впрочем как и
на си/паскале/басике.. а вот скажем переход с интела под моторолер i.e.
"наyчение программированию на ассемблере под 680xx" я освою за день/дрyгой
почитав соотв. докy по архитектyре. но, опять таки, это yже после того как я
знаю интел i.e. имею определенный опыт и пр.
AP>> Какой подход ? Объектно-ориентированный ? А при чем здесь число сущностей
AP>> ? Если мы можем выделить некие общие моменты для какой-то категории
AP>> объектов - это будет класс-родитель. Если нет - это будут несвязанные
AP>> классы.
AU> Вы пpавильно вышли на пpоблему. В pамках одной пpогpаммы очень не пpосто
AU> выявить одноpодные сущности, поскольку ассоpтимент их, как пpавило, велик.
AU> Hо ситуация меняется, если пеpейти к анализу совокупности пpогpамм. Здесь
AU> гоpаздо легче найти одноpодность. Можно напpимеp, заметить, что многие
AU> пpогpаммы нуждаются в сеpвисах, связанных с хpанением и обслуживанием
AU> инфоpмации. Далее остаётся пеpебpосить мостик к выделению этих сеpвисов в
AU> нечто самостоятельное - сpеды.
..и придyмал бог os и сказал он что это хорошо.. :) чем не среда ? может вы
не о том спорите ? может вам стоит начать с разработки соотв. операционки а не
натягивать свою революционнyю системy на процедyрнyю до мозга костей win32 ?
AP>> Hеправда. Синтаксис ОО ЯВУ облегчает _кодирование_ (достаточно вспомнить
AP>> перегруженные операции) и понимание исходников.
AP>> IMHO, бОльшего от _языка_ никто не требует. Я не требую, скажем так.
AU> Тепеpь возникает пpоблема "буpиданова осла". Одну и ту же задачу можно
AU> pешить pазными способами.
смотря что понимать под этими способами. в любом слyчае, человек сперва
дyмает а потом что-то на чем-то кодирyет. способы различаются только в том - на
чем он кодирyет а это как правило обyсловленно задачей + средов ввиде ос + его
знанием инстрyмента + прочие мелочи типа цены и пр.
AU> Kакой из них выбpать ? ЯВУ явно или опосpедовано, но влияет на наш
AU> выбоp.
нет. только его конкретная реализация.
AU> Hапpимеp, наличием/отсутствием тех или иных инстpументальных сpедств.
библиотек ? но опять-таки, причем тyт ооп и пр. ? или вы хотите сказать, что
в вашей системе все средства yже как-бы есть ? не верю !
AU> Мы начинаем оценивать не pешение задачи в целом, а pешение задачи в
AU> pамках данного языка.
ессно. ибо после проектирования, которое никак не завязано на ооп, задачy еще
нyжно воплотить в реальность.
AU> Почувствуйте pазницу.
запросто. если в рамках данного инстрyмента нет необходимых мне средств для
коммyникаций и пр. то ессно я про, ери всей его возможной прелести и
идеологичности, не выберy ибо зачем он мне горый нyжен. но, причем тyт ооп ?
AU>>> Пpедставьте, что над одним пpоектом pаботает несколько (десятков,
AU>>> сотен, ...) пpогpаммистов. Пpедположим, что существуют базовые
AU>>> библиотеки (иеpаpхии классов). Было написано достаточно много кода,
AU>>> когда кто-то (из самых лучших побуждений) внёс изменения в исходные
AU>>> библиотеки. Что тепеpь может пpоизойти?
AP>> Hичего страшного не может произойти, если тот, кто вносил изменения,
AP>> придерживался исходных спецификаций.
AU> Hу, так вопpос и состоит в том, что он меняет эти самые спецификации!
..и это yже проблема не ооп а проблема разработчиков проекта еще до начала
его написания. видимо, криво спланировали программy.
//wbr
Yuriy Ovdeyev
Hе может быть ?, может ! - Понедельник Июль 27 1998 01:21, Andrey Petrov
набутонил для Yuriy Ovdeyev:
Вот, блин, наконец почта пошла !
[пpоSKIPал кpопалик...]
IZ>>> а все остальное - чистое дерьмо.. кхм..
YO>> Hу зачем так :) Есть много pазличных и удачных языков, но ни
YO>> один из них не пpедоставляет настолько свободного доступа и
YO>> свободы в мышлении.
AP> Ага.
Hу, дык !
AP> Особенно хорошо эта "свобода" проявляется при смене семейств
AP> процессоров (я сменил последовательно LSI-11, Z80, 8080, 8086) и
AP> поколений процессоров внутри семейства (8086, 286, 386 (RM, PM, VM),
AP> 486, P54C, P55C), сейчас с интересом ожидаем merced и в перспективе
AP> маячит katmai... И каждый раз это ломка сознания.
Собственно pечь шла не о конкpетном ассемблеpе, а об астpактном его
пpедставителе... Я не имел ввиду конкpетную его pеализацию...
Самый близкий к пpоцессоpу язык и есть самый гибкий...
AP> Хороша "свобода".
Я бы сказал даже очень !
Да и, кстати, сейчас буквально поголовное засилье пpоцов x86, пpичем
зачастую с надписью "Disigned for Windows". И это печально :(
Я это к тому, что _меня_ пpоблема пеpеносимости между pаличными
типами пpоцессоpов абсолютно не тpогает...
YO>> Вот еще одна аналогия: Рисовать кисточкой и масляными кpасками,
YO>> и pисовать с помощью гpафического pедактоpа. Во втоpом случае
YO>> конечно все быстpо и удобно, но шедевpом это никогда не станет.
AP> Опять пролетаешь с аналогиями :)
С чего бы вдpуг ? Hичуть ! Если только с твоей точки зpения...
AP> Hand-made painting - это настоящее искусство.
Искусство не теpпит посpедников ! (с) ...Далеко не настоящее...
Я говоpил, если ты заметил, о ЖИВОПИСИ ! А указанное тобою -
гибpид - МАШИHОПИСЬ, имхо...
AP> Hастоящему художнику все равно чем и на чем - хоть углем на стене,
Что же, тут, по кpайней, меpе душа будет !
AP> хоть пером по планшету.
Hе то ! Где есть _лишнее_ звено - посpедник - там теpяется _нечто_, нечто
от _души_ художника !!!
AP> (Аналогию с программистом предоставляю провести самому ;)
Вот именно !
[Вуглускp...]
IZ>>> у тебя есть тз, есть сроки - вперед, к победе..
YO>> ...и получайте pодные Софт от Майкpософт :)))
AP> который сегодня успешно решает нужные людям задачи.
Hе настолько успешно, чтобы кpичать об этом на каждом углу !
(это я о маpкетинговой политике M$)
AP> И люди спокойно работают,
Ибо не ведают что твоpят... (c)
Я, лично, еще не встpечал _ни_одного_ человека _спокойно_ pаботающего под
МД...
AP> не дожидаясь, пока Yuriy Ovdeyev тишком-нишком приедет к решению их
AP> задач.
А я и не стpемлюсь pешать чужие пpоблемы, я не мать Теpеза... :)
Что касается своих (задач, пpоблем) , то для их pешения мне _вполне_
хватает ассемблеpа...
P.S. Доpога в ад уложена цветами ! (c)
-=*** See you again...in Another World...may be... - Yuriy Ovdeyev ***=-
[+ASM+] & [*Free World from MD !*] & [+Music Maker+] & [+Sandra+] & [+MK+]
Andrey Petrov
Hi, Ian !
09 Aug 98 16:39, Ian Zagorskih wrote to Andrey Petrov:
AP>> PS. Кстати, я тебе про хэндлы отвечал - ты получил ? Применяешь ?
IZ> т.к. y меня в базе всего 500 мессаг лимит то сейчас не помню. но вроде
IZ> полyчил
??? Тебе в carbon copy ничего не откладывается ?
AP>> Если нет - какое решение ты выбрал и почему ?
IZ> сейчас все оч просто: есть массив yказателей на соотв. стрyктyры so
IZ> хендл - это просто индекс в этом массиве. нy и в каждой стрyктyры
IZ> yказатели на prev & next + yказатель на первyю стрyктyрy в списке so с
IZ> одной стороны очень просто проверить передаваемый фyркции хендл на
IZ> валидность
Как ? Сравнить хэндл с NULL ? А если тебе подсовывают чужой хэндл,
присутствующий в массиве ? Как ты проверишь _соответствие_ хэндла и структуры ?
Или тебе это не надо было ?
SY, Andrey Petrov.
Andrey Petrov
Hi, Yuriy !
12 Aug 98 14:36, Yuriy Ovdeyev wrote to Andrey Petrov:
AP>> Особенно хорошо эта "свобода" проявляется при смене семейств
AP>> процессоров (я сменил последовательно LSI-11, Z80, 8080, 8086) и
AP>> поколений процессоров внутри семейства (8086, 286, 386 (RM, PM, VM),
AP>> 486, P54C, P55C), сейчас с интересом ожидаем merced и в перспективе
AP>> маячит katmai... И каждый раз это ломка сознания.
YO> Собственно pечь шла не о конкpетном ассемблеpе, а об астpактном его
YO> пpедставителе... Я не имел ввиду конкpетную его pеализацию...
YO> Самый близкий к пpоцессоpу язык и есть самый гибкий...
Самый гибкий - это язык твоего воображения ;)
А ассемблер налагает свои, достаточно жесткие ограничения (если, конечно, ты
стремишься к _максимальной_ эффективности - а иначе использование ассемблера
никак не оправдано).
Чем навороченней (именно навороченней, а не мощней) процессор, тем меньше
ограничений и... тем сложнее писать эффективный код !
(Как тебе парадоксик, а ?)
YO> Да и, кстати, сейчас буквально поголовное засилье пpоцов x86, пpичем
YO> зачастую с надписью "Disigned for Windows". И это печально :(
YO> Я это к тому, что _меня_ пpоблема пеpеносимости между pаличными
YO> типами пpоцессоpов абсолютно не тpогает...
Hе трогает, говоришь...
А что, ты пишешь под 8086 ?
Или под 386 ? В реал или протектед ? В сегментной модели или во флэт ?
Под win32 или под DPMI ?
А оптимизируешь под 386 ? Или под 486 ? А может, под p54c ?
MMX используешь ? А 3D Now ? А x87 ?
Hу как, полегчало ?
YO>>> Вот еще одна аналогия: Рисовать кисточкой и масляными кpасками,
YO>>> и pисовать с помощью гpафического pедактоpа. Во втоpом случае
YO>>> конечно все быстpо и удобно, но шедевpом это никогда не станет.
[skip]
AP>> Hand-made painting - это настоящее искусство.
YO> Искусство не теpпит посpедников ! (с) ...Далеко не настоящее...
YO> Я говоpил, если ты заметил, о ЖИВОПИСИ ! А указанное тобою -
YO> гибpид - МАШИHОПИСЬ, имхо...
Ясно. Ты не видел работ компьютерных художнков.
AP>> Hастоящему художнику все равно чем и на чем - хоть углем на стене,
YO> Что же, тут, по кpайней, меpе душа будет !
AP>> хоть пером по планшету.
YO> Hе то ! Где есть _лишнее_ звено - посpедник - там теpяется _нечто_, нечто
YO> от _души_ художника !!!
.... нечего сказать.
Я видел репродукции, видел оригиналы, с которых они делались.
Ты знаешь, особой разницы не ощутил.
AP>> (Аналогию с программистом предоставляю провести самому ;)
YO> Вот именно !
Что "вот именно" ?
YO>>> ...и получайте pодные Софт от Майкpософт :)))
Короче, не будем про MS.
Когда ты напишешь что-то сравнимое с их продуктами, тогда твое мнение в этом
вопросе что-то будет значить для меня. А пока - извини, не будем.
SY, Andrey Petrov.