Comments 58
Всё что угодно кроме «Определенно, да» :)))
Не буду из-за одного только var.
Хотя в целом плюшки приятные.
Не хокку.
Хотя в целом плюшки приятные.
Не хокку.
typedef void* var;
Это ещё не самое ужасное. Вот, смотрите:
#define is ==
#define isnt !=
#define not !
#define and &&
#define or ||
#define in ,
Зачем?
#define in,
о_0
Тяжёлая наркомания. Либо это не перечисление, а что-то другое, но тогда наркомания тяжелее тяжёлой.
о_0
Тяжёлая наркомания. Либо это не перечисление, а что-то другое, но тогда наркомания тяжелее тяжёлой.
Конкретно is, isn't, not, and и or — конечно же, полная ересь. Но in нужен для того, чтобы писать красивые foreach-циклы!
Между прочим,
Alternative spellings для логических операторов есть в стандарте самого С, определены в <iso646.h>
Alternative spellings для логических операторов есть в стандарте самого С, определены в <iso646.h>
Primary Alternative
&& and
&= and_eq
& bitand
| bitor
~ compl
! not
!= not_eq
|| or
|= or_eq
^ xor
^= xor_eq
Тебе никто не запрещает использовать рабоче-крестьянский
void*. Я конечно не ручаюсь в таком случае за твое здоровье, но твое право!Что void*, что var — код не читабелен. Поди угадай, что за тип. Я бы предпочёл настоящую строгую типизацию, чем вообще её отсутствие.
UFO just landed and posted this here
Такое, что ни в С, ни в С++ нет строгой типизации. Я бы предпочёл «дополнение» со строгой типизацией, чем всякую прочую ненужную фигню.
Например, какой тип будет при записи: «var a = 1;»? Под это объявление подходит минимум восемь типов int'ов, плюс float и double (но их точно не будет выбрано).
Например, какой тип будет при записи: «var a = 1;»? Под это объявление подходит минимум восемь типов int'ов, плюс float и double (но их точно не будет выбрано).
UFO just landed and posted this here
Я и не спорю, что var (почти) не имеет общего со строгой типизацией. В С++ строгую типизацию добавить элементарно на уровне компилятора. Только потеряется совместимость с имеющимися программами и придётся в большинстве арифметических операций вручную тип задавать… Пожалуй, мне и без строгой типизации неплохо программируется.
ШОК! Зачем же мне теперь все эти ваши Go/D/Nim/<впиши>, если С на стероидах решает все проблемы рода человеческого?!
Cello добавляет поверх С дополнительный слой рантайма.мда… проблема рода человеческого в том, чтобы обеспечить почти всё это без рантайма.
Есть же Rust, который делает всё это и куда больше, только без оверхеда в рантайме. И как, кстати, у Cellо дела со строгой типизацией? Сдается мне, что многие синтаксические фишки не позволяют сохранить информацию о типе без поддержки компилятора, как тот же
var.Тоесть ты сейчас серьезно критикуешь, по-сути, Си, за то, что в нем нету плюшек из Rust? Тут товарищ сделал костыль для сишки и назвал его Cello. Зараза, в каждый тред о C/C++ прибежит фрик, угорающий по Rust и начнет доказывать, что последний обосраться какой крутой.
Все понимают, что в Rust с его девятью типами указателей полная потокобезопасность, контроль лайфтайма и вот это все. Ясно, всем все понятно, спору нет — классный язык. Не нужно об этом постоянно напоминать.
Все понимают, что в Rust с его девятью типами указателей полная потокобезопасность, контроль лайфтайма и вот это все. Ясно, всем все понятно, спору нет — классный язык. Не нужно об этом постоянно напоминать.
Си, в основном, используется там, где нужна прямо таки maxxxимальная производительность — например, во встраиваемых системах.Там он используется скорее потому, что компилятора C++ (и Rust, ага) просто нет, или есть, но «ужас-ужас-ужас».
Получается, нишу C это заполнить не может (рантайм, гц, динамическая типизация). Зачем оно тогда вообще нужно? С такими свойствами полно других языков, только не являющихся набором костылей над С.
Как-то пробовал на нём писать «Песню про пиво», ощущения так себе.
Всегда считал, что вместо траты времени на создание новых языков, лучше написать хорошую библиотеку для того языка, который тебе нравится.
Cello — прикольная штука, думаю это первая ласточка к созданию «упрощенных / безопасных» библиотек / оберток для С и С++.
Там где нужна скорость — пишешь на чистом С / С++;
Там где нужна супер скорость — пишешь asm {… }
Там где скорость не критична, подключаешь Cello.h или еще что-то и быстренько ваяешь что-нибудь в стиле PHP.
И все это в одной программе и на одном компиляторе — вот это было бы супер круто!!!
На С писал программы только по работе для микроконтроллеров (других применений его в 21 веке не знаю), там скорость очень важна, поэтому Cello использовать никто не будет.
А вот на C++ пишется много прикладных задач, в которых критических мест мало, вот там можно было бы добавить хорошую библиотеку типа php.h
PHP чем хорош? Тем что там по любому чиху уже есть готовая стандартная ф-ция, не надо искать библиотеку (выбираешь из стандартных), не надо следить за освобождением памяти, автоматические типы переменных, простой интерфейс для ассоциативных массивов с теми же foreach и т.п…
Когда начинал писать на PHP все время задавался вопросом: Почему такую же библиотеку не сделать для С++? Ведь по сути все стандартные библиотеки PHP написаны на С++, зачем придумывать новый язык если можно сделать удобную обертку, ибо C++ велик и могуч! :)
В новомодном C++14, много фишек типа всяких лямбда и новой интерпретации auto, но имхо, их синтаксис туманит разум выросший на простом и понятном C++98. Вот если бы эти фишки применить для обертки библиотек php и их автоматической конвертации в код C++ по типу Cello… А там уже и не далеко до полного портирования любого php-кода в C++ (если разницу в синтаксисе через обертку минимизировать, то может даже до простого copy/past можно довести).
Ну что, господа, как Вам идея?
А может такая штука уже давно реализована, и я один ни х… не знаю? :)
Cello — прикольная штука, думаю это первая ласточка к созданию «упрощенных / безопасных» библиотек / оберток для С и С++.
Там где нужна скорость — пишешь на чистом С / С++;
Там где нужна супер скорость — пишешь asm {… }
Там где скорость не критична, подключаешь Cello.h или еще что-то и быстренько ваяешь что-нибудь в стиле PHP.
И все это в одной программе и на одном компиляторе — вот это было бы супер круто!!!
На С писал программы только по работе для микроконтроллеров (других применений его в 21 веке не знаю), там скорость очень важна, поэтому Cello использовать никто не будет.
А вот на C++ пишется много прикладных задач, в которых критических мест мало, вот там можно было бы добавить хорошую библиотеку типа php.h
PHP чем хорош? Тем что там по любому чиху уже есть готовая стандартная ф-ция, не надо искать библиотеку (выбираешь из стандартных), не надо следить за освобождением памяти, автоматические типы переменных, простой интерфейс для ассоциативных массивов с теми же foreach и т.п…
Когда начинал писать на PHP все время задавался вопросом: Почему такую же библиотеку не сделать для С++? Ведь по сути все стандартные библиотеки PHP написаны на С++, зачем придумывать новый язык если можно сделать удобную обертку, ибо C++ велик и могуч! :)
В новомодном C++14, много фишек типа всяких лямбда и новой интерпретации auto, но имхо, их синтаксис туманит разум выросший на простом и понятном C++98. Вот если бы эти фишки применить для обертки библиотек php и их автоматической конвертации в код C++ по типу Cello… А там уже и не далеко до полного портирования любого php-кода в C++ (если разницу в синтаксисе через обертку минимизировать, то может даже до простого copy/past можно довести).
Ну что, господа, как Вам идея?
А может такая штука уже давно реализована, и я один ни х… не знаю? :)
Украл мой комментарий :-).
О… пояндексил и нашел phpcpp.h
правда он для создания расширений на cpp для php сервера, и… не так удобен как хотелось (если бы просто повторить/приблизиться к синтаксису php), поэтому обычное использование библиотеки чисто для создания c++ программ не дает особого выигрыша в простоте
правда он для создания расширений на cpp для php сервера, и… не так удобен как хотелось (если бы просто повторить/приблизиться к синтаксису php), поэтому обычное использование библиотеки чисто для создания c++ программ не дает особого выигрыша в простоте
Вы предлагаете решать все задачи с помощью одного известного вам инструмента, потому что он «велик и могуч», но серебряной пули не бывает. Для написания сайта нужен совсем другой фреймворк, нежели для десктопного приложения или мобильной игры, и попытка сделать один универсальный приведет только к тому, что на нем будет одинаково сложно и неудобно писать любые приложения.
Ну… не знаю.
Основной инструмент, который я использую для C++ это С++Builder.
С помощью него сейчас из коробки можно написать и десктопное приложение (Vcl, FireMonkey), сайт (IntraWeb/VclForWeb, Indy) и мобильную игру (компилится в нативный, android, mac) и компоненты для работы с БД (SQLite, MySql, FireBird, MS SQL...)
И все это я реально использую в своих проектах из одной IDE и на одном языке.
PHP — юзаю больше для создания прототипов и доработки open source проектов используемых в нашей организации. Плюсы PHP, которых мне не хватает в C++ я описал выше.
А то что С++ «велик и могуч» — это Вы не сомневайтесь :)
На его базе с помощью оберток можно к синтаксису любого языка приблизиться (так сказать создать язык внутри языка), было бы время да голова на плечах.
Основной инструмент, который я использую для C++ это С++Builder.
С помощью него сейчас из коробки можно написать и десктопное приложение (Vcl, FireMonkey), сайт (IntraWeb/VclForWeb, Indy) и мобильную игру (компилится в нативный, android, mac) и компоненты для работы с БД (SQLite, MySql, FireBird, MS SQL...)
И все это я реально использую в своих проектах из одной IDE и на одном языке.
PHP — юзаю больше для создания прототипов и доработки open source проектов используемых в нашей организации. Плюсы PHP, которых мне не хватает в C++ я описал выше.
А то что С++ «велик и могуч» — это Вы не сомневайтесь :)
На его базе с помощью оберток можно к синтаксису любого языка приблизиться (так сказать создать язык внутри языка), было бы время да голова на плечах.
UFO just landed and posted this here
В данном случае основной недостаток C++ — что он не отсекает возможность писать небезопасный код. На фоне этой небезопасности в плане «диких» указателей и утечек памяти все «улучшения через макросы» выглядят как «ложка мёда к бочке дёгтя» — ни на хлеб положить ни телегу смазать. Как если бы это были макронадстройки над языком ассемблера. И как, в прочем, и аналогичные надстройки на фортом, которые регулярно появляются just for fun.
Не безопасный код — понятие растяжимое, его можно писать на любом языке.
Типа взаимный Lock потоков из-за неверного условия в if Или случайно затерявшаяся строчка посреди программы exec(«format c:») :-)… Все зависит от того, кто этот код пишет.
Дикие указатели с new и забытыми/не продуманными delete — удел школьников и дилетантов.
Профессионалы если такое используют — то делают это обосновано (очень очень нужна скорость) проектируют и тестируют архитектуру для всех возможных вариантов событий на 100 ходов веред.
Там где скорость не критична и более важно удобство — ВСЕГДА нормальными программистами используются смарт-поинтеры (причем при правильной архитектуре достаточно лишь auto_ptr) и контейнеры с автоочисткой.
Надстройка (доп. библиотека) нужна лишь только для того, чтобы упростить синтаксис работы с этими указателями и контейнерами (в стандартном варианте он получается длинноват)
Мне приходилось писать на разных ЯП от asm, бэйсика, паскаля, js, vb, c#, php, до языков функциональных блоковых диаграм и LAD. Но оптимальным для себя выбрал именно c++ в совокупности с IDE С++Builder которая всегда в авангарде технологий и имеющая кучу готовых компонентов, которые на данный момент позволяют решать абсолютно любые современные задачи за вполне разумное время (от построения дестопного GUI или web-сервисов до программирования МК или мобильных устройств).
Для счастья всего лишь не хватает библиотеки, которая упростила бы (сократила код) для работы в критически не важных по скорости местах программы по типу php и его стандартных библиотек.
Vala — это не совсем то. Основная ее идея — полное создание приложения на Vala (с возможностью вызова C ф-ций) и последующей компиляции в продакшен на C. Я же говорю об основном коде на C++ и подключением к этому коду библиотеки обеспечивающей упрощение синтаксиса и автоматическую безопасность. Что упростит и разработку и отладку.
Типа взаимный Lock потоков из-за неверного условия в if Или случайно затерявшаяся строчка посреди программы exec(«format c:») :-)… Все зависит от того, кто этот код пишет.
Дикие указатели с new и забытыми/не продуманными delete — удел школьников и дилетантов.
Профессионалы если такое используют — то делают это обосновано (очень очень нужна скорость) проектируют и тестируют архитектуру для всех возможных вариантов событий на 100 ходов веред.
Там где скорость не критична и более важно удобство — ВСЕГДА нормальными программистами используются смарт-поинтеры (причем при правильной архитектуре достаточно лишь auto_ptr) и контейнеры с автоочисткой.
Надстройка (доп. библиотека) нужна лишь только для того, чтобы упростить синтаксис работы с этими указателями и контейнерами (в стандартном варианте он получается длинноват)
Мне приходилось писать на разных ЯП от asm, бэйсика, паскаля, js, vb, c#, php, до языков функциональных блоковых диаграм и LAD. Но оптимальным для себя выбрал именно c++ в совокупности с IDE С++Builder которая всегда в авангарде технологий и имеющая кучу готовых компонентов, которые на данный момент позволяют решать абсолютно любые современные задачи за вполне разумное время (от построения дестопного GUI или web-сервисов до программирования МК или мобильных устройств).
Для счастья всего лишь не хватает библиотеки, которая упростила бы (сократила код) для работы в критически не важных по скорости местах программы по типу php и его стандартных библиотек.
Vala — это не совсем то. Основная ее идея — полное создание приложения на Vala (с возможностью вызова C ф-ций) и последующей компиляции в продакшен на C. Я же говорю об основном коде на C++ и подключением к этому коду библиотеки обеспечивающей упрощение синтаксиса и автоматическую безопасность. Что упростит и разработку и отладку.
Подобные бубнотанцы с макросами могут быть нужны, если вдруг необходима компиляция кода, написанного на более безопасном языке типа Java или C#, компилятором С или С++. Типа трансляции в Javascript в GWT. Тут гарантией безопасности является компилятор исходного языка, а «вылизать» транслятор и макробиблиотеку теоретически нужно только один раз.
Для продакшена есть С++ (даже без D, Go, Rust и Nim). Еще есть C++/Boost, в котором тоже немало накручено… но он как-то используется более широко, поэтому доверия больше.
А это — любопытно, не более того. Любопытный пример того, что должно быть в языках программирования, но нет, отличный довод в пользу того, что в языках должно быть много фич (аналогично Бусту для С++).
А это — любопытно, не более того. Любопытный пример того, что должно быть в языках программирования, но нет, отличный довод в пользу того, что в языках должно быть много фич (аналогично Бусту для С++).
Человек сделал vala, причем сделал намного хуже оригинала. Не нужно
UFO just landed and posted this here
Согласно Десятому правилу Гринспана, лучшей и наиболее естественной надстройкой над фортраном или С является Common Lisp ;-). Ну или в крайнем случае другой функциональный язык ;)
А всё почему? А потому, что незаметно, чтоб авторы языка С удосужились сделать нормальную поддержку использования блоков кода в качестве аргументов макроса.
А всё почему? А потому, что незаметно, чтоб авторы языка С удосужились сделать нормальную поддержку использования блоков кода в качестве аргументов макроса.
А как со скоростью такой надстройки? Вы точно уверены что речь о надстройке над C, а не над Forth? Поскольку функциональный код можно очень легко транслировать в быстрый Forth-код, просто превратив выражения вроде +(a,b) в код вида a b +
Но вот способа превратить функциональный код в быстрый C-код я не вижу.
Но вот способа превратить функциональный код в быстрый C-код я не вижу.
Хочу! (^_^)
А с OpenGL эта библиотека насколько хорошо совместима? (кто-нибудь проверял?)
А с OpenGL эта библиотека насколько хорошо совместима? (кто-нибудь проверял?)
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Высокоуровневый С или пару слов о Cello