Неплохо так. Примерно так и делаю, кстати. Хотя Haskell не знаю=)

Мы тут о поздних связываниях и ad-hoc полиморфизмах, если что.

Ага. Но все началось с вот этого вброса. Мне кажется что свою точку зрения я отстоял.

Не хотите ООП, давайте возьмем что-то вроде тайпклассов Haskell.

Извини, анон, но с Haskell-ем я тоже не знаком, а про тайпклассы слышу и вовсе впервые.

И еще предпочитаю не дискутировать на темы в которых я совсем некомпетентен.

Весь тред не читал, а go тут не вспоминали?

Икота замучала?

Мне кажется что свою точку зрения я отстоял.

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

И еще предпочитаю не дискутировать на темы в которых я совсем некомпетентен.

Но уже начал. Там вроде простой сишных код. Структурка с указателями на функции выделяется в отдельный тип. А дальше мы можем заполнять такую структурку(или даже несколько) для своего типа.

что ты, действительно, мало знаешь.

Да, мало. Чем дольше живу, тем больше это понимаю.

Но уже начал. Там вроде простой сишных код.

Скажу тебе честно, анон, я просто «съезжаю». Мне же нужно и в RL кодить. Отвлекает все это.

Нет, а что?

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

Все это пустая болтовня. Нету у вас никаких аргументов, особенно по поводу медленно. Медленно относительно чего? Давайте цифры. Пункт 5 вообще лол. Про юникод непонятный знак вопроса. И вообще все это смахивает на «С++ херня потому что в нем нету того, что есть в джаве».

Нифига себе затравка для троллинга - эта статья. Аж 11 страниц срача.

А по сути - поменяйте пару пунктов и замените С++ на любой другой язык - будет такая же статья.

Срача будет меньше, потому что другие языки никому нахрен не сдались :)

И вообще все это смахивает на «С++ херня потому что в нем нету того, что есть в джаве».

Язык, в котором нету ДАЖЕ ТОГО, что есть в какой-то убогой джаве - действительно херня.

Откровенное враньё.

боюсь, остальные пункты в твоем «опровержении» — такая же ложь

может ты-бы постеснялся откровенный быдлокод постить? Ну не знаешь ЯП — не пиши на нём. Зачем позориться? Я же не кидаю сюда например свой говнокод на C#, который тоже «не работает»? Ну не знаю я C# (и знать не желаю), это же не доказывает, что C# говно?

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

потому-что const это ПРИКАЗ. Он НЕ ОБСУЖДАЕТСЯ. Если написано const, компилятор строит свой код так, как если-бы эта переменная НИКОГДА НЕ ИЗМЕНИЛАСЬ.

Ну а если таки изменилась — ССЗБ. Это _твои_ проблемы, дорогой говнокодер.

И да, в сишечке никаких «сторожей» нет, и не было никогда. Учи BASIC или там питон.

Приведи, пожалуйста. пример, чтобы const после O3 что-то изменило по перфомансу

ты сам привёл такой пример: у тебя three КОНСТАНТНО РАВНО трём. Вот компилятор и НЕ изменяет. Согласись — не считать быстрее, чем считать.

В СА говорят: не нужно выполнять тупой приказ, нужно подождать, пока его отменят.

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

можно. В быдлокоде можно ВСЁ.

Наш стивчик отдал приказ «стой там, иди сюда». На его приказ положили болт. А он почему-то обиделся...

потому-что const это ПРИКАЗ. Он НЕ ОБСУЖДАЕТСЯ. Если написано const, компилятор строит свой код так, как если-бы эта переменная НИКОГДА НЕ ИЗМЕНИЛАСЬ.

А чего же он ее меняет тогда?

потому-что const это ПРИКАЗ. Он НЕ ОБСУЖДАЕТСЯ. Если написано const, компилятор строит свой код так, как если-бы эта переменная НИКОГДА НЕ ИЗМЕНИЛАСЬ.

А чего же он ее меняет тогда

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

А компилятор просто делает то, что ему сказано. Да, приказ тупой, и результат тупой. Он(результат) ещё и непредсказуемый...

http://dlang.ru/forum/10-prichin-pochemu-u-spp-net-budushhego

какие оценки у тебя были по математической логике, математической/компьютерной лингвистике, построению компиляторов? «неуды»?

какие оценки у тебя были по математической логике, математической/компьютерной лингвистике, построению компиляторов? «неуды»?

деточка, хочешь похвастаться? Ну давай...

Кстати, какое это отношение к теме имеет, расскажешь? И вообще, чем ты на занятиях занимался?

Потому что процессор меняет. Обжабаные что, реально настолько тупые?

Прочитал пару пунктов - дальше не стал, трололо почти на каждом пункте. Хехе

Воу, воу полегче

gcc выдаст ошибку т.к. нельзя ссылаться на константу обычным указателем (как минимум если бы вы немного разбирались в компиляторе, то он при компиляции создает таблицу констант, для более быстрого обращения к ним). Ты можешь осилить с++ (даже новый стандарт), если прочитаешь хотя бы Прата С. Язык программирования С++ Лекции и упражнения 2011 и Параллельное программирование на С++ в действии. Практика разработки многопоточных программ. И тогда у тебя в голове немного по яснеет.

Зачем подобные «заметки» и пустопорожние выяснения? Кому какое дело, на каком языке ведется разработка того или иного проекта? Главное ЧТО именно является результатом, насколько широко используется и делает мир лучше. Пусть язык будет какой угодно и как угодно пусть называется.

вспомним легендарный тред:

http://www.sql.ru/forum/466654/

стивчек?

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

А компилятор просто делает то, что ему сказано.

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

Ну так почему он меняет, если четко и однозначно сказали - «не менять»? Чего он приказы-то не выполняет?

А он генерирует

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

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

переменная != область памяти, компилятор не обязан генерировать код, который при каждой записи будет проверять - разрешено ли туда писать

переменная != область памяти, компилятор не обязан генерировать код, который при каждой записи будет проверять - разрешено ли туда писать

Конечно. Он это проверять должен при компиляции, а не в рантайме.

Он это проверять должен при компиляции

не всегда это тривиально или возможно:

struct S
{
    int a;
    const int b;
};

...

S s;
const int k;

*(&s.a + sizeof(int) * n) = 1;

тут может перезаписаться и s.b и k

не всегда это тривиально или возможно:

Всегда.

тут может перезаписаться и s.b и k

Очевидно, что если в структуре есть const поле то запись в нее по указателю запрещена. Ну, должна быть запрещена.

Всегда.
Очевидно, что если в структуре есть const поле то запись в нее по указателю запрещена.

struct S
{
    int a[1];
    const int b;
};

и?

s.a[n] может переписать s.b, если n==1

а не переписать может?

эта та же самая адресная арифметика, которую ты хотел запретить

если в таблицах MMU записано что нельзя писать - будет исключение. #PF например на x86. а если не написано, то кто ж виноват альтернативно одарённым обжабаным, что они ни ухом ни рылом про то, как работает процессор.

пишете говнокод а виноват с++. и кстати это все ++хейтеры изображают - везде говнокод в качестве примеров.

а причина одна - вы дебилы.

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

Ну не переписать может? Ты уверен, что там действительно будет оно, учитывая выравнивание?

Ты уверен, что там действительно будет оно, учитывая выравнивание?

выравнивание можно явно задать

То есть не гарантируется, что переменная __действительно_ будет переписана, и, т.о., программист ссылается на неспецифицированное поведение. Здесь все в порядке. не надо ничего запрещать. В случае если поведение неспецифицировано - ты сам себе злой буратино. А вот когда оно специфицировано и меняет константное значение - это фейл.

Жопа ты с ручками, пиши и дальше говнокод и заказчику говори что во всем виноват с++

А эти прагмы, которыми ты выравнивание будешь задавать, в стандарте присутствуют?

Дело не в говнокоде, а в том, что компилтяор языка не выполняет отданные ему команды. Сказали константа - значит константа. Или тогда убирайте этот модификатор, раз компилятору на него похуй.

А эти прагмы, которыми ты выравнивание будешь задавать, в стандарте присутствуют?

на голом стандарте далеко не уедешь, ну и без этих прагм можно узнать точное смещение с помощью offsetof

Что значит не выполняет? У меня в const-память ничего не пишется.