LINUX.ORG.RU

KDevelop 4.3

 , , , , , ,


0

2

Cостоялся выход версии 4.3 интегрированной среды разработки KDevelop. Как обычно, в релиз вошел ряд новых возможностей, а также исправления ошибок и улучшения производительности.

Неполный список изменений:

  • Поддержка С++11.
    Новая версия стандарта теперь частично поддерживается в KDevelop. Парсер теперь поддерживает такие новые возможности языка, как списки инициализации, лямбды, for-циклы по коллекции и шаблоны с переменным числом аргументов. Также поддерживаются =default и =delete методы, auto, ссылки на временные объекты (rvalue-references) и много другого. Тем не менее, С++11 включает много изменений и некоторые из них еще не поддерживаются. Разработчики ставят за цель улучшить поддержку в последующих релизах, чтобы сделать KDevelop отличной средой для разработки с использованием C++11.
  • Восстановление состояния редактора.
    С выходом версии 4.3 разработчики синхронизировались с Kate по функционалу работы с файлами: свернутые блоки кода, закладки и прочее теперь корректно восстанавливаются для последних 20 открытых файлов.
  • Улучшенная интеграция с системами контроля версий.
    Была добавлена область просмотра изменений в проекте, которая показывает файлы в проекте, измененные с момента последнего коммита. Также улучшен режим Review, который теперь автоматически обновляется по мере внесения изменений в код проекта.
  • Интеграция с проектами KDE
    Инфраструктура проектов KDE была адаптирована для поддержки projects.kde.org. Это позволило иметь полный список всех проектов KDE с возможностью их загрузки для быстрого начала старта работы над ними.
  • Улучшения интеграция konsole
    Встроенный konsole в KDevelop получил ряд улучшений — теперь при использовании bash стало возможно управлять сессией KDevelop, т.е. открывать и создавать файлы, выполнять поиск по файлам и пр. Просто введите help!, чтобы узнать, что теперь можно делать.
  • Форматирование кода
    Встроенное форматирование также было улучшено — теперь оно может переопределять настройки выравнивания редактора. Более того, «Custom Script Formatter», ранее поддерживавший Gnu Indent, был расширен с упрощением добавления собственных скриптов форматирования. Одним из примеров является kdev_format_source.sh, поставляемый с KDevelop, позволяющий задавать правила форматирования путем размещения файлов format_sources в дереве проекта. В связке с мощным форматировщиком uncrustify, скрипт позволяет легко работать в больших гетерогенных проектах.
  • Исправления ошибок
    Было исправлено более 170 ошибок по сравнению с KDevelop 4.2.3. Среди прочих, теперь нормально поддерживается SVN 1.7, улучшен разбор C++, улучшено взаимодействие с GDB. Также исправлено много падений и прочих проблем.
  • Оптимизации
    Кроме добавления новых возможностей и улучшения стабильности, этот релиз иммет ряд заслуживающих внимания оптимизаций — открытие больших проектов теперь должно происходить значительно быстрее. Также быстрее стал инструмент Quickopen, что делает более комфортной работу в больших проектах.

У проекта появился форум, на котором можно получить поддержку и ответы на вопросы. Также доступны список рассылки, а также канал IRC #kdevelop на freenode.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

Ответ на: комментарий от Dead

Настройки kate перекрываются настройками kdevelop и это нормально. Код подсветки конечно же не относится ни к kate ни к парсеру. Какие еще отмазки будут?

Я просто оставлю это здесь:

language/highlighting/configurablecolors.h
language/highlighting/configurablecolors.cpp
language/highlighting/codehighlighting.h
language/highlighting/codehighlighting.cpp

Pavval ★★★★★
() автор топика
Ответ на: комментарий от Pavval

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

Кстати, kdevelop вроде cmake поддерживает, может, поможет на него перелезть.

BattleCoder ★★★★★
()
Ответ на: комментарий от Pavval

Ok, спасибо за наводку.

Пока только нашел где это захардкожено, но правильный дизайн пока еще в голове не сформировался. Буду капать дальше.

Если можете, подскажите правильный дизайн по добавлению этих цветов в стандартный диалог настройки подсветки.

Dead ★★★★
()
Ответ на: комментарий от NegatiV

С и С++ настолько близки, что почти один язык. С++ похож на «улучшенный» С :)

Сразу видно что С++ вы совсем не знаете =) Хотя да, синтаксически эти два языка немного похожи, но это в общем то и все.

Хмм, а что есть такого в С++, что не является «мелким» улучшением С? Классы+методы+наследование — слегка улучшенные структуры+функции для их обработки, операторы — чуть более удобные функции, ссылки — чуть более безопасные (и менее удобные) указатели, шаблоны — просто экономия кода на написание однотипных функций (притом еще иногда и криво поддерживаемых), и т.д.

abalakin ★★
()
Ответ на: комментарий от mv

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

Почитай чейнджлоги gcc и подумай над тем, какие изменения могут сломать компиляцию.

P.S.: И вообще, куда ЛОР катится? Какая серая неведомая фигня не только два раза «ку» перед пятизвёздочным лиспером в теме про кресты не делает, но ещё и осмеливается дерзить не по канонам сайта!

Собственно, вот и доказательство преимуществ С/С++. На лиспе видимо приходится проект переписывать после каждого релиза средств разработки ... трудоголики, «пятизвёздочные» ...

А я вот ленивый, «серый и неведомый», как написал лет 10-15 назад программки так они и работают ... не смотря на версию компилятора(-ов), на название компилятора(-ов), на ОС где они работают ... Стандарты это вещь!

abalakin ★★
()
Ответ на: комментарий от abalakin

Собственно, вот и доказательство преимуществ С/С++. На лиспе видимо приходится проект переписывать после каждого релиза средств разработки ... трудоголики, «пятизвёздочные» ...

Лисперы не работают, ты разве не знал? Они все пишут себе макрос на два экрана, который работает за них, и на работу только ходят за зряплатой, да в курилке с народом потолкаться.

mv ★★★★★
()
Ответ на: комментарий от abalakin

забей, у лисперов комплексы - они сначала всем рассказывают, что лисп рулит, DSL во все поля, С++ отстой, а доходит до мелких практических задач - выдают нечитабельный код на пол-экрана, который работает медленней чем код на С++, при том еще не работает на всех реализациях их CL, вот ставь любимый LW автора - тогда и заработает

vaino
()
Ответ на: комментарий от vaino

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

[алгоритмы] подсчет частот вхождения чисел в массив (комментарий)

(defmacro опрфун (&body body)
  `(defun ,@body))

(defmacro пуст (body)
  `(null ,body))

(defmacro совпадает (&body body)
  `(eq ,@body))

(defmacro если (condition &body body)
  `(if ,condition ,@body))

(defmacro первый-элемент (&body body)
  `(car ,@body))

(defmacro остаток (&body body)
  `(cdr ,@body))

(defmacro элемент (&body body)
  `(caar ,@body))

(defmacro элемента-в (&body body)
  `(cdar  ,@body))

(defmacro отныне (&body body)
  `(let ,@body))

(defmacro составить (&body body)
  `(cons ,@body))

(defmacro перевернуть (&body body)
  `(nreverse ,@body))

(опрфун список-в-гистограмму* (список гистограмма)
        (если (пуст список) гистограмма
              (отныне ((голова-списка (первый-элемент список))
                       (хвост-списка (остаток список))
                       (элемент-гистограммы (элемент гистограмма))
                       (число-вхождений (элемента-в гистограмма)))
                      (если (совпадает голова-списка элемент-гистограммы)
                            (список-в-гистограмму* хвост-списка (составить (составить элемент-гистограммы (+ 1 число-вхождений)) (остаток гистограмма))) 
                            (список-в-гистограмму* хвост-списка (составить (составить голова-списка 1) гистограмма))))))


(опрфун список-в-гистограмму (список)
        (перевернуть (список-в-гистограмму* список NIL)))

* (список-в-гистограмму '())

против кода на С++

for( size_t i = 0 ; i < count ; ++i )
{
    if( !i || data[ i ] != data[ i - 1 ] )
        res.push_back( data[ i ] );
    else
        res.back().count++;
}

про производительность автор кода на лиспе умолчал ^_^

vaino
()
Ответ на: комментарий от mv

овладел техникой скоростной езды на велосипеде с квадратными колёсам
проще найти работу на йаве или сишарпе

программисту знакомому с С# этот топик с лиспопроблемами сделает смешно:

[cl][нубский вопрос] case и строки

вы все еще пользуетесь треугольными колесами?

vaino
()
Ответ на: комментарий от vaino

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

vaino
()
Ответ на: комментарий от gensym

Где ты там костыли узрел ;) это lispy-way

Если в сисярпе 4.0 нету свитча по строкам, горемыки год по форумам стенают, пока тёмный повелитель не сжалится, и не выпустит сисярп 5.0 с этой фичой и новую визуалстудию с подсветкой и семантическим дополнение фичи, организовав к релизу банкет с шампанским, икрой и хоть и полуголыми, но, в целом, некрасивыми женщинами. Через две недели сисярподжедаи, освоив новую ошеломительную фичу, пишут тонны статей на хабре. В комментам им консевартивно настроенные сисярподжедаи срут тонны говна, что эта фича нафиг не нужна, только захламляет язык, и без неё было хорошо.

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

mv ★★★★★
()
Ответ на: комментарий от vaino

вы все еще пользуетесь треугольными колесами?

А ещё у нас вместо одного == есть eq, eql, equal и equalp!

mv ★★★★★
()
Ответ на: комментарий от mv

А ещё у нас вместо одного == есть eq, eql, equal и equalp!

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

vaino
()
Ответ на: комментарий от mv

сколько воды, чтоб отвести внимание от факта, что C# лучше CL

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

в C# и даже С можно компилировать генерированный код на лету, этому можно найти применение, а часто тебе приходилось «перепиливать встроенный компилятор»?

vaino
()
Ответ на: комментарий от vaino

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

4 функции сравнения имеют под собой крепкий теоретический фундамент. Сказать, что они нафиг не нужны, это то же самое, что сказать хаскеллисту про ненужность всех ихних морфизмов.

mv ★★★★★
()
Ответ на: комментарий от vaino

сколько воды, чтоб отвести внимание от факта, что C# лучше CL

Лучше CL быть можно, но сложно. И сисярп не лучше.

в C# и даже С можно компилировать генерированный код на лету, этому можно найти применение

В языке Си генерировать и компилировать код нельзя.

а часто тебе приходилось «перепиливать встроенный компилятор»?

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

На самом деле, примечательна история появления поддержки SSE2 в SBCL: сначала это была просто библиотека, расширяющая компилятор.

mv ★★★★★
()
Ответ на: комментарий от vaino

никто такого не говорил, наоборот - супер же, катайтесь на здоровье

Я вижу, что много философии огорчают молодые горячие умы, жаждущие действия.

mv ★★★★★
()
Ответ на: комментарий от mv

Лучше CL быть можно, но сложно. И сисярп не лучше.

сразу видно джедая (с)

В языке Си генерировать и компилировать код нельзя.

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

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

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

На самом деле, примечательна история появления поддержки SSE2 в SBCL:

ох уж этот наколенный sbcl ;)

vaino
()
Ответ на: комментарий от mv

Я вижу, что много философии огорчают молодые горячие умы, жаждущие действия.

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

vaino
()
Ответ на: комментарий от abalakin

А что есть такого в С, что не является «мелким» улучшением ассемблера? Вывод: C и ассемблер настолько близки, что почти один язык. И подобные сравнения можно делать для любого языка и С (Pascal почти С; Java тоже почти С, работающий в виртуальной машине написанной на почти С).

Так что давайте не проводить столь поверхностных аналогий.

NegatiV
()
Ответ на: комментарий от vaino

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

Концепция эквивалентности двух сущностей.

mv ★★★★★
()
Ответ на: комментарий от vaino

прямо уж генерировать даже нельзя? :)

Генерировать код программы? Нет, конечно!

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

Какое это имеет отношение к языку?

в CL разве не так?

Нет.

mv ★★★★★
()
Ответ на: комментарий от mv

Нет.

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

Какое это имеет отношение к языку?

см. выше

Генерировать код программы? Нет, конечно!

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

vaino
()
Ответ на: комментарий от vaino

ссылку на документацию - как можно получить исполняемый файл

http://www.lispworks.com/documentation/lw61/DV/html/delivery-41.htm#pgfId-853657

или разделяемую библиотеку из CL

http://www.lispworks.com/documentation/lw61/DV/html/delivery-42.htm#pgfId-865189

или ты всего-лишь интерпретацию кода имел ввиду?

И это тоже можно.

см. выше

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

И даже если использовать библиотеки и вызовы внешнего компилятора, это ж смех по сравнению с поддержкой рантаймной генерации кодв в лиспе.


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

Про макросы ляпнул вообще не в тему. В лиспе код программы - это список, хоть rplacd'ом его собирай, хоть строчку собирай и список ридером из неё читай.

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

Я как-то с год или два назад попросил тут продемонстировать возможность изменить поведение сишечной программы из самой программы на самом простом примере. Закончилось демагогией со стороны оппонента и хоть и хаком (на системтапе), но хоть каким-то, с моей стороны.

mv ★★★★★
()
Ответ на: комментарий от mv

http://www.lispworks.com/documentation/lw61/DV/html/delivery-41.htm#pgfId-853657
Ткни меня носом в пункт ANSI C, где сказано, как можно сгенерировать сишный код, скомпилировать его в машинный и тут же начать использовать?

вот именно - в С это делается так же как и в твоем LW, сторонними от ЯП средствами, а тебе лишь бы доказать, что в лиспе что-то сделано лучше, а по факту - один в один как в примитивном и древнем С

Про макросы ляпнул вообще не в тему

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

Я как-то с год или два назад попросил тут продемонстировать возможность изменить поведение сишечной программы из самой программы на самом простом примере

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

http://root.cern.ch/drupal/content/cint

засчитываешь как решение? или использование LW для компиляции - честно, а CINT для интерпретации С - нет?

vaino
()
Ответ на: комментарий от vaino

вот именно - в С это делается так же как и в твоем LW, сторонними от ЯП средствами, а тебе лишь бы доказать, что в лиспе что-то сделано лучше, а по факту - один в один как в примитивном и древнем С

Нет, в лиспе (CL) есть штатные read, eval, compile, load. В Си этого нет. Ты путаешь компиляцию кода и сборку бинарника.

засчитываешь как решение? или использование LW для компиляции - честно, а CINT для интерпретации С - нет?

Не засчитываю, лиспворкс тут не при чём. Возьми вместо LW любую другую реализацию ANSI CL, и результат будет тем же.

mv ★★★★★
()
Ответ на: комментарий от mv

В языке Си генерировать и компилировать код нельзя.

Генерировать можно, но в виде строк, а это ад по сравнению с лиспами.

Reset ★★★★★
()
Ответ на: комментарий от mv

Нет, в лиспе (CL) есть штатные read, eval, compile, load. В Си этого нет. Ты путаешь компиляцию кода и сборку бинарника.

не путаю, runtime компиляция кода давно есть в JS/Lua/Basic и пр. динамических ЯП аки CL, и делается она там как и положено - автоматически, смысл вообще руками вызывать компиляцию? вот сборка бинарника - отдельная «ручная» задача для разных ЯП, или у тебя претензия, что С не динамический ЯП и ты хотел это показать?

Не засчитываю, лиспворкс тут не при чём. Возьми вместо LW любую другую реализацию ANSI CL, и результат будет тем же.

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

П.С. забавно, но найти даже драфт стандарта CL в PDF нереально, предлагается читать «не стандарт» в виде 15Мб HTML или PS; в С с этим гораздо лучше

vaino
()
Ответ на: комментарий от NegatiV

А что есть такого в С, что не является «мелким» улучшением ассемблера? Вывод: C и ассемблер настолько близки, что почти один язык.

Не надо путать божий дар и яичницу. На ассемблере можно такие вещи вытворять, что С и не снились (если конечно ассемблерные вставки не делать).

Другой вопрос — сложность С/С++ и ассемблера, и их синтаксис — тут надеюсь вопросов тоже нет :)

И подобные сравнения можно делать для любого языка и С (Pascal почти С; Java тоже почти С, работающий в виртуальной машине написанной на почти С).

Опять таки вы путаете класс алгоритмических языков (они действительно почти как близнецы в сравнении с тем же лиспом, прологом, фортом) и языков с близким синтаксисом. А Java вообще полу-интерпретируемый язык, хотя и слизанный когда-то с С++.

abalakin ★★
()
Ответ на: комментарий от vaino

не путаю, runtime компиляция кода давно есть в JS/Lua/Basic и пр. динамических ЯП аки CL, и делается она там как и положено - автоматически, смысл вообще руками вызывать компиляцию?

Отличай eval от compile.

вот сборка бинарника - отдельная «ручная» задача для разных ЯП, или у тебя претензия, что С не динамический ЯП и ты хотел это показать?

Это у вас претензии на то, что из сишной программы модифицировать саму программу на лету - нефиг делать. Ну, можно в некоторых случаях (наличие libtcc или возможности вызвать gcc и dlopen), но боль от процесса нивелирует его результат. В отличии от языков, где горячее обновление - родная фича, которую очень легко использовать.

ты все еще про сборку бинарника?

Нет, я всё ещё про наличие возможности генерировать код, компилировать и тут же исполнять в стандарте языка. Один конкретно взятый интерпретатор Си - это частность, а не стандарт.

П.С. забавно, но найти даже драфт стандарта CL в PDF нереально, предлагается читать «не стандарт» в виде 15Мб HTML или PS; в С с этим гораздо лучше

Все претензии к ANSI.

А какие сложности с постскриптом?

mv ★★★★★
()
Ответ на: комментарий от NegatiV

И да, реквестирую у вас реализацию наследования (с динамическим связыванием функций) на С.

Первый вопрос а зачем? — часто и так ясно кто будет вызывать. Но если очень надо, то с использованием указателей функций делается примерно так

typedef (*mystruct_method)(mystruct *);
struct mystruct
{
  mystruct_method method;
};
а потом каждый новый наследник определяет свою method. Насколько я понимаю примерно тоже самое сделано и в С++, только скрытно.

abalakin ★★
()
Ответ на: комментарий от mv

Отличай eval от compile.

отличаю, просто ты их вместе написал

В отличии от языков, где горячее обновление - родная фича, которую очень легко использовать.

для частных задач, где имеет смысл использовать динамические ЯП, и таких задач даже для указанных ЯП немного, а вот например с С можно сделать так:

#include <libtcc.h>

int main()
{
    TCCState *s = tcc_new();

    tcc_set_output_type(s, TCC_OUTPUT_EXE);
    tcc_compile_string(s, "int main(){ printf(\"hello, world!\n\"); }");
    tcc_output_file(s, "1");

    system("./1");

    tcc_delete(s);
}

140Кб при -Ofast, зависимость только от libc, все в себе - один файл, возможность генерировать so,exe,obj или исполнять код прямо в памяти, 600Кб ОЗУ ( перед tcc_delete ), а сколько нужно ОЗУ и места на диске, чтоб реализовать такую функциональность( so,exe,... ) с CL? можно брать любую живую реализацию, это я к тому, что у каждого ЯП и даже каждой его реализации есть свои задачи, смысл требовать от С динамики? она прекрасно живет поверх С в виде JS, lua и даже python

А какие сложности с постскриптом?

поиск в okular и evince не работает, нет удобной навигации ну и т.д по мелочи

vaino
()
Ответ на: комментарий от vaino

140Кб при -Ofast, зависимость только от libc, все в себе - один файл, возможность генерировать so,exe,obj или исполнять код прямо в памяти, 600Кб ОЗУ ( перед tcc_delete )

Твой пример у меня не работает на UCOS-II, хотя там сишечка... Правда, процессор не x86, и ось не линукс.

а сколько нужно ОЗУ и места на диске

Как подберёшься к функциональности CL, так места в памяти и на диску сразу же столько начнёт занимать. Он же жрёт столько не потому что злой, а потому что много функциональности.

смысл требовать от С динамики

Смысл сраться по теме недостаточной навороченности CL? CL наворочен, и с этим даже спорить не захочется, если наискосок пробежаться по вводным параграфам глав в ClTl2.

mv ★★★★★
()
Ответ на: комментарий от vaino

Ха, да у тебя ещё и system() используется! Т.е. даже с помощью libtcc нельзя скомпилировать код в память своего процесса? Или можно?

mv ★★★★★
()
Ответ на: комментарий от vaino

поиск в okular и evince не работает, нет удобной навигации ну и т.д по мелочи

Для этого есть CLHS, в емаксе (slime) есть интеграция.

mv ★★★★★
()
Ответ на: комментарий от mv

Твой пример у меня не работает на UCOS-II, хотя там сишечка... Правда, процессор не x86, и ось не линукс.

еще одно док-во, что всему свое место

Как подберёшься к функциональности CL, так места в памяти и на диску сразу же столько начнёт занимать.

как минимум к библиотекам это не относится, не будешь спорить, что тут С уместней?

Он же жрёт столько не потому что злой, а потому что много функциональности.

а случаи бывают разные, я вот использую libtcc вместе с sqlite, компактное и быстрое решение, человек скачал 350Кб-ю библиотеку, просто слинковался со статической версией или подгрузил ее средствами sqlite, и, даже не написав строчки кода, получил возможность использовать большую часть PL/SQL поверх sqlite на своем любимом ЯП или даже без него, такого рода решение на CL будет и громоздким и неюзабельным в общем случае

Смысл сраться по теме недостаточной навороченности CL?

смысл вообще сраться? ну нравиться тебе CL, но не стоит ж постоянно всем это показывать, особенно в топиках про другие ЯП

vaino
()
Ответ на: комментарий от mv

Ха, да у тебя ещё и system() используется! Т.е. даже с помощью libtcc нельзя скомпилировать код в память своего процесса? Или можно?

это пример того, что ANSI CL не умеет ;) а скомпилировать в память очень просто - указываешь TCC_OUTPUT_MEMORY, получаешь указатель на функцию через tcc_get_symbol и вызываешь напрямую

vaino
()
Ответ на: комментарий от mv

Для этого есть CLHS, в емаксе (slime) есть интеграция.

знаю, я ж писал про вариант в HTML

vaino
()
Ответ на: комментарий от vaino

как минимум к библиотекам это не относится, не будешь спорить, что тут С уместней?

Смотря каким. Если в библиотеке шибко заумная логика, которую проще на другом языке написать, то не соглашусь. Но сейчас обычно используют другие способы подключения внешней функциональности, shared object не так актуален.

mv ★★★★★
()
Ответ на: комментарий от vaino

это пример того, что ANSI CL не умеет ;)

ANSI C тоже system() не умеет ;)

Я могу через ffi твой пример с libtcc за 5 минут прикрутить к любому живому ANSI CL ;)

mv ★★★★★
()
Ответ на: комментарий от vaino

а есть достойные на CL? чтоб не уступали аналогам на С

Ты думаешь, что на лиспе софта совсем не пишут? :) Есть вещи, аналогов которым вообще нет.

mv ★★★★★
()
Ответ на: комментарий от mv

Я могу через ffi твой пример с libtcc за 5 минут прикрутить к любому живому ANSI CL ;)

да, это популярная практика для CL

vaino
()
Ответ на: комментарий от mv

Ты думаешь, что на лиспе софта совсем не пишут? :)

пишут, но пощупать его на практике удается немногим, разве что можно на lisper.ru зайти, чтоб хоть косвенно им попользоваться

vaino
()
Ответ на: комментарий от vaino

Забавная штука (пример на tcc). Вот думаю его к своему проекту прикрутить. Но есть куча вопросов.

Насколько он переносим (на сайте вроде есть Linux и Windows)? Будет ли работать на маках? Можно ли использовать переменные основной программы (точнее получить доступ к переменным созданной программы/функции или передать что-то в качестве аргумента)? Насколько быстрая компиляция мелких функций в 10-50 строчек (хотя это надо экспериментировать)?

В общем вопросов много. Буду рад если хотя бы на часть их ответите. Хотя в ближайший релиз все равно включить не успею :(

abalakin ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.