[C++] Чего вам нехватает в языке?

> Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

Да, именно это и нужно.

Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL. Т.е. изменяемый синтаксис не мог разрушить все до основания.

> попробуй *определи* operator< для указателей

Зачем, если он _уже_ определен? А можно ли его перегрузить, нельзя ли его перегрузить - это уже проблемы плюсов, которые шерифа не волнуют.

без кастов к инту

А это каким боком к данной теме?

*заюзай* оператор - для указателей

Я не употребляю наркотики.

в каких книжках пишут, что для указателей на функцию есть оператор < ?

Я же взял название книги в кавычки. Если не знаешь авторов - Б. Керниган, Д. Ритчи.

вот нашел http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-linear-bestiary.pdf

>> без кастов к инту

А это каким боком к данной теме?

*только* в таком контексте обсуждение имело смысл

в каких книжках пишут, что для указателей на функцию есть оператор < ?

Я же взял название книги в кавычки. Если не знаешь авторов - Б. Керниган, Д. Ритчи.

И где они пишут о сравнении указателей на функцию? Цитату! (я нашел только вот это:

Если p и q указывают на элементы одного и того же массива, то такие отношения, как <, >= и т.д., работают надлежащим образом. Например, p < q истинно, если p указывает на более ранний элемент массива, чем q. )

> *только* в таком контексте обсуждение имело смысл

То, что было в контексте, само по себе не имело смысла. Так что и обсуждение этого в таком контексте точно так же не имеет смысла.

я нашел только вот это

Это оно и есть. Что тебя смущает?

>Я то с таким встречался, как и все, кто пытаются тебя образумить. А вот ты, видимо, нет.
В чём вы меня хотите образумить? Не пользоваться такой либой?

А полтреда про хэши кто заливал? Известный лётчик-ас Пушкин?

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

> поподрбнее плиз
Из-за необходимости неявной передачи аргумента this, указатели на функции члены отличаются от обычных указателей на функции. Довольно подробно вопрос описан здесь: http://www.rsdn.ru/article/cpp/fastdelegate.xml
Как я уже писал выше, это совершенно некритичная вещь, паттерн «наблюдатель» подходит для простых случаев, но для более сложных и универсальных уже придется городить огород, например такой: http://www.rsdn.ru/article/cpp/delegates.xml

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

> В чём вы меня хотите образумить?

Уже не хочу. Я пасс.

>Уже не хочу. Я пасс.
Боюсь Вы даже не захотели понять о чём я.

Потому-как даже процитировали только одну фразу.

> Это оно и есть. Что тебя смущает?

То, что указатели на функцию ( typedef int (*fun)(int); ) ну никак нельзя считать что «указывают на элементы одного и того же массива».

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

> что указатели на функцию ( typedef int (*fun)(int); ) ну никак нельзя считать что «указывают на элементы одного и того же массива».

Что значит «считать»? Они либо указывают, либо не указывают в зависимости от того, как ты их определил. Это программирование, а не выбор летнего платьица или штор в гостинную.

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

При чём тут «вычитание»?

И где они пишут о сравнении указателей на функцию?

Сравнение есть? Есть. Чего тебе еще надобно, старче?

> так всё-таки, как ты собираешься решать нарушение LSP?

например так (считаем, что над указателями нет адресной арифметики):

void Ellipse::set_axis(double x, double y) я воспринимаю как

Ellipse* set_axis(Ellipse* this, double x, double y) с постусловием this==set_axis(this, x, y)

LSP я воспринимаю как наличие Ellipse* set_axis(Circle* this, double x, double y) с тем же постусловием ((Ellipse*)this)==set_axis(this, x, y) — приведение происходит к базовому классу, поэтому законно

Кроме того, должно быть обеспечено наличие не более одно указателя вида Circle* на каждый круг (иначе будет плохо); это условие можно уточнить, используя что-нить типа capability calculus

а вообще это тема отдельного топика

> Сравнение есть? Есть. Чего тебе еще надобно, старче?

map<fun,std::string> требует оператор< про который К&R молчат

> Что значит «считать»? Они либо указывают, либо не указывают в зависимости от того, как ты их определил. Это программирование, а не выбор летнего платьица или штор в гостинную.

Ну попробуй определи 2 fun-а так, чтобы они указывали.

> с постусловием this==set_axis(this, x, y)

на всякий случай: подразумевается равенство именно указателей, *this==*set_axis(this, x, y) будет неверно (в общем случае)

> оператор< про который К&R молчат

Т.е. оператор «<», так же как «>» и «==» в таблице приоритета операций, тексте книги и примерах кода мне приснился?

map<fun,std::string> требует

Ну и что? Мало ли чего требуют потроха конкретного шаблона. Если шаблон будет делить на ноль, ты тоже будешь конкретизировать его на int и жаловаться на жизнь?

> Т.е. оператор «<», так же как «>» и «==» в таблице приоритета операций, тексте книги и примерах кода мне приснился?

КиР гарантируют его нормальную работу только тогда, когда оба указателя «указывают на элементы одного и того же массива», что всегда *неверно* в случае указателей на функцию ( typedef int (*fun)(int); )

точно с таким же успехом ты можешь делить на 0 — оператор / тебе не приснился, но его нормальная работа на 0 не гарантирована

заканчивай детский сад

Ну и что? Мало ли чего требуют потроха конкретного шаблона.

Они требуют того, что КиР не гарантируют. Так что КиР тут не поможет.

> Ну попробуй определи 2 fun-а так, чтобы они указывали.

Первый раз в первый класс?

void (*f[array_size])();

> что всегда *неверно*

Такое 4.2, что волосы встают дыбом. Ты никогда не слышал про массивы указателей?

заканчивай детский сад

Вот тоже самое хотел написать, веришь, нет? )))

> Такое 4.2, что волосы встают дыбом. Ты никогда не слышал про массивы указателей?

слышал и применял. попробуй уж скомпильни http://www.linux.org.ru/jump-message.jsp?msgid=4562164&cid=4565009 и успокойся

>> Ну попробуй определи 2 fun-а так, чтобы они указывали.

Первый раз в первый класс? void (*f[array_size])();

я просил 2 fun-а ( из typedef int (*fun)(int); ) а не тот тип, что ты придумал

Вот тоже самое хотел написать, веришь, нет?

а еще лучше попробуй вот это — не должно скомпилится

/* gcc -Wall -Werror -pedantic test4.c */

#include <stdio.h> 
typedef int (*fun)(int);

int f1(int i) { return 1; }
int f2(int i) { return 2; }

int main()
{
    int i=( f1<f2 );
    printf("%d\n", i);
    return 0;
}

> попробуй уж скомпильни

С таким же успехом я могу компилить содержимое /dev/urandom.
Внешне оно ничем не отличается.

> С таким же успехом я могу компилить содержимое /dev/urandom. Внешне оно ничем не отличается.

Логичным продолжением темы было бы сравнение содержимого твоих мозгов и...

Посмотри, там есть оператор < над указателями функций, про который (якобы) КиР нам рассказывали и который конечно тебе не приснился.

Ну и как результат компиляции? Со всеми указанными флагами и обязательным расширением .с (а не .схх или .срр)?

g++ компелирует.

А при чём здесь Си?

Этот код не только скомпилируется, но даже работать будет правильно на x86/x64. Но исключительно за счет черной магии, так что как демонстрация свойств языка он не годится.

> g++ компелирует.

ж++ понимает исходник как с++, а надо чтобы понимал как си.

> А при чём здесь Си?

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

test4.c:11: error: ISO C forbids ordered comparisons of pointers to functions

> Логичным продолжением темы было бы сравнение содержимого твоих мозгов

Не хочу тебя расстраивать, но содержимое моих мозгов ничем принципиально не отличается от содержимого мозгов любых других представителей вида homo sapiens. Все те же «серые клеточки», кора, полушария и всё такое...

Посмотри, там есть оператор < над указателями функций

Где? Где там указатели на функции? Ты разницу между указателем и адресом вообще понимаешь?

У меня стойкое ощущение, что ты чем-то обдолбан. )))

> типа мы тут си не знаем

Ну так и есть. Путать адрес с указателем, пытаться вычесть один указатель из другого, обнаружить операторы сравнения указателей на равенство и больше/меньше - и всё это за один тред!

По-моему, это рекорд на лоре.

> Ты разницу между указателем и адресом вообще понимаешь?

Терминология в русском языке не настолько стандартна.

> обнаружить операторы сравнения указателей на равенство и больше/меньше - и всё это за один тред!

Про равенство я ничего не говорил, не надо приплетать его сюда. А насчет сравнения на < вот пример http://www.linux.org.ru/jump-message.jsp?msgid=4562164&cid=4565840

>Так чтож ты сразу не сказал, что речь о гумне. Столько букв бы сэкономили.
А что-же дальше-то не процитировал?

> Про равенство я ничего не говорил, не надо приплетать его сюда.

Равенство идет бесплатным бонусом к сравнениям на больше/меньше.

А насчет сравнения на < вот пример

Это пример сравнения адресов.

>> Ты разницу между указателем и адресом вообще понимаешь?

Терминология в русском языке не настолько стандартна.

Нет, терминология в русском языка стандарта именно на столько. Если по всему интернету во всяких «самоучителях» и записях в бложиках путают одно с другим - это никак не означает, что «терминология не стандартна». Это означает, что авторы всех этих опусов не знают терминологии. И что самое печальное - не владеют предметной областью.

Это же семантически настолько же разные вещи как *указатель* и *значение указателя*.

Путать одно с другим - не понимать семантики указателей в принципе.

Посмотри к примеру перевод всё тех же K&R в исполнении Штаркмана. Там нигде нет путаницы между адресом и указателем. Тоже самое касается любой приличной книжки. Под «приличными книжками» я не имею ввиду выпушенные издательством «Фолио» или русские переводы Williams Publishing.

> стандарта

стандартна

Так предметная область ничем не ограничена.

Тогда это не предметная область.

Еще желательно чтобы какая-то информация (хотя бы об AST, приоритетах) была доступна (взглядом) даже тому, кто не знает сам DSL. Т.е. изменяемый синтаксис не мог разрушить все до основания.

В общем, язык может быть любым, если это Хаскель.

> выпушенные

выпущенные, ессно. ))

По-моему Вы перегибаете с педантичностью. Когда говорят о операциях с переменными, то подразумеваю операции над значениями. Указатель это обычная переменная, хранящая значение. Переменная это синоним значения.

>> Так предметная область ничем не ограничена.

Тогда это не предметная область.

Ок, каковы ограничения предметной области программирования?

Ок, каковы ограничения предметной области программирования?

Кто-то пишет один DSL для всех возможных применений программирования? Ну-ну, пока что это никому не удалось.

> По-моему Вы перегибаете с педантичностью.

Да ну?

Когда говорят о операциях с переменными, то подразумеваю операции над значениями.

Кто? Программисты на бейсике? Когда говорят об операциях над переменными подразумевают операции над переменными. А уж какие это операции - дело языка/модуля/библиотеки и т.д.

Переменная это синоним значения.

Это упрощение приемлемое только для бейсика (не VB). Ну может быть еще пары языков.

> Кто-то пишет один DSL для всех возможных применений программирования?

Это у вас надо спросить. ))

Я отвечал вот на это:

Поэтому нужен достаточно мощный язык, в который DSL-и будут удобно встраиваться БЕЗ его перекорёживания.

>Это упрощение приемлемое только для бейсика (не VB). Ну может быть еще пары языков.

Есть только две вещи: значение и адрес где оно лежит. Переменная в ЯП это синоним значения, адрес - адрес переменной. Есть другое понимание?

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

gcc с тобой не согласен: test4.c:11: error: ISO C forbids ordered comparisons of pointers to functions

> В общем, язык может быть любым, если это Хаскель.

В общем, язык может быть любым, если в нем можно устоить Хаскель как embedded DSL. // FIXED