Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
_Harry писал(а): Дык пусть и будет и так и этак. Кто мешает подключить/отключить нужную библиотеку. дык, проблема в том, что разрастается синтаксис. То есть получаются имена с дублирующими функциями. впрочем, оно и есть и так и этак. _Harry писал(а): Кстати действительно имеет смысл сделать что то вроде fld.fts, но без сохранения имен полей и размера структуры в коде. Точнее лучше сделать чтобы это было опциями одной билиотеки типа DEBUG/RELEASE.
а еще лучше сделать TURNKEY . То есть, чтобы в готовую программу входили только необходимые данные (как в SMAL32)...
но это быстро не сделается 8(
[quote="_Harry"]Дык пусть и будет и так и этак. Кто мешает подключить/отключить нужную библиотеку.[/quote] дык, проблема в том, что разрастается синтаксис. То есть получаются имена с дублирующими функциями. впрочем, оно и есть и так и этак.
[quote="_Harry"]Кстати действительно имеет смысл сделать что то вроде fld.fts, но без сохранения имен полей и размера структуры в коде. Точнее лучше сделать чтобы это было опциями одной билиотеки типа DEBUG/RELEASE.[/quote]
а еще лучше сделать TURNKEY . То есть, чтобы в готовую программу входили только необходимые данные (как в SMAL32)...
но это быстро не сделается 8(
|
|
|
|
Добавлено: Вс июн 07, 2009 18:33 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): ни на один из пунктов я дать окончательного ответа не могу (получается что и так бывает надо и этак) ...
Дык пусть и будет и так и этак. Кто мешает подключить/отключить нужную библиотеку.
Кстати действительно имеет смысл сделать что то вроде fld.fts, но без сохранения имен полей и размера структуры в коде. Точнее лучше сделать чтобы это было опциями одной билиотеки типа DEBUG/RELEASE.
Мне так вот кажется
[quote="mOleg"]
ни на один из пунктов я дать окончательного ответа не могу (получается что и так бывает надо и этак) ...[/quote]
Дык пусть и будет и так и этак. Кто мешает подключить/отключить нужную библиотеку.
Кстати действительно имеет смысл сделать что то вроде fld.fts, но без сохранения имен полей и размера структуры в коде. Точнее лучше сделать чтобы это было опциями одной билиотеки типа DEBUG/RELEASE.
Мне так вот кажется :shuffle;
|
|
|
|
Добавлено: Вс июн 07, 2009 12:05 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: хранить ли вообще имена структур после сборки кода
если для отладки понадобится поставить какой-либо эксперимент ...
[quote]хранить ли вообще имена структур после сборки кода [/quote]если для отладки понадобится поставить какой-либо эксперимент ...
|
|
|
|
Добавлено: Пт июн 05, 2009 10:03 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
factor использует макросы, которыми генерирует требуемый код, см. в направлении functor:
(правда, название для слова он выбирал, чтобы специально дразнить функциональщиков, это не настоящий функтор)
обзорно применение можно глянуть здесь (особо не вдаваясь в детали)
http://factor-language.blogspot.com/search?q=functor%3A
в чём там суть - всё разворачивается в отдельные слова (вместе с операциями доступа к полям)
factor использует макросы, которыми генерирует требуемый код, см. в направлении functor:
(правда, название для слова он выбирал, чтобы специально дразнить функциональщиков, это не настоящий функтор)
обзорно применение можно глянуть здесь (особо не вдаваясь в детали)
http://factor-language.blogspot.com/search?q=functor%3A
в чём там суть - всё разворачивается в отдельные слова (вместе с операциями доступа к полям)
|
|
|
|
Добавлено: Ср июн 03, 2009 20:19 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
кстати, со структурами вообще несколько вопросов возникает.
1) хранить ли поля структур в общем пространстве имен (базовом словаре) либо для каждой структуры делать отдельное
2) на сколько сложные структуры поддерживать (можно очень просто, как сделано в СПФе c: -- и CONSTANT ; а можно как начале топика)
3) хранить ли вообще имена структур после сборки кода
4) автоматизация импорта структур из хидеров (сишных, как наиболее доступных)
ни на один из пунктов я дать окончательного ответа не могу (получается что и так бывает надо и этак)
поэтому хочется какую-то выдумать универсальную синтаксическую конструкцию, позволяющую делать и так и этак, при этом не городить слишком много.
Сейчас у меня самого 4 варианта:
vocs/ struct.fts - с упрятыванием полей внутрь словарей (изолированные пространства имен)
memory/ fld.fts - чуточку более сложные, чем СПФовские, но по сути такие же простые
memory/ ns.fts - то, что представлено в начале данного топика (сложновато по сравнению с предыдущими)
и набросок .\samples\sketches\typedef.fts для импорта хидеров предназначенный (сложновато оно получается)
а в итоге бы это все слить в один (два, если с учетом импорта хидеров) вариант...
кстати, со структурами вообще несколько вопросов возникает.
1) хранить ли поля структур в общем пространстве имен (базовом словаре) либо для каждой структуры делать отдельное
2) на сколько сложные структуры поддерживать (можно очень просто, как сделано в СПФе c: -- и CONSTANT ; а можно как начале топика)
3) хранить ли вообще имена структур после сборки кода
4) автоматизация импорта структур из хидеров (сишных, как наиболее доступных)
ни на один из пунктов я дать окончательного ответа не могу (получается что и так бывает надо и этак)
поэтому хочется какую-то выдумать универсальную синтаксическую конструкцию, позволяющую делать и так и этак, при этом не городить слишком много.
Сейчас у меня самого 4 варианта:
vocs/ struct.fts - с упрятыванием полей внутрь словарей (изолированные пространства имен)
memory/ fld.fts - чуточку более сложные, чем СПФовские, но по сути такие же простые
memory/ ns.fts - то, что представлено в начале данного топика (сложновато по сравнению с предыдущими)
и набросок .\samples\sketches\typedef.fts для импорта хидеров предназначенный (сложновато оно получается)
а в итоге бы это все слить в один (два, если с учетом импорта хидеров) вариант...
|
|
|
|
Добавлено: Сб май 30, 2009 19:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Жаль, как же переносимость?
В том то и прикол, что стандарт ничего такого не обеспечивает и даже не обещает 8(
[quote="вопрос"]Жаль, как же переносимость?[/quote]
В том то и прикол, что стандарт ничего такого не обеспечивает и даже не обещает 8(
|
|
|
|
Добавлено: Пт май 29, 2009 20:02 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Всё, стандарт пал под натиском ...
Жаль, как же переносимость?
Всё, стандарт пал под натиском ...
:) Жаль, как же переносимость? :D
|
|
|
|
Добавлено: Пт май 29, 2009 19:56 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): уже - это " от когда"? сейчас уже вопрос писал(а): что именно тут имеется ввиду - что не выгодно?
в скобках отвечено.
[quote="вопрос"]уже - это " от когда"?[/quote] сейчас уже 8)
[quote="вопрос"]что именно тут имеется ввиду - что не выгодно?[/quote]
в скобках отвечено.
|
|
|
|
Добавлено: Пт май 29, 2009 18:19 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: уже не вижу (для себя) в некоторых моментах мне даже поддержку стандарта делать не выгодно (урезаю возможности без видимой пользы)
уже - это " от когда"?
что именно тут имеется ввиду - что не выгодно?
[quote][b]уже [/b]не вижу (для себя) в некоторых моментах мне даже поддержку стандарта делать [b]не выгодно [/b](урезаю возможности без видимой пользы) [/quote]
:shock: :shock:
уже - это " от когда"?
что именно тут имеется ввиду - что не выгодно?
|
|
|
|
Добавлено: Пт май 29, 2009 17:00 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): должно быть портируемо под стандарт
стандарт пора делать свой
смысла в стандарте уже не вижу (для себя)
в некоторых моментах мне даже поддержку стандарта делать не выгодно (урезаю возможности без видимой пользы) тем более, что портировать код между системами всеравно не просто по огромному списку причин
[quote="вопрос"]должно быть портируемо под стандарт[/quote]
стандарт пора делать свой
смысла в стандарте уже не вижу (для себя)
в некоторых моментах мне даже поддержку стандарта делать не выгодно (урезаю возможности без видимой пользы) тем более, что портировать код между системами всеравно не просто по огромному списку причин
|
|
|
|
Добавлено: Пт май 29, 2009 14:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mrack_ писал(а): пример прозрачного кода, красиво
+1 Много программ есть на паскале использующие структуры,
расчитываю перекодить на форт.
[quote="mrack_"]пример прозрачного кода, красиво[/quote]
+1 Много программ есть на паскале использующие структуры,
расчитываю перекодить на форт.
|
|
|
|
Добавлено: Чт май 28, 2009 12:27 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
должно быть портируемо под стандарт
должно быть портируемо под стандарт
|
|
|
|
Добавлено: Ср май 27, 2009 21:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
вопрос писал(а): Да, всё замечательно, но насколько это переносимо:
для СПФа портируемо
[quote="вопрос"]Да, всё замечательно, но насколько это переносимо:[/quote]
для СПФа портируемо :)
|
|
|
|
Добавлено: Ср май 27, 2009 18:28 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Да, всё замечательно, но насколько это переносимо:
такая работа со строками разве не исключительно форк-овская ?
Да, всё замечательно, но насколько это переносимо:
такая работа со строками разве не исключительно форк-овская ?
|
|
|
|
Добавлено: Ср май 27, 2009 17:40 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
пример прозрачного кода, красиво
пример прозрачного кода, красиво
|
|
|
|
Добавлено: Ср май 27, 2009 15:22 |
|
|
|
|