[k155la3 26]

17 minutes ago, gosha-z said:

Boost Spirit (плюс развивается как самодостаточный проект)

Boost меня несколько пугает (пока), посмотрим, спасибо.

[AlexandrY 2]

12 minutes ago, k155la3 said:

Boost меня несколько пугает (пока), посмотрим, спасибо.

Берете нормальный пакет компонентов типа DevExpress и там всегда найдет run-time expression editor встроенный прямо в поля таблиц. 
В наше время писать доморощенный парсер - просто убивать время. Нынче парсеры и те на автомате генерируются.  
 

[V_G 8]

44 минуты назад, k155la3 сказал:

Нет, C# не подойдет.

Не скажу за редактор формул, но у меня в одной программе вполне сосуществуют С++ (MFC) и С# (WPF). На последнем реализовано отдельное окно с анализатором спектра звукового диапазона частот

[k155la3 26]

3 minutes ago, AlexandrY said:

Берете нормальный пакет компонентов типа DevExpress  . . .

Ok спасибо за инф.

[esaulenka 5]

19 minutes ago, k155la3 said:

Boost меня несколько пугает

Спирит, действительно, похоже весьма сложный (не доводилось использовать), а в целом Буст - очень качественная библиотека. Хорошая документация, примеры, продуманное API без побочных эффектов.

Главное - внутрь не смотреть, там внутри действительно страшно :-)

[jcxz 181]

10 минут назад, AlexandrY сказал:

В наше время писать доморощенный парсер - просто убивать время. Нынче парсеры и те на автомате генерируются.  

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

И с готовым придётся убить гораздо больше времени на переписывание всего с нуля. А свой код будет несложно перенести и доработать.

У нас так и было. Дошли до скриптов в устройстве  

[esaulenka 5]

9 minutes ago, jcxz said:

сохранения этих формул в приборе и выполнения их как скриптов

Придётся найти список движков скриптовых языков, и разобраться хотя бы в одном из них.

Лучше уж свой велосипед бесконечно пилить...

[AlexandrY 2]

13 minutes ago, jcxz said:

И с готовым придётся убить гораздо больше времени на переписывание всего с нуля. А свой код будет несложно перенести и доработать.

На портирование скриптового движка уходит в среднем пару дней. Тут разговор вести не о чем. 
А вот компоненты DevExpress - это эталон юзабельности. Поэтому при всех раскладах для UI на PC девэкспресу конкурентов нет. 

[k155la3 26]

29 minutes ago, esaulenka said:

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

Спасибо за ссылку. Я тоже склоняюсь к "велосипеду".

 

[jcxz 181]

42 минуты назад, esaulenka сказал:

Лучше уж свой велосипед бесконечно пилить...

Лучше... Тем более если за это платят  

[k155la3 26]

29 minutes ago, AlexandrY said:

На портирование скриптового движка уходит в среднем пару дней. Тут разговор вести не о чем. 
А вот компоненты DevExpress - это эталон юзабельности. Поэтому при всех раскладах для UI на PC девэкспресу конкурентов нет. 

Весч замечательная, хотя для моей задачи явно избыточна. На данный момент мне не подходит. 

Рассчитываю найти модуль CPP 10-20-50 kB кода где ЭТО реализовано. Без переменных, сложных мат. функций (только +-*/ степень, корень).

Если нет - ближайшая цель "прикрутить" python.

 

1 minute ago, jcxz said:

Лучше... Тем более если за это платят  

Да, есть такая гипотеза .... Но не в "тех" масштабах .....   

[alexunder 4]

1 hour ago, k155la3 said:

Нет, C# не подойдет. За ссылку спасибо, посмотрю.

Быстродействие тоже желательно, хотя и не очень критично. Поэтому если будет чистый С / C++  - оптимальный вариант.

 

Если у Вас проект в MSVS на C++, то он написан с MFC или аж голыми WinApi функциями? В MFC был компонент расширенного текстового редактора вроде (RichTextEdit), но насколько он гибок и многофункционален  -большой вопрос.

 

P.S. Пардон за навязчивость. Вариант на C# удобен тем, что вы быстрее его реализуете (при наличии знаний языка) и он будет более гибким и масштабируемым, ну и, как верно заметил @V_G, прикрутить C#-морду к backend, сделанному на C++ несложно.

[k155la3 26]

4 minutes ago, alexunder said:

(1)

Если у Вас проект в MSVS на C++, то он написан с MFC или аж голыми WinApi функциями? В MFC был компонент расширенного текстового редактора вроде (RichTextEdit), но насколько он гибок и многофункционален  -большой вопрос.

 

(2)

P.S. Пардон за навязчивость. Вариант на C# удобен тем, что вы быстрее его реализуете (при наличии знаний языка) и он будет более гибким и масштабируемым, ну и, как верно заметил @V_G, прикрутить C#-морду к backend, сделанному на C++ несложно.

(1) MSVC, CPP, MFC с вызовами Win32API. Сейчас менять платформу не буду, тк все уже сделано, надо только ф-лы прикрутить.

(2) Да, Вы абсолютно правы, тк MFC хоть и дает абсолютную гибкость и через него даже видно Win32, но .... очень много надо держать в памяти, что напрягает.

C# у меня в ближайших планах, и как раз в контексте который Вы и @V_G предлагаете.

 

[_pv 50]

16 minutes ago, k155la3 said:

Весч замечательная, хотя для моей задачи явно избыточна. На данный момент мне не подходит. 

Рассчитываю найти модуль CPP 10-20-50 kB кода где ЭТО реализовано. Без переменных, сложных мат. функций (только +-*/ степень, корень).

Если нет - ближайшая цель "прикрутить" python.

это питон-то в 10-20-50кБ?

модуль найти можно в книжке Б.Страуструпа, http://www.stroustrup.com/dc.c и добавить к нему недостающие функции.

если немного увлечься с добавлением, может получится что-то вроде https://github.com/rswier/c4 , самое забавное, что оно само себя распарсить может :)

ну а если не хватит, тогда есть libtcc или lua, пусть не 10-20, но в 100-200кБ вполне влезет.

[antis 1]

Lua не подойдет?