Сообщение от smartpointer Выше я ведь привел что-то подобное, без привязки аргументов и типа возврата.

Ты написал совершенно не то, что требовалось

Добавлено через 24 минуты
В общем ожидается возможность написать что-то типа:

typedef GET_RET_TYPE(sin) sinRetType;

В результате чего sinRetType должен быть double т.к. функция sin возвращает double. Естественно макрос должен работать для абсолютно любой функции

0

Сообщение от nullxdth Ну а вообще, мне кажется, что топить за C, как за язык общего назначения в XXI веке - расписаться в собственном бессилие

Никто этого и не гонит. На чём лучше писать драйвера, например? На Си и асм.

Сообщение от Инженер_3 Я сторонник такого порядка: английский, C, C++. Без английского трудно, что и сейчас испытываю.

С++ не обязательно. Этот язык появился в результате генетического скрещивания языка Си и ООП механизмов, что совершенно несовместимо в принципе, поэтому получился генетический уродец. Изучать его ради ООП? Есть много других языков, более чистых с генетической точки зрения. Язык должен быть настолько простым, чтобы можно было держать в голове все его особенности в обозримой перспективе. Чем более монструознее язык, тем менее можно с ним совладать пытаясь применить наиболее необходимые подходы к решению проблем.
Си низкоуровневый язык, поэтому позволяет на своей основе создавать парадигмы, на что не способны другие языки. Совершенно необязательно писать в чисто процедурном стиле, да ещё применяя структурный подход, на таком императивном языке как Си. Существует совершенный конкурент ООП стилю: это автоматное программирование, которое берёт за основу не обьекты сами по себе и классы управления ими как самостоятельные величины, а такое понятие обьекта, как - "состояние", в котором обьект пребывает в единичные моменты времени. Это намного круче ООП с точки зрения управляемости, обозримости, верификации т.д. Данный стиль прошёл проверку временем, давно развивается в России ещё с советских времён и является чисто нашей разработкой, несмотря на то, что отдельные составляющие этого подхода были давно известны.

0

Сообщение от smartpointer А значит о результате времени компиляции не может идти и речи

о каком результате времени компиляции вы пишите?

вы вообще сами понимаете, чего хотите?

Сообщение от smartpointer Вызов MACRO компилятор автоматически пропишет в (поскольку были переданы две литеральные константы)

и при чем здесь время компиляции?

Сообщение от smartpointer Опять же говорю аккурaтно, потому как возможно в release компилятор преобразует эту лямбду также как и макрос.

вы похоже вообще не понимаете как работает с/с++ компиляторы.

компилятор оптимизирует асд,
а не исходный код.

Сообщение от smartpointer Вы различаете ?

да, различаю.

Сообщение от smartpointer Всегда думал, что код генерирует непосредственно ассемблер.

ассмо-выхлоп - это конечная остановка комплиятора.
с поправкой на линкер.

Добавлено через 2 минуты

Сообщение от CoderHuligan На чём лучше писать драйвера, например?

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

для винды/бубнты/etc - на с++ получится быстрее, надежнее, проще.

для микроволноффки часто просто не выбора,
потому что под них нет компиляторов с++.

используют си/ассм

Добавлено через 51 секунду

Сообщение от CoderHuligan Си низкоуровневый язык, поэтому позволяет на своей основе создавать парадигмы, на что не способны другие языки.

с++ снисходительно улыбается на вашу наивность.

Добавлено через 54 секунды

Сообщение от CoderHuligan Данный стиль прошёл проверку временем

бла бла бла.


название языка будет?

Добавлено через 2 минуты

Сообщение от smartpointer а значит по сути шаблоны ведут себя точно также как и макросы

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

0

Сообщение от CoderHuligan Язык должен быть настолько простым, чтобы можно было держать в голове все его особенности в обозримой перспективе

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

0

Сообщение от hoggy название языка будет?

Это не язык, а концепция, при помощи которой можно писать на любом языке включая ++ проекты любого уровня сложности. Но есть и наработки:http://unimod.sourceforge.net
Материалы по АП: http://is.ifmo.ru

Добавлено через 6 минут

Сообщение от Voivoid А как быть в случае, когда один человек вполне себе держит в голове особенности языков, а вот другому человеку ничего в его бедную головешку посложнее C не лезет. Это проблема языков или головешки?

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

0

Сообщение от CoderHuligan Это не язык, а концепция, при помощи которой можно писать на любом языке включая ++ проекты любого уровня сложности.

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

где концепция проходила проверку времени?
есть что-то более существенное,
чем один линк-описание?

Сообщение от CoderHuligan Если этому человеку приходится "держать" что-то в своей башке, то на "удержания" этого чего-то, тратится львинная доля энергии мозга.

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

0

Сообщение от hoggy где концепция проходила проверку времени?

См. линк.

Сообщение от hoggy есть что-то более существенное, чем один линк-описание?

На основе концепции создана облачная ОС Corezoid:http://www.business.ua/it/Obzo... da-234542/

Сообщение от hoggy зачем? в смысле, зачем удерживать в голове кучу всего?

Так вот и я говорю: ЗАЧЕМ???

0

Сообщение от CoderHuligan Так вот и я говорю: н-а-х-р-е-н-а???

Типа, нахрена держать в голове таблицу умножения, можно ж и на пальцах посчитать, так что-ли?

0

Сообщение от Voivoid Типа, нахрена держать в голове таблицу умножения, можно ж и на пальцах посчитать, так что-ли?

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

0

Сообщение от CoderHuligan Чем сложнее язык, тем больше шансов получить ошибку в проекте выбрав не тот инструмент.

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

0

Сообщение от CoderHuligan См. линк.

там какой то один проект.

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

0

Каждый ест свою кашу... Пошёл варить...

0

Сообщение от Voivoid В результате чего sinRetType должен быть double т.к. функция sin возвращает double. Естественно макрос должен работать для абсолютно любой функции

Не знаю, typeid в С нету. Другое дело как это поможет, ну выдал вам строку возвращаемого аргумента дальше что ?

Сообщение от hoggy и при чем здесь время компиляции?

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

Сообщение от hoggy компилятор оптимизирует асд, а не исходный код.

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

Добавлено через 45 минут

Сообщение от Voivoid А как быть в случае, когда один человек вполне себе держит в голове особенности языков, а вот другому человеку ничего в его бедную головешку посложнее C не лезет. Это проблема языков или головешки?

Посложнее для нас есть асм. А про С++ я бы сказал так - это не сложный язык, а усложненный. Усложняйте ваш код с каждым выходом нового стандарта С++, скоро их клепать ежегодично будут, лол

0

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

это называется inline-подстановка.

Сообщение от smartpointer Нуу... я тебе про это и говорю, уберет ли компилятор в результате оптимизации явный вызов call - и подстроит простейший код в тело вызова, как это делается в случае макроса или нет.

надо смотреть ассмо-выхлоп конкретного компилятора, и его настройки.

если "анализ выигрыша" покажет,
что inline-подстановка даст профит к эффективности - сделает inline

0

С Хабра, перевод: Ваш язык программирования — отстой

0

Сообщение от sharpey перевод

Эту статью надо было изначально назвать
"Список того, что я не осилил".

0

Сообщение от Croessmah Эту статью надо было изначально назвать "Список того, что я не осилил".

Звучит как "не осилил съесть мешок навоза". Там большая часть претензий вполне по делу, особенно позабавила Java, т.к. на работе на ней пишу.

Перевод только кривоват.

0

Сообщение от korvin_ Звучит как "не осилил съесть мешок навоза"

Это о другом совершенно. Я не вижу в конце слов "я разработал самый лучший и прекрасный язык в мире.".
Где оно? Не разработал? Тогда не надо орать что другие плохие.
Сделай свой прекрасный язык, а мы расскажем тебе, какое оно убогое.

0

Сообщение от Croessmah Я не вижу в конце слов "я разработал самый лучший и прекрасный язык в мире.".

Почему они должны быть? Как будто кто-то из знаменитых литературных критиков 19-го века написал «самое лучшее произведение в мире». Умение находить недостатки в существующих вещах и умение создавать новые вещи ортогональны. Тестеров не заставляют править баги и рефакторить код/архитектуру приложения. Они могут отлично знать как «не надо делать», но мало что знать о том как «надо делать». То же самое работает и наоборот. Конечно, это крайности и в реальность есть только разные сочетания градаций этих крайностей.

Сообщение от Croessmah Где оно? Не разработал? Тогда не надо орать что другие плохие.

Ага-понятно.

0

Сообщение от korvin_ Ага-понятно.

Нет, не понятно.
Там под спойлером было много чего из разряда
"автор не дочитал книжку по C++",
убрал, ибо начнется сами знаете что.
Аргументы в статье какие-то не очень,
есть и хорошие аргументы, с этим тоже не спорю,
но это не значит абсолютно ничего,
потому что идеальных языков нет.
Может если язык не подходит для решения
определенной задачи, то стоит взять другой,
и обойтись меньшей болью?
Плюс ко всему на всех не угодишь,
сколько бы язык не лизали, он всё равно
кому-то не будет нравится.
Так что это мнение исключительно автора статьи,
и со многими его аргументами я не согласен,
однако, если он при этом называет языки отстойными,
то тогда и все несогласные с его аргументами
могут называть автора аналогично, не так ли?

Сообщение от korvin_ Умение находить недостатки в существующих вещах и умение создавать новые вещи ортогональны.

Умение находить и создавать - да.
Но если не устраивает то приходится либо клепать своё,
либо использовать то что есть, а не кричать по всем углам.
Так что в любом случае "не осилил".
Либо "создание своего прекрасного",
либо "накладывание швов на раны".

Сообщение от korvin_ Они могут отлично знать как «не надо делать», но мало что знать о том как «надо делать».

Если они не знают "как надо", даже приблизительно,
значит они не могут знать как "не надо",
иначе "не надо" - это всё то, что не устраивает лично автора.

Добавлено через 7 минут
korvin_, наверное, мне стоило высказаться слегка по-другому.
Автор собрал множество недостатков, но,
во-первых, не все из них являются недостатками,
во-вторых, некоторые аргументы уже давно устарели,
в-третьих, некоторые аргументы не относятся к языкам,
в-четвертых, не все будут согласны,
в-пятых, автор может просто не знать всех этих языков в совершенстве и,
соответственно, каких-то правил, концепций и решений,
поэтому у него возникают подобные сложности и
он, ошибочно, заносит их в раздел недостатков.

0