Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

> Вот оно! Вот от куда goto появляется! из блок-схем.
> Порочная система проектирования.

Извините, ваше утверждение, что "блок-схемы === порочная система проектирования", это я надеюсь, ирония ? Или вы действительно так считаете?

Блок-схемы. Нас еще в 1979 году от блок-схем отучали вследствие их порочности. Тогда же изучали основы структурированного программирования. И научили-таки вместо блок-схем пользоваться "псевдокодом", проектированию "сверху-вниз" и пр. А блок-схемы - действительно додейкстровская эпоха. Как раз для ниспровергателей основ годятся. Отсюда и выводы о невозможности обойтись без GO TO. PS: если уж Дейкстра устарел, то как блок-схемы остались актуальными?

Нас наверное несколько по разному учили. Потому что иначе крайне трудно объяснить использование мною блок-схем и крайне редкое использование мною goto (только в критических участках, за последний год - 1 раз).

Кроме того USDP (разработанный в 1998 если не ошибаюсь) базируется на использовании UML, который крайне сходен с блок - схемами.
Да и проектированию "сверху-вниз" блок-схемы ничуть не мешают, а налгядность при общении между несколькими разработчиками дают очень высокую.

Хотя также вполне вероятно, что я просто путаюсь в терминологии и под блок-схемами понимаю нечто другое. :)

to anonymous (*) (2003-02-18 01:35:13.289) :

>Ну-ка нука, поподробнее.

Возьми жабу да попробуй :)

>>Ты есче скажи что деструкторы всегда вызываются "при выходе из scope"
>Ну-ну. Продолжаем бредить, да?

Ну выдели память под объект через new, и продолжай бредить.


>> По моему мы говорим о разных вещах.
>Я говорю о том, что finally нах не нужен и является костылем.

Ага то-то народ из Borland __try\__finally в BC втиснули :)
Инвалиды наверно, костыли любят :)))

>> Кстати, C++ это не всегда классы и OOP - это на случай если ты
>>не знал :)

>Ну дык может просветите? А то пиздить-то не мешки ворочать.

Вопрос тебе на засыпку : "А можно ли писать на C++ без использования классов ?" :)

>Да ради бога. Только это работает до тех пор пока объект не был создан
>динамически.

>Ваши знания С++ на динамических объектах заканчиваются?
>Про smart-pointerы таки слышали?

Это ты про _com_ptr_t ? :)))

"сверху-вниз" проще на псевдокоде. Для этого достаточно любого текстового редактора. А USDP в 1979 году еще не было. Как, впрочем, и PCшек. Поэтому писать программы приходилось на бумаге. Тут тоже в псевдокоде проще.

2 MrBool (*) (2003-02-18 01:11:58.805)

>Да ради бога. Только это работает до тех пор пока объект не был создан динамически

Хмм.. дорогой :))) немного перегибаешь палку. Можно ведь использовать функциональное замыкание, да и те же умные указатели.. Так, что IMHO, не все так плохо. :)))

> "сверху-вниз" проще на псевдокоде. Для этого достаточно любого текстового редактора.
Спорный вопрос. Для блок-схем достаточно карандаша и бумаги.

> А USDP в 1979 году еще не было. Как, впрочем, и PCшек.
> Поэтому писать программы приходилось на бумаге.
> Тут тоже в псевдокоде проще.
Вполне может быть, что и проще (хотя мой опыт работы в группе доказывает обратное, если вам интересно, могу развить тему), но как мне казалось мы обсуждаем не то, как писали/проектировали ПО в 1979 году, а то как нужно/желательно это делать сейчас. А в этом случае имеет смысл рассматривать и UML, и USDP.

>>Для блок-схем достаточно карандаша и бумаги.
Да. Для того, чтобы ее нарисовать. Но для того, чтобы ее детализировать....

>>...а то как нужно/желательно это делать сейчас
Точнее - как это ВОЗМОЖНО сейчас. А "нужно/желательно".... Тут я не согласен. И тоже могу дальше развивать тему, но зачем?

to Alter :

>Хмм.. дорогой :))) немного перегибаешь палку. Можно ведь
>использовать функциональное замыкание, да и те же умные
>указатели..

Можно так же прицепить gc :) Но это все так сказать не
стандарт языка, а навороты вокруг да около, которые не
факт что будут всегда корректно работать при смене
компилера на той же самой платформе. Да и аноним
вобще от темы отошел, он мои знания тестирует :0)

>Так, что IMHO, не все так плох

Мне нехватает finally в C++ (очень редко :)

Вам хочется алгоритмов - их есть у меня (с) фильм :)

#include <stdio.h>

void print_vec(int *v, int n){
int i;
for(i = 0 ; i < n ; i++) printf("%d ", v[i]);
printf("\n");
}

#define n 3

int main(){
int N[n] = {3,4,2};
int j[n] = {1,1,0};
int k = n - 1;

do{
j[k] = j[k] + 1;
if( j[k] <= N[k] ){
print_vec(j, n);
k = n - 1;
continue;
}else{
j[k] = 1;
k = k - 1;
}
}while( k >= 0 );

return 0;
}

[ivan@onix ivan]$ vi temp/dec.c
[ivan@onix ivan]$ gcc -o dec temp/dec.c
[ivan@onix ivan]$ ./dec
1 1 1
1 1 2
1 2 1
1 2 2
1 3 1
1 3 2
1 4 1
1 4 2
2 1 1
2 1 2
2 2 1
2 2 2
2 3 1
2 3 2
2 4 1
2 4 2
3 1 1
3 1 2
3 2 1
3 2 2
3 3 1
3 3 2
3 4 1
3 4 2
[ivan@onix ivan]$

Надеюсь вывод программы это то что нужно получить ?

Этот вариант без лишних проверок, дублирования и прочих недостатков.
Кроме этого его ГОРАЗДО легче прочитать и понять, чем вариант с GOTO.
Что лишний раз и подтверждает, что очень часто использование
безусловного перехода происходит от недопонимания сути алгоритма.

Хм, извиняюсь за предыдущее, должно быть так

#include <stdio.h>

void print_vec(int *v, int n){
	int i;
	for(i = 0 ; i < n ; i++) printf("%d ", v[i]);
	printf("\n");
}

#define n 3

int main(){
	int N[n] = {3,4,2};
	int j[n] = {1,1,0};
	int k = n - 1;

	do{
		j[k] = j[k] + 1;		
		if( j[k] <= N[k] ){
			print_vec(j, n);
			k = n - 1;
                        continue;
		}else{
			j[k] = 1;
			k = k - 1;
		}
	}while( k >= 0 );

	return 0;
}

2 MrBool
>Мне нехватает finally в C++ (очень редко :)

Хотя, да. :))). Чуть посмотрев log dev/brain нашел прилично случаев, когда __try & __finally мне значительно упрощали жизнь :))). С другой стороны, если компайлер поддерживает шаблоны, то проблемы с динамическим созданием объектов должны решаться "легко и непренужденно" (с), а вот GC в С++ ну никак не могу одобрить - лень-матушка народ заест так, что он и думать перестанет, а "сие чревато" (с). :)))

> Точнее - как это ВОЗМОЖНО сейчас. А "нужно/желательно".... Тут я не согласен.

Насколько я понимаю, в данном треде не просто предлагаются разные парадигмы разработки ПО (кодирования, проектирования, дизайна и т.д.), а делаются попытки объяснить, чем тот или иной способ качественно лучше и почему не надо или нежелательно использовать другие.

> И тоже могу дальше развивать тему, но зачем?
А зачем вы вообще что-то пишите в данные форумы? Это не ирония, мне действительно интересно.

to anonymous (*) (2003-02-18 06:54:45.307) :

О, тебя-то я просмотрел  ;)

>Скажем, не при завершении, а когда-нибудь.

:)

-------------------------------------------------------
public class Test {
	
	public int test() {
		
		 try {
		    System.out.println("try{}");	 
		    System.out.println("return 1");
 		    return 1;
		 }
		 finally {		 	
		    System.out.println("finally{}");	 
		 }
// Unreachable code		 
//		 System.out.println("return 2");	 
	}
	
	protected void finalize() throws Throwable
	{
	   System.out.println("finalize()");
	}
	

	public static void main(String[] args) {
		
	Test test = new Test();
        System.out.println("test.test()="+test.test());
	}
}

to anonymous (*) (2003-02-18 06:54:45.307) :

Че-то обрезалось :(

-----------------------------------------------------------
output:

try{}
return 1
finally{}
test.test()=1

to anonymous (*) (2003-02-18 06:54:45.307) :

Млять, "Preformatted text" глючит ! :(

>И, по-моему, в яве можно заблокировать вызов finalyze...
>Хотя не уверен

:)

Сюда : http://www.javable.com/javaworld/08_99/03_QA/

А вот и рекурсивный вариант.

#include <stdio.h>

void print_vec(int *v, int n){ int i; for(i = 0 ; i < n ; i++) printf("%d ", v[i]); printf("\n"); }

#define n 3

void dec(int *v, int *N, int k){ int i;

if( k < n ){ for( i = 1; i <= N[k]; i++){ v[k] = i; dec(v, N, k+1); } }else{ print_vec(v, n); } }

int main(){ int N[n] = {3,4,2}; int j[n];

dec(j, N, 0); return 0; }

Блин, ну это уже традиция такая - постить с глюком :), исправляюсь...

#include <stdio.h>

void print_vec(int *v, int n){ int i; for(i = 0 ; i < n ; i++) printf("%d ", v[i]); printf("\n"); }

#define n 3

void dec(int *v, int *N, int k){ int i;

if( k < n ){ for( i = 1; i <= N[k]; i++){ v[k] = i; dec(v, N, k+1); } }else{ print_vec(v, n); } }

int main(){ int N[n] = {3,4,2}; int j[n];

dec(j, N, 0); return 0; }

Блин, ну это уже традиция такая - постить с глюком :), исправляюсь...

#include <stdio.h>

void print_vec(int *v, int n){
	int i;
	for(i = 0 ; i < n ; i++) printf("%d ", v[i]);
	printf("\n");
}

#define n 3

void dec(int *v, int *N, int k){
	int i;

	if( k < n ){
		for( i = 1; i <= N[k]; i++){
			v[k] = i;
		        dec(v, N, k+1);
		}
	}else{
		print_vec(v, n);
	}
}

int main(){
	int N[n] = {3,4,2};
	int j[n];

	dec(j, N, 0);
		
	return 0;
}

2 eugine_kosenko

Это ж надо было такое наваять:

----------------------------------------------------- А идея с рекурсией оказалась очень плодотворной!

Доказано, что всякая простая (хвостовая) рекурсия эквивалентна итеративному решению. На этом основаны отдельные виды оптимизации кода.

Однако, кроме простой существует еще сложная рекурсия, которая принципиально не сводится к итеративным решениям, чем она и живет. ----------------------------------------------------

Да, путаница еще та... Есть понятие простой рекурсии - когда рекурсивный вызов встречается в функции один раз, есть понятие сложной - когда более одного.

Хвостовая рекурсия - это частный случай простой рекурсии, когда результаты и параметры рекурсивного вызова далее в функции не используются, как раз она приводима к итерации. Пример хвостовой рекурсии - печать (в общем виде проход по) списка - [печать: если список не пуст напечать голову, затем вызвать "печать" с параметром - хвост списка]. Понятно, что такая функция элементарно заменяется циклом. Пример нехвостовой - обход двоичного дерева без обратных ссылок (на родителя). [печать: если дерево не пусто напечатать узел, вызвать "печать" с левым потомком, затем вызвать "печать" с правым потомком]

Главный момент здесь - необходимость сохранять указатель на текущий узел после первого рекурсивного вызова. Такая рекурсия приводима к итерации с использованием дополнительного стека.

-------------------------------------------------------------- Но!.. Можно выдвинуть следующую гипотезу:

Всякая сложная рекурсия эквивалентна итеративному решению с использованием оператора безусловного перехода.

Кто возьмется это доказать? Или это уже доказано? ----------------------------------------------------

В свете вышеизложенного ПОЛНЫЙ БРЕД, берусь доказать обратное :)

---------------------------------------------------- Если эта гипотеза справедлива, то из нее следует один интересный момент. Пожалуй, самым весомым аргументом против goto является то, что он создает множество точек выхода из конструкции, и тем самым становится невозможным вычисление слабейших предусловий (по Дийкстре). Однако, в таком случае можно говорить о том, что сложная рекурсия также неверифицируема по Дийкстре! Значит ли это, что сложную рекурсию нужно предать анафеме и запретить ее использование в программировании? -----------------------------------------------------

Ну а это закономерное следствие предыдущего бреда. Апофеоз апофегея (с) не мой.

eugine_kosenko (*) - Подучиться бы вам, товарищ.

nst (*) (2003-02-18 15:39:37.296): Бывает, поначалу захватывает спор. А когда начинаются самоповторы и/или переход на личности, интерес угасает. Ну и еще одно условие - есть перерыв в работе.

4MrBool: так бы и сказал сразу: "не знаю я, чо такое смарт пойнтеры". Так ведь нет. Ни один ни в жисть не признается. Лажаться будет - а не признается. Это я сделал вывод из твоих слов о непереносимости.

L.

> 1)оператор goto ухудшает читабельность листинга, а не улучшает его.
Линус и Кнут думают иначе. При прочих равных верим им, а не AVL2.

> 2)оператор goto не является необходимым
Как собственно и for при наличии while?

> 3)оператор goto делает программу неоптимизируемой.
Любопытное заявление, требующее доказательств, не находите?

> 4)оператор goto - это всегда потери из за остановки в конвейере
Оператор goto - это то же, что и if c предопределённым результатом сравнения, и точно так же обрабатывается branch prediction логикой.

> Это не значит, что безусловный переход не появляется в маш. коде.
> В среднем через каждые пять инструкций происходит условный или
> безусловный переход, но в языке высокого уровня goto давно уже
> персона non grata.
Bullshit.

> ЗЫ Исключения значительно лучше оптимизируются для предсказателя
> переходов и логически легче воспринимаются.
Как и это.

> А насколько я знаю, еще когда компьютеры были большими а программеры
> пробивали перфокарты, было доказано что нет такого алгоритма который
> нельзя было бы реализовать без goto. Читайте структурное
> программирование оно рулит.
Насколько я знаю, этого и никто не отрицал. Вопрос лишь в том, насколько догматическое отрицание goto как такового оправдано на практике. Учитесь читать, маленький знаток Дейкстры, грамотность - она тоже рулит.

2vada:
> Но!!! Есть такая наука КИБЕРНЕТИКА
К вам, очевидно, не относящаяся.

> Так вот, уважаемый Юрий Фролов, Если ваш замечательный и красивый код
> имеет Ваш любимый оператор goto, то получается, что у Вас, как
> минимум, два блока у которых входов, и выходов не два.
Зависит от метода разбиения, очевидно. В простейшем случае ислходный блок разбивается на два под-блока, до и после goto.

Не хотел бы я чтобы вы ДОКАЗЫВАЛИ ПРАВИЛЬНОСТЬ моего кода.

Да, я не Юрий Фролов, но решил таки вмешаться.

P.S. Вы всегда кричите на публике?

> Насколько я понимаю, чтобы TCP стек был оптимален на многопроцессорных
> системах он должен быть многопоточный. Но уважаемые BSD'шнико
> обьясните мне пожалуста как может разбор протокола закрученый в одну
> функцию быть многопоточным? Либо Вы ламо и не шарите либо в BSD TCP
> стек однопоточный.
Объяснять бы не стоило, ибо случай клинический, однако... Не приходило ли в голову достопочтенному джинну, что одна и та же функция может исполняться на нескольких процессорах сразу для нескольких пакетов от нескольких сетевых карт?

Либо Вы ламо и не шарите ...

2kraw:
Это скорее ответ на вопрос "почему". :)
А меня интересовало именно "зачем", сейчас правда желание развить тему тоже несколько ушло.
Но все равно, спасибо за ответ.

to L:

>так бы и сказал сразу: "не знаю я, чо такое смарт пойнтеры".

Самое смешное что я знаю что такое smart-pointers
только без темплейтов это по серьезному не юзабельно
и вот тут-то нас ожидают сюрпризы. Какие ? Вот это
тебе останется в качестве домашнего задания :0)

>Так ведь нет. Ни один ни в жисть не признается.

Насчет free(NULL) я вроде признал. Или ты это влегкую
скипанул ?

>Лажаться будет - а не признается.

:0))

> Это я сделал вывод из твоих слов о непереносимости.

Это еще вопрос кто облажался :)

Короче, удостоверься собственными глазами здесь :

http://subscribe.ru/archive/comp.prog.visualc/200204/21095006.html

---[cut]---
ПРИМЕЧАНИЕ

По причине использования конструкций типа
std::vector<str::auto_ptr<T> > проект не будет
компилироваться, если используется современная версия STL.
Кроме того, в примере используется новая версия библиотеки
ввода-вывода Microsoft, несовместимая с STL от SGI.
---[cut]---

Будем дальше пиписьками меряться ? :0)

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

>Зависит от метода разбиения, очевидно. В простейшем случае ислходный блок
>разбивается на два под-блока, до и после goto.

До и после метки, очевидно ?

goto - позволяет не тлолько выходить из любого количества вложенных блоков но и входить ;)
И вот в этом случае такое разбиение на блоки не всегда возможно,
Один из блоков, тот который включает метку может оказаться с двумя входами ...

to Alter :

>а вот GC в С++ ну никак не могу одобрить - лень-матушка народ
>заест так, что он и думать перестанет, а "сие чревато" (с).
>:)))

Lisp, Java, Oberon, C# для ленивых ? 8)

Правда мне больше нравится подход в Ada.Там наличие gc не
умаляет достоинства освобождения памяти вручную. Кроме того
можно работать с собственными пулами памяти (Storage Pools)
не особо изголяясь.

http://www.stsc.hill.af.mil/crosstalk/1997/06/databases.asp

2anonymous (*) (2003-02-18 19:31:57.617)

>> А насколько я знаю, еще когда компьютеры были большими а программеры
>> пробивали перфокарты, было доказано что нет такого алгоритма который
>> нельзя было бы реализовать без goto. Читайте структурное
>> программирование оно рулит.
>Насколько я знаю, этого и никто не отрицал. Вопрос лишь в том, >насколько догматическое отрицание goto как такового оправдано на >практике. Учитесь читать, маленький знаток Дейкстры, грамотность - она >тоже рулит.
>
>anonymous (*) (2003-02-18 19:31:57.617)

Для особо нудных анонимусов привожу цитату:
"Насколько я знаю, алгоритм решения следующей задачи невозможно реализовать без goto: [skiped]
eugine_kosenko (*) (2003-02-16 23:32:00.773)"

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

anonymous (*) (2003-02-19 00:32:47.097):
> Что с блеском было и опровергнуто вчастности, ...
Замечу, что реализация алгоритма, предъявленная ignite (*) (2003-02-18 15:02:03.635),
выдает результат ОТЛИЧНЫЙ от того, что дает алгоритм
eugine_kosenko (*) (2003-02-17 23:44:34.18).

А что требовалось - извините, лень разбираться. Во всяком случае, это
не декартово призведение.

>> 1)оператор goto ухудшает читабельность листинга, а не улучшает его.
>Линус и Кнут думают иначе. При прочих равных верим им, а не AVL2.
верить можно богу. а насчет остального надо думать, мой маленький сотворитель кумиров...

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


>> 2)оператор goto не является необходимым
>Как собственно и for при наличии while?
ага. но если бы он был необходим, то и вопросов бы не было. Жри, что дают. а так смотрим дальше.


> 3)оператор goto делает программу неоптимизируемой.
Любопытное заявление, требующее доказательств, не находите?

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

>> 4)оператор goto - это всегда потери из за остановки в конвейере
>Оператор goto - это то же, что и if c предопределённым результатом >сравнения, и точно так же обрабатывается branch prediction логикой.

а разбираться с экстренным выходом из того же цикла и одновременным влетом в середину другого уже не будем?

Остальное подсказывает, что основным оптимизирующим моментом по твоей логике является смена компьютера. :(

Задолбали офтопиком. Одно и то же по кругу. Создали вечный
цикл. Ничего другого не остается, как сказать: goto out!
Вот вам и оправдание в пользу goto ;)

> А что, трудно догадаться, что пересечения конструкций без правил и логики превращают заранее разобраные логические конструкции (главное, циклы) в неоптимизируемую кашу?

Господин AVL2, видимо, не представляет себе, как и когда работают оптимизаторы. Во всех (мне известных) компиляторах оптимизация выполняется, когда все структурные конструкции уже преобразованы в последовательности условных и безусловных переходов, то есть, по его словам, "в неоптимизируемую кашу".

to Last anonymous:

Ну-ка, ну-ка :))
Как гриться - марш в избу-читальню.
Это как вы предполагаете loop unrolling и strength reducing без
явного указания циклов ? :))

Честно говоря, форумы LOR меня поражают. Все во всем специлисты.
Лучше анекдот ру :). finally в яве можно заблокировать, да еще
корка с деструкторами - давно я так не смеялся :)))

А по поводу goto - в нормальных языках есть прямое и правильное
решение их проблемы. Называется continuations. Вот как раз на них
то сопрограммы и пишутся.

Кроме того, второй вариант реализации сопрограмм - два потока. 
Зачем goto-то ?

ARia

2 Die-Hard

Замечу, что реализация алгоритма, предъявленная ignite (*) (2003-02-18 15:02:03.635), выдает результат ОТЛИЧНЫЙ от того, что дает алгоритм eugine_kosenko (*) (2003-02-17 23:44:34.18).

А что требовалось - извините, лень разбираться. Во всяком случае, это не декартово призведение.

--------------------------------------------------------------------

Да, логика железная - выдает не то что нужно, а что нужно - не знаю.

Курам на смех, (мне даже не смешно - грустно).

> Ну-ка, ну-ка :)) > Как гриться - марш в избу-читальню. Это как вы предполагаете loop unrolling и strength reducing без явного указания циклов ? :))

Ага. Марш в избу-читальню. Steven S. Muchnik. Advanced Compiler Design & Implementation. Когда прочитаете, тогда возвращайтесь и больше таких глупостей не пишите.

Вам я посоветую не всякое гавно читать, а http://cs1.cs.nyu.edu/leunga/www/MLRISC/Doc/html/index.html Особенно, касаемо SSE http://www.cs.virginia.edu/zephyr/vpo/ Плюс, поискать на Microsoft Research и на SRI касательно program transformation. + Поискать на тему Specializers.

После этого стоять в углу и плакать :)))

На том же уровне, что вы указали, возможно лишь небольшое количество низкоуровневых оптимизаций, типа instruction scheduling.

Большинство же оптимизаций так или иначе выполняются на графе исполнения кода. Причем срабатывают они с помощью паттерн матчинга. So чем регулярнее будет граф, тем эффективнее будет оптимизация.

ARia

Вам я посоветую не всякое гавно читать, а
http://cs1.cs.nyu.edu/leunga/www/MLRISC/Doc/html/index.html
Особенно, касаемо SSE
http://www.cs.virginia.edu/zephyr/vpo/
Плюс, поискать на Microsoft Research и на SRI касательно program
transformation. 
+ Поискать на тему Specializers.

После этого стоять в углу и плакать :)))

На том же уровне, что вы указали, возможно лишь небольшое
количество низкоуровневых оптимизаций, типа instruction scheduling.

Большинство же оптимизаций так или иначе выполняются на графе исполнения кода. Причем срабатывают они с помощью паттерн матчинга.
So чем регулярнее будет граф, тем эффективнее будет оптимизация.

ARia

2 MrBool :))

>Lisp, Java, Oberon, C# для ленивых ? 8)
Oops! :))) Не для ленивых - для умных. :)) Ага, точно..:)) J2EE для ленивых.. :)))

Ну _сложно_ мне GC в С++ представлять :)). Может стереотипы, но непросто привычной образ мышления перестраивать.

Насколько вкусна Ada?

> Вам я посоветую не всякое гавно читать...

А Вы читали? Или в лучших традициях: сам я не читал, но думаю что...

> графе исполнения кода

Скажите, как это звучит по-английски?

Если там написано, что высокоуровневой оптимизации нет, то автор явно не знает, о чем пишет.

Если не написано, значит вы плохо читали.

BTW, читать стоит не устаревшие книги, большинство из которых пиано ламерами для ламеров, а классику (Ульман, Ахо) + научные статьи по теме (хотя бы с research index).

Тогда и таких безаппеляционных высказываний не будет.

ARia

Control Dependence Graph (в частности, для распараллеливания) Вообще говоря, Execution Graph

Граф исполнения кода - этот термин пробегал в каких-то русских лекциях по параллельным вычислениям, вот в голову и запал :)

ARia

to Alter :

>J2EE для ленивых.. :)))

Нюню, без тулзов запаришся дескрипторы к ej beans писать.

>Ну _сложно_ мне GC в С++ представлять :)).

А мне нет, кроме того помнится в свое время Тутубалин
gc к C прикрутил :)

>Насколько вкусна Ada?

Для начала :

http://www.ada-ru.org/
http://faqs.org.ru/progr/other_l/adafaq.htm
http://qnx.org.ru/forum/viewtopic.php?topic=342&forum=10&111

> BTW, читать стоит не устаревшие книги, большинство из которых пиано ламерами для ламеров, а классику (Ульман, Ахо) + научные статьи по теме (хотя бы с research index).

Совок неистребим. Сам я не читал, но думаю что... :-)))

Не поленитесь, сходите на amazon.com и посмотрите, какого года издания Muchnik, а какого года издания Aho. В следующий раз Вы такие глупости писать не будете. Сходите на researchindex и посмотрите индекс цитирования для Мучника (это по поводу ламеров для ламеров).

И не смешите больше мои тапочки!

И если Вы никогда не слышали про упомянутую книгу Мучника, я сомневаюсь, что Вы когда-либо серьёзно занимались компиляторами.

Ну, во первых, прежде чем кидать пальцы, научитесь правильно писать.
Muchnick, а не Muchnik.
Во-вторых, советую вам перечитать страницы со 669 по 775.
А то получается, слышал звон, да не знаю, откуда он 

ARia

По ходу дела, судя по ri, Мачник как раз специалист по низкоуровневой оптимизации (типа скедьлинга).

Да, еще не забывайте, что Мачников много :))) как раз на RI.

ARia