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

> Например число в хеш таблице.

Число это число. Указатель это указатель. С какого хрена использовать указатель как число, и приводить его к более короткому целому?!?

>Число это число. Указатель это указатель. С какого хрена использовать указатель как число, и приводить его к более короткому целому?!?
Вы знаете как устроена хеш таблица?

>Особенно не нужны DSLы на C++.

Спасибо, К.О.!

Не надо прототипов. DSLы не нужны. Нужны языки, идеально интегрирующиеся в IDE.

Чувак, просыпайся! Парадигма Language Workbench уже давно не только придумана но и реализована. Man Jetbrains MPS ;)

> Вы знаете как устроена хеш таблица?

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

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

> Чувак, просыпайся! Парадигма Language Workbench уже давно не только придумана но и реализована. Man Jetbrains MPS ;)

Она там херовенько реализована, во первых. И во вторых сама парадигма дурацкая. DSL не нужны ни в каком виде, ни под каким соусом. Язык, который можно произвольным образом менять, это по определению write only язык. Никакая подсветка синтаксиса, типов и прочего не поможет, когда язык не читается в момент с листа визуально. Поддержка IDE это в первую очередь возможность бить кодера по рукам, когда он пытается умничать, а вовсе не потакание в этом самом умничаньи.

Слушай, ты что, совсем тупой? Повторяю ещё раз, для особенно одарённых, операция ((int)ptr) никакого отношения к приличной хеш-функции по определению не имеет, и на многих архитектурах просто будет тупо трапаться.

Другое дело - что-то вроде 0xffff&(ptr>>16). Никаких неявных преобразований, никаких идиотских предположений о размерностях целых и указателей.

Язык, который можно произвольным образом менять, это по определению write only язык.

Как раз наоборот. Опыт имеется ;)

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

DSL по оперделению читается лучше.

Она там херовенько реализована, во первых.

Сколько ты с ним работал?

Вы сами тупой, просили пример указателя не как указателя, а теперь оскорбляете.

>>невозможности передавать массив по значению

это очень неэффективно и понравится быдлокодерам. не нужно

лол... в С++ и так пользуются в основном векторами...

>А если мы не можем передавать указатель на объект в хэш-таблице, т.к. он может поменяться (а вот хэш не поменяется)?

Booster предлагал по указателю хешировать, на что я и возразил. Т.е. речь не о указателях на содержимое хеш-контейнера.

я бы предложил вместо «молнии» иметь фичу «запретить любые reinterpret_cast в моем проекте»

Во-первых, указатели, емнип, и статик кастом к инту приводятся. Во вторых найти все /\w+_cast/ легко можно грепом. В третьих, те, кто думает, что в указателе 4 байта обычно пользуются си-стайл кастом. На него есть -Wold-style-cast. В четвёртых, основной гимор ламера создают когда пишут либы, тулзы и унаследованные части проекта. Из своего проекта говно сравнительно легко вычищается означенными способами.

21. Интуитивно приемлемого варианта решения вопроса с классами Elipse & Circle.

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

>Например у майкросфт LPARAM это uint, как быть?

Поразить их молнией. Самое правильное решение.

>>невозможности передавать массив по значению

это очень неэффективно и понравится быдлокодерам. не нужно

Быдлокодеры как передавали vector<list<string>> по значению, так и будут.

>Вы сами тупой, просили пример указателя не как указателя, а теперь оскорбляете.

Ну дурацкий же пример. Никому не нужен хеш-контейнер, где ключ - указатель. А там, где ключ - не указатель - никому не нужен указатель.

>Ну дурацкий же пример. Никому не нужен хеш-контейнер, где ключ - указатель. А там, где ключ - не указатель - никому не нужен указатель.
Почему? Таблица функций-же, где ключ хеш указателя.

Нет, у тебя просили не просто пример указателя не как указателя, потому что указатель как ключ в хеш-таблице это всё равно указатель. У тебя просили пример, когда нужно кастовать указатель к int и обратно. Этого ты не осилил.

Повторю, в хеш таблице.

Когда нужно кастовать я уже писал, колбеки, фух.

>потому что указатель как ключ в хеш-таблице это всё равно указатель
Нифига и не указатель, а ключ.

> Как раз наоборот. Опыт имеется ;)

Твой опыт не интересен. Интересен был бы опыт программиста, который поддерживал бы твой код после того, как ты ушел.

DSL по оперделению читается лучше.

Да да да. После того, как прочитается вся документация по этому DSL (если разработчику хватило ума и таланта её хорошо написать). И после того, как на каждом из мелких DSLей в проекте ты понапишешь достаточно кода для приобретения опыта чтения с листа.

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

Сколько ты с ним работал?

Достаточно. И с ним, и с Nemerle, и с mbase, и с другими глупыми цацками, претендующими на «расширяемость». Для попонтоваться перед другими кодерами - годится. Для реальной работы не подходит абсолютно.

Да, что-то ты совсем упоротый какой-то. Если это ключ, то на хера его кастовать?

Дурак, да? Какие на хер колбеки, какой на хер кастовать с потерей значащих бит?

>Да, что-то ты совсем упоротый какой-то. Если это ключ, то на хера его кастовать?
Пускай упоротый, а ты хамло.

Ну уж извини, за базар то отвечать надо. Ты ведешь себя по хамски, не давая развернутых ответов. За это к тебе и отношение соответствующее.

Я не понял при чём здесь лямбды и колбеки. В колбэк передаётся либо указатель, либо не указатель. Если нам нужно иное, то придётся привести. Например у майкросфт LPARAM это uint, как быть?

При том, что если в языке есть нормальные лямбды, то необходимость передавать в коллбек значение типа void* отсутствует.

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

>Да, что-то ты совсем упоротый какой-то. Если это ключ, то на хера его кастовать?

Не переживай =). Booster он и правда упоротый. Он тут куйню в каждой теме несет.

Да уж я совсем по-хамски.

Ну уж извини, за базар то отвечать надо.

По фене не ботаю.

>Не переживай =). Booster он и правда упоротый. Он тут куйню в каждой теме несет.
Ну вот и мой персональный почитатель нарисовался.

Да я заметил, что оно совсем больное. Уж было подумал, не тот ли это шизофреник, который раньше про «булочничество» везде бухтел.

>Почему? Таблица функций-же, где ключ хеш указателя.

Абсурд. Покажи код как ты себе это представляешь.

> Да и вообще мало-ли зачем может понадобится использовать указатель как не указатель, в системном коде думаю запросто.

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

Да блин, какой ещё абсурд. Таблица(массив) функций, в которой для доступа к элементу используется хеш указателя функции(индекс массива).

> Таблица(массив) функций, в которой для доступа к элементу используется хеш указателя функции(индекс массива).

А теперь показывай конкретный код, с объяснением, на хрена кастовать к меньшему целочисленному типу. Противно, когда с таким упоротым видом несут чушь.

>При том, что если в языке есть нормальные лямбды, то необходимость передавать в коллбек значение типа void* отсутствует.

Тут бустер упомянул винапишные колбеки. Сишные насквозь, да ещё к x86 гвоздями прибитые. Я посмотрю как ты в них лямбду запихаешь. Ногами проталкивать придётся.

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

Этот ананимус меня реально задолбал, только и оскорбляет. Да и Waterlaz не лучше, обвиняет во всех тяжких без объяснения причин.

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

Таблица(массив) функций, в которой для доступа к элементу используется хеш указателя функции(индекс массива).

int naturalnye_chisla[10];

...

void vazshnaja_functsia(int x)
{
  drugaja_functsia(naturalnye_chisla[x]);
}

...

void main()
{
  for (int i = 1; i <= 10; i++)
   naturalnye_chisla[i] = i;

 ...
}

Обязан, обязан. Пасть раскрыл, чушь вякнул - изволь за базар отвечать. Или признай, что говоришь полную чухню, и что ты дурак. Других вариантов нет. Раз начал дискуссию, или отстаивай как следует свою точку зрения, или признавай себя идиотом. Таковы правила.

Тут бустер упомянул винапишные колбеки. Сишные насквозь, да ещё к x86 гвоздями прибитые. Я посмотрю как ты в них лямбду запихаешь. Ногами проталкивать придётся.

Ну может и ногами :-) Пример приведи, а то я давно на Win32 API не писал.

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

>Пасть раскрыл, чушь вякнул - изволь за базар отвечать. Или признай, что говоришь полную чухню, и что ты дурак. Других вариантов нет.
С такими хамами, не имею привычки что-либо обсуждать.

>Таблица(массив) функций,

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

Ещё раз: имея указатель приводить его к инту, считать хеш, по хешу как по индексу вытаскивать из массива указатель - абсурд.

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

это как же получается - RTTI совсем убрать?

Массив указателей на функции, где индекс это хеш соответствующего указателя. Так понятнее?

>Не бывает массивов функций

ну массив указателей на функции-то можно создать

ну массив указателей на функции-то можно создать

зачем?

Какое отношение RTTI имеет к кастингу указателей к целочисленным типам и наоборот?

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