[philosophy] В чем заключается революционность перехода от функциональщины к ООП?

А даже если ввел до компиляции? (в файл)
можно будет плюсовыми шаблонами получить это значение?

Где? в статье не нашел, в комментах?

В статье человек подумал использовать ленивость для того же, для чего используют макросы (withFile тот же), т.е. утверждал о взаимозаменяемости второго первым. Ну а в коментариях появились, помимо прочих, Peter Seibel и один из основателей Symbolic и раскрыли человеку глаза (он признал свою ошибку).

макросом, как минимум, можно по одному коду сгенерить другой код

да, всё верно, об этом и речь.

Присоединяюсь к вопросу, а что такое «ООП на замыканиях»?

SICP / 3 глава - рекомендую :) Для scheme есть даже ООП «фреймворки» на этой основе.

> в файл

Если исходников, что-нибудь в роде «const int n = 10;», то почему бы и нет? ))

ну лол, это читерство

А ты как думал? Думаешь, творение Влора будет белым и в костюмчике? ;))

Если исходников, что-нибудь в роде «const int n = 10;», то почему бы и нет? ))

Ну, для совсем на голову нездоровых можно и так:

MigMit:~ MigMit$ cat test.cpp
#include <iostream>
const int n =
#include "test.h"
;
int main() {
  std::cout << n << std::endl;
  return 0;
}
MigMit:~ MigMit$ cat test.h
10
MigMit:~ MigMit$ g++ test.cpp -o test
MigMit:~ MigMit$ ./test
10

А это точно будет на всех реализациях работать?

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

чтобы эти 2 случая имело смысл различать, должен существовать гипотетический, но реализуемый компилятор, который сможет «использовать это знание»

приведи пример такого компилятора

хинт: привести пример невозможно, если в том примере int foo(int) throw(); тебе придется загнать константы в сигнатуру либо прямо int foo(Int<0,15>) throw() либо через придумывание класса

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

Ты не сможешь определить Int<0, 15>, проверяемый на этапе компиляции, так что твое «нихрена компилятор не знает» просто нелепо.

ты о чем?

проверка введеного юзером значения будет, и в обоих примерах приведет к return;

однако разница в том, что во втором случае, если убрать рантаймовую проверку, то компилятор с этим может не согласится;

впрочем, g++ -Wall -Wextra молча соглашается с кодом

int f(int i) throw() { if(i==0) throw(123); return i; }

запихнуть же проверки внутрь каждой функции менее выгодно, чем один раз проверить аргумент (как с точки зрения скорости, так и с точки зрения читабельности)

А это точно будет на всех реализациях работать?

Да куды ж ему, на хрен, деться?

А ты как думал? Думаешь, творение Влора будет белым и в костюмчике? ;))

в светло-сером в крапинку костюмчике :-) уже щас можно покритиковать код с mapcar

а трюки типа

#include <iostream>

const int n=
#include "/dev/stdin"
;

int main()
{
    std::cout << n;
    return 0;
}

мне как-то чужды

> уже щас можно покритиковать код с mapcar

Ага, его только прочитать осталось.

> Мы ждем от влора шаблон-телепат, предсказывающий ввод пользователя.

1. не будет от меня шаблона-телепата — тот шаблон позволяет всего лишь объяснить то, что |a+b+c+d+e|==|a+e+d+b+c|

2. шаблон будет, но не в этой ветке, сорри.

> Ага, его только прочитать осталось.

ну а что ты хотел? тут у нас не Первый канал, так что обосрать не прочитав не получится.

Присоединяюсь к вопросу, а что такое «ООП на замыканиях»?

SICP / 3 глава - рекомендую :) Для scheme есть даже ООП «фреймворки» на этой основе.

Тогда понятно. Вообще, я в оригинале читал ту главу. Что-то такого термина не припомню.

> Я всё еще жду реализации вот этого:

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

Я тоже этого жду.

>> Я сказал, что есть способ дать компилятору знать, какое значение ввел пользователь. Я _не_ говорил, способен ли какой-нибудь существующий компилятор использовать это знание.

должен существовать гипотетический, но реализуемый компилятор, который сможет «использовать это знание»

приведи пример такого компилятора

То есть ты сомневаешься в принципиальной вожзможности? O_O Почему?

Пример именно компилятора не приведу, но как минимум 2 тайпчекера для Python декларируют распознавание конструкций вида assert isinstance(obj, Foo) и использование их для вывода типа obj (PyDev и Pyntch). Надеюсь, принципиальной разницы между assert isinstance(obj, Foo) и if (0 <= v && v <= 15) ты не видишь?

Ты не сможешь определить Int<0, 15>, проверяемый на этапе компиляции, так что твое «нихрена компилятор не знает» просто нелепо.

ты о чем?

Я о том, что мне лично непонятно, что такое Int<0, 15>. Ты вроде претендуешь на то, что это целочисленный тип, ограниченный 0..15, присваивания которому _статичнески_ проверяются компилятором? Если да, то пример в студию. Если нет, то твой компилятор тоже нихрена не знает.

Я о том, что мне лично непонятно, что такое Int<0, 15>. Ты вроде претендуешь на то, что это целочисленный тип, ограниченный 0..15, присваивания которому _статичнески_ проверяются компилятором? Если да, то пример в студию. Если нет, то твой компилятор тоже нихрена не знает.

Интересно, а как с этим обстоят дела в Аде? Там можно объявлять такие типы, насколько помню. Может быть, их компиляторы достаточно умны, и некоторые статические проверки действительно делаются на этапе компиляции. Интересно было бы узнать мнение тех, кто работал с Адой, если таковые, вообще, читают этот топик, в чем я сильно сомневаюсь ;)

> Интересно, а как с этим обстоят дела в Аде?

Насколько я понимаю, там вводиться новый тип «целое 0..15», и для присваивания значению этого типа другого целого нужно явное преобразование. Т.е. примерно так же, как можно сделать в Си++.

>> Я сказал, что есть способ дать компилятору знать, какое значение ввел пользователь. Я _не_ говорил, способен ли какой-нибудь существующий компилятор использовать это знание.

чтобы эти 2 случая имело смысл различать, должен существовать гипотетический, но реализуемый компилятор, который сможет «использовать это знание»

Вы съезжаете с темы в идиотский разговор о возможностях компилятора по части оптимизаций.

Везде выше по топику выражение «компилятор знает» означает возможность _программиста_ использовать значение в вычислениях времени компиляции.

Конкретный пример:

#include <iostream>

int main(int argc, char **argv)
{
	int n;
	std::cin >> n;
	// Ритуал чёрной магии производится тут.
	static int array[n];
	return 0;
}

Всем всё понятно? ;)

> Вы съезжаете с темы в идиотский разговор о возможностях компилятора по части оптимизаций.

Не участвуй в идиотских разговорах, делов-то.

Так я и забочусь о том, чтобы разговор не стал идиотским. Разве не видно? :3

Т.е. ты говоришь что комплятор может (хоть и в теории) использовать значение, который пользователь должен будет ввести ПОСЛЕ компиляции?

> Т.е. ты говоришь что комплятор может (хоть и в теории) использовать значение, который пользователь должен будет ввести ПОСЛЕ компиляции?

Формально - да. Фактически, конечно, прогер просто скажет компилятору «мамой клянусь, значение будет таким-то».

> Формально - да.
Вот теперь покажи, как это возможно.
Код такой:
main {
n = input_from_user
...
Здесь компилятор должен _использовать_ значение n
...
}

Фактически, конечно, прогер просто скажет компилятору «мамой клянусь, значение будет таким-то».

Это если только 1 значение, а если несколько?

> Вот теперь покажи, как это возможно.

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5046401

Ты что, видишь там какую-то логическую дыру?

Фактически, конечно, прогер просто скажет компилятору «мамой клянусь, значение будет таким-то».

Это если только 1 значение, а если несколько?

А какая разница? Любой число, заранее известное прогеру:

if (0 <= val1 && val1 <= 15 && 0 <= val2 && val2 <= 16 /* ... */) {

/* здесь мы можем полагаться на то, что значения val и val2 ограничены */

}

Подозреваю, что возможно даже ограничить любое количество значений - операцией над массивом.

> Ты что, видишь там какую-то логическую дыру?

/* Всё, здесь и далее - уже сообщили, что всегда (0 <= x < 16) */

Отлично, мы знаем что введенное значение будет меньше нуля, но значение мы не знаем, значит и использовать не можем.

/* здесь мы можем полагаться на то, что значения val и val2 ограничены */

Ограничены, да пожалуйста. Это можно и с помощью системы типов сделать. Сказать, что n - unsigned int, вот и ограничили. Но значение мы _использовать_ не может, нет его

> Ограничены, да пожалуйста. Это можно и с помощью системы типов сделать

Это будет примерно то же самое, что написал я, только вместо if будет преобразование типа (потенциально бросающее исключение).

Но значение мы _использовать_ не может, нет его

Неужели?

if (n > 0) {

/* гарантированно не даст dvide-by-zero */ return 1./n;

}

А если по «использовать» ты имеешь в виду «использовать с целью $ЦЕЛЬ», то по крайней мере назови значение ЦЕЛЬ.

> return 1./n;

И это будет вычисленно на этапе компиляции?
Где здесь *компилятор* использует n?

Можно if(n>0) убрать, можно поставить, дополнительно компилятор ничего посчитать не сможет.

> ты имеешь в виду «использовать с целью $ЦЕЛЬ», то по крайней мере назови значение ЦЕЛЬ.

режим К.О. = старт

Любое значение, известное на момент компиляции, можно использовать в вычислениях времени компиляции.

режим К.О. = стоп

Простейший пример я привел выше. Если забыл, напоминаю, - объявить статический массив заданной размерности. ;)

>> ты имеешь в виду «использовать с целью $ЦЕЛЬ», то по крайней мере назови значение ЦЕЛЬ.

режим К.О. = старт

Любое значение, известное на момент компиляции, можно использовать в вычислениях времени компиляции.

В этом режиме оно использоваться вполне может.

Ну и как может использоваться _еще не введеное_ (и, следовательно, неизвестное) значение во время компиляции?

Хотеть! :D

Под словом «как» я подразумеваю «покажи» ))

if (n == 2) return n/2; /* оптимизируется в return 1 */

Причем это тривиально и уже сейчас возможно %) Наверное, ты о чем-то другом хотел спросить?

Ага!

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5049774

)))

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

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

в то время как я предлагаю в общем-то небольшое изменение, которое полезно

вот те 2 функции, специально чуть переписаны так, чтобы их можно было сравнить построчно

int foo(int); int bar(int); int baz(int);

void f() 
{ 
  int x = input_some_number();  
  if(x < 0 || x > 15) return;  /// вместо этой строки
  int u=foo(x); 
  int v=bar(x); 
  int w=baz(x); 
  ... 
}

int foo(Int<0,15>); int bar(Int<0,15>); int baz(Int<0,15>);

void f() throw()
{ 
  int tmp=input_some_number(); Int<0,15> x; 
  try{ x=Int<0,15>(tmp); } catch(OutOfRange) { return; } /// работает эта строка
  int u=foo(x); 
  int v=bar(x); 
  int w=baz(x); 
  ... 
}

Ты вроде претендуешь на то, что это целочисленный тип, ограниченный 0..15, присваивания которому _статичнески_ проверяются компилятором?

чуда нет — присваивание из int в Int<0,15> кидает исключение; профит *только* в том, что забыть написать строку с if нам никто не помешает, а забыть написать строку с try помешает нормальный компилятор (который следит за исключениями)

еще более умный компилятор мог бы даже принимать такое:

int foo(Int<0,15>); int bar(Int<0,15>); int baz(Int<0,15>);
 
void f() throw()
{  
  int x = input_some_number();   
  if(x < 0 || x > 15) return;  
  int u=foo(x);  
  int v=bar(x);  
  int w=baz(x);  
  ...  
}

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

> Ага!

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5049774

А что «ага»? Такое использование сейчас невозможно, но я не вижу причин, по которым его нельзя реализовать (за исключением тотальной бесполезности). Напоминаю, что изначально использование введенных юзером значений было упомянуто в разговоре о проверке типов.

> Ты вроде претендуешь на то, что это целочисленный тип, ограниченный 0..15, присваивания которому _статичнески_ проверяются компилятором?

одного взгляда на код с «catch(OutOfRange)» должно было бы хватить, чтобы понять, что это не так

> Формально - да. Фактически, конечно, прогер просто скажет компилятору «мамой клянусь, значение будет таким-то»

«мамой клянусь» не годится; прогер должен предъявить доказательство, которое компилятор может принять, а может и найти в нем ошибки

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

«мамой клянусь» не годится

В роли «мамой клянусь» - обычный if.

> В роли «мамой клянусь» - обычный if.

пиши свой вариант кода с функциями foo bar baz и говори, как компилятор поймет, что ты пропустил if

«компилятор» = «гипотетический, но без чудес и чОрной магии, компилятор»

> пиши свой вариант кода с функциями foo bar baz

void f(x) { foo(x); bar(x); baz(x); }

и говори, как компилятор поймет, что ты пропустил if

x не используется в if вообще (т.е. никак не ограничен), что там понимать?

>>> В роли «мамой клянусь» - обычный if.

и говори, как компилятор поймет, что ты пропустил if

x не используется в if вообще (т.е. никак не ограничен), что там понимать?

стоит ли что-то обсуждать в таком стиле? мне кажется не стоит.

> А что «ага»? Такое использование сейчас невозможно, но я не вижу причин, по которым его нельзя реализовать

Ну, если ты не понимаешь, что нельзя собрать ELF/COFF/etc, прописав размер bss сегмента, на основании тех данных, что будут введены пользователем в запущеный на исполнение это же elf/coff, не имея на руках машины времени, то у меня для тебя плохие новости...

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

Да что ты?

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5046164 :

а насчет маразма — меня интересует решение вот этой http://www.linux.org.ru/jump-message.jsp?msgid=4911022&cid=4912133 задачи

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5046197 :

есть класс Array, инстансы которого создаются с длинной, определяемой по вводу от пользователя,но далее неизменно;

Как видим, лично я хотел самый обычный array :))

> вот уже несколько человек ждут от меня какого-то чуда, ну или думают, что я его щас поведаю :-)

Вовсе нет. Несколько человек совсем не ждут от тебя чуда, но им чертовски интересно, как ты будешь выкручиваться. ;)))

чуда нет

Кто б сомневался.))

присваивание из int в Int<0,15> кидает исключение;

Т.е. - райнтайм. ЧТД.

профит *только* в том, что забыть написать строку с if нам никто не помешает, а забыть написать строку с try помешает нормальный компилятор

А юмор в том, что описанная тобою фигня является enum'ом. Мои поздравления! :D

> Т.е. - райнтайм. ЧТД.

между нереалистичным «телепатическим шаблоном» и «рантаймом» есть куча промежуточных (и реалистичных!) способов использования типизации; но я устал пытаться обратить ваше внимание на эти спосообы, так что продолжу как-нить в другой раз

в конце концов, тема — ООП, и там есть что пообсуждать кроме этого

> Ну, если ты не понимаешь, что нельзя собрать ELF/COFF, прописав размер bss сегмента, на основании тех данных, что будут введены пользователем

Ну, если ты не понимаешь, что речь не об этом...

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

Да что ты?

http://www.linux.org.ru/jump-message.jsp?msgid=5034750&cid=5046164 :

И? Пройди по ссылке и увидь текст, начинающийся с: «Есть класс Array, инстансы которого создаются с длинной, определяемой по вводу от пользователя».

Как видим, лично я хотел самый обычный array :))

Не-а. По-моему, ты хотел просто повыпендриваться своей практичностью.