[@Carpe-diem]

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

Можно ли написать такое приложение для Андроид на С# или С++? И если да, то на чем лучше писать?

[@taras atavin]

программистов там мало, гораздо больше разработчиков. Специфика такая. запрос сшил-в БД отправил-данные в шаблон выплюнул. больше редко когда чего надо.

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

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

А вот в таких случаях очень удобно
Код PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function Draw(){
$Source=get_object_vars($this);
preg_match_all('/({)(\w+)(})/',$Template,$Matches);
foreach ($Matches[2] as $Match){
$Value='';
if (array_key_exists($Match,$Source)){
if (is_object($Source[$Match])) $Value=$Source[$Match]->Paint();
else $Value=$Source[$Match];
}
$Values[$Match]=$Value;
}
return str_replace($Matches[0],$Values,$Template);
}

Не смешно.

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

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

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

[@Fulcrum_013]

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

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

[@taras atavin]

При чём здесь конкретно CGI? Файлы предназначены в первую очередь для обмена. И другое приложение может быть написано на чём угодно от опкодов сетуни до c++.

[@Fulcrum_013]

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

константы сравнивать быстрее чем строки. а разреженный это по большому счету и есть ассоциативный. то есть к примеру чтобы можно было вот так сделать к примеру Concentration[AL2O3]+=Value и при этом концентрация либо прибавилась к уже существующей, либо добавилась в список если ее там еще нет(нулевая).

Не смешно.

Зато работает. Достаточно удобный в использовании шаблонизатор, хотя и без кэширования и предкомпиляции шаблона.

В первую очередь надо поддерживать двоичные форматы. Тем более при сохранении массивов.

Это если людям их потом читать не надо. я ж говорю реалии WEB-сервера они от реалий УВМ а тем более контроллера сильно отличаются.

[@taras atavin]

константы сравнивать быстрее чем строки.

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

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

Это если людям их потом читать не надо.

1. Для массивов тем более если надо. Хексредактор найти не сложно, а разобрать якобы текст из одних цифр - та ещё вешалка.
2. Файлы предназначены не для людей, а для приложений. Людям же надо читать в основном экранное представление, теми приложениями генерируемое, а сами файлы только на этапе отладки. А таблицу один чёрт с какого файла рисовать, если ты массив загрузил и во внутреннее двоичное представление перегнал, то дальше операции одни и те же.

[@Fulcrum_013]

Файлы предназначены в первую очередь для обмена.

Данные сессии предназначены для обмена между страницами одного сайта, а он обычно весь на PHP.

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

Правильно. кстати ассоциативный и разреженный по большому cчету синонимы. получается если в массиве Сoncentration элемента с ключем AL2O3 нет то считаем что он равен 0.

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

Файлы предназначены не для людей, а для приложений.

Не всегда. Логи например. Да и данные в массивах сессий преимущественно текстовые.

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

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

гораздо удобнее с HTML в данном случае. Дизайнер верстает, вставляя только имена выводимых данных, а скрипт наполняет их данными. Удобнее и дизайнеру и программисту. а массив он в том представлении в каком есть. Другое дело что в PHP массивы не типизированы. т.е. в одном массиве могут быть и строки и чисала и другие массивы и объекты классов. Я ж говорю - задачи разные. Задача PHP - препроцессор гипертекста.

[@taras atavin]

При чём здесь конкретно данные сессии? Файлы предназначены в первую очередь для обмена. А внутренние данные длительного хранения, будь то сессии php, или вордовый документ - во вторую очередь. В том числе для обмена с другим экземпляром того же приложения на другой машине, но не только, а вообще для обмена с любым приложением, которое понимает формата. Сохранить набранный текст можно и в оперативе, просто не выключая машину.

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

гораздо удобнее с HTML в данном случае. Дизайнер верстает, вставляя только имена выводимых данных, а скрипт наполняет их данными.

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

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

Правильно. кстати ассоциативный и разреженный по большому cчету синонимы. получается если в массиве Сoncentration элемента с ключем AL2O3 нет то считаем что он равен 0.

Ах вот это что. Каким боком здесь константы? Он же по определению динамический.

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

Не всегда. Логи например. Да и данные в массивах сессий преимущественно текстовые.

Вот я сейчас пишу прогу. Лог она сохраняет в xml и предназначен он не для человека, а для браузера, а уже структурированное экранное представление, которое он выводит, для человека.

[@Fulcrum_013]

1. Для массивов тем более если надо. Хексредактор найти не сложно, а разобрать якобы текст из одних цифр - та ещё вешалка.

Ага... и рисовать массив черным на зеленом, а при обновлении новые элементы по столбикам вниз обновляются подсвечиваясь clLime

Кстати реалии к примеру АСУП тоже от реалий АСУТП отличаются.
делал когда еще студентом был СЦПД(система централизованной подготовки данных) для заводского ВЦ. Так вот формат данных(который уже там был и под который пришлось соответственно подстраиваться) - текст определенной ширины(даже не BCD). массивы числовые, пустые десятичные позиции забиты нулями. Так удобнее обмениваться данными между компами (формат не привязан к архитектуре конкретной ЭВМ). И вообще без проблем увязываются в общую связку и ЕС (какие не помню но еще с лентопротяжками),на которых старая СЦПД была, и IBM пр-ва 60-ых которая все обсчитывала, и PC

[@taras atavin]

Ага... и рисовать массив черным на зеленом, а при обновлении новые элементы по столбикам вниз обновляются подсвечиваясь clLime

Издеваешься?

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

Так удобнее обмениваться данными между компами (формат не привязан к архитектуре конкретной ЭВМ).

Он и так не привязан. Пока размер байта хотябы кратен, можно хоть итаниум заставить обмениваться бинарниками с i8086.

Добавлено через 6 минут
А как Вы собираетесь на не равных байтах гонять текст? Он ведь даже к конкретной кодировке привязан.

[@Fulcrum_013]

Он и так не привязан.

Это если int на всех системах 4 байта float тоже 4 а double 8. А есть еще и паскаль у которого real 6 байт. а в принципе существуют и тринарные компы.

Издеваешься?

Это сначала ничего не понятно, потом мозг привыкает. И становишся недохакером, потому как от хакерства пользы ноль, а в бинарных файлах копаться АСУТП да и не только требует ( это я не о тебе, это я о нас обоих)

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

А как Вы собираетесь на не равных байтах гонять текст? Он ведь даже к конкретной кодировке привязан.

конвертер текста при таком формате все равно проще, мало того не зависит от формата вложенных в него данных. А кодировка ASCII тогда уже была.

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

А кодировка ASCII тогда уже была.

Кстати на практике не встречал компов в которых была бы другая кодировка первой половины (ну до 0x80), хотя с раритетами на местных заводах сталкиваться приходилось.

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

Ах вот это что. Каким боком здесь константы? Он же по определению динамический.

Константы ключей. к примеру #define Al2O3 0x100 и т.д. интовые ключи быстрее буде сравнивать и места будут занимать меньше чем строковый "AL2O3"

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

Лог она сохраняет в xml и предназначен он не для человека, а для браузера, а уже структурированное экранное представление, которое он выводит, для человека

а можно PHP между ними поставить. Прога лог пишет в текст, текст при этом отсылает за пределы УВМ, а там уже PHP скрипт из него браузерное представление делает. А можно в БД сохранять, которое тоже за пределами УВМ, так же как можно и в бинарник. PHP по запросу на просмотр вытаскивает из БД/преобразовывает.
А вообще xml предназначен для того чтобы его и браузер читал и человек читал/писал без напряга.

[@taras atavin]

конвертер текста при таком формате все равно проще, мало того не зависит от формата вложенных в него данных. А кодировка ASCII тогда уже была.

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

[@taras atavin]

А вообще xml предназначен для того чтобы его и браузер читал и человек читал/писал без напряга.

Попробуйте: Log.rar.

[@Fulcrum_013]

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

Я не об этом. каждая строка текста содержит одну запись состоящую из полей. поля числовые. Даже если придется конвертировать сам текст (из одной кодировки в другую) или даже будет неодинаковое количество бит в байте, то возможна просто посимвольная перекодировка, т.к. формат данных не зависит от внутреннего представления значений каждого из полей в памяти конкретной ЭВМ. Да и операторам которые все это набирают так удобней. позволяет к примеру при наборе отделить часть поля и поставить на автодублирование с предыдущей записи.

[@taras atavin]

Константы ключей. к примеру #define Al2O3 0x100 и т.д. интовые ключи быстрее буде сравнивать и места будут занимать меньше чем строковый "AL2O3"

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

[@Fulcrum_013]

Попробуйте: Log.rar.

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

[@taras atavin]

Это что то из нутрей Visual Studio?

У меня нет Visual studio. Это лог 3Dредактора. Пока на столько сырого, что в нём не чем редактировать саму модель.

[@taras atavin]

Где здесь:

инспектор с конструктором в перемешку?

[@CoolMind]

Кто здесь?

[@Fulcrum_013]

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

По большому счету надо делать систему которая по сложит AL и O в AL2O3 и сама генерит константы. Кстати насколько понимаю рассчитываемых соединений в плаке не так уж и много. Лаборатория хим.анализа и та не больше двух десятков соединений в составе металла/шихты дает, а обычно гораздо меньше.

[@taras atavin]

По большому счету надо делать систему которая по сложит AL и O в AL2O3 и сама генерит константы.

Это по определению не возможно.