M>>QDom в Qt очень медленный. Как-никак, на каждый элемент создается по QDomElement, да еще с постоянными кастами из QDomNode в QDomElement и обратно Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
WF>ИМХО, работать руками что через DOM, что через SAX — слишком низкоуровневое занятие. Я бы в такой ситуации поискал маппинг XML->объекты Вот, например, boost::serialization вроде умеет XML поднимать/сохранять. Не знаю, правда, его фич и насколько он гибок.
Тут надо сразу разделиться. Демону такая обработка XML не нужна — по вполне понятным причинам. Но она, возможно, может понадобиться клиенту. Буст... Не знаю, не знаю. Половина РСДН им пользуется и нарадоваться не может. Надо будет пощупать....
Не надо забывать о том, что Шеридан категорически против ХМЛя, настаивая на сериализации напрямую в поток. Другой вопрос — а можно ли будет безпроблем считать этот поток из других сред — Явы там, Питона...
Здравствуйте, Mamut, Вы писали:
M>>>Шеридан предложил, а я поддеожал идею использовать в этом деле Qt. A>>Согласен на 100%. A>>Компилятор какой? то что GCC понятно, но от какой версии плясать? A>>Например в Fedore 4 стоит уже GCC 4.0.0.8...
Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк
3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух
ориентироваться?
A>>В какой среде? (KDevelop или из ком.строки) A>>и т.д.
M>ИМХО, не имеет значения. Например, я если и буду участвовать, то буду пользовать VS.NET 2003 Буду ... эээ... windows release manager M>А если серьезно, то под Линухом это, скорее всего, будет gcc + KDevelop.
Может более кардинально подойти? CMake например. Умеет создавать проекты для разных сред в том
числе (вроде) и для KDeveloper. И что интересно и под VC 6/2003. Более того KDE активно его использует. www.cmake.org
M>>>В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю). A>>меня почему-то больше тянет в сторону SQL-Lite M>Меня тоже , но поставляемый с Qt 3.x драйвер поддерживает только SQLite 2, поддержка 3-го появится только в четвертой кути. А человеческих реализаций доступа к SQLite, да еще и кросс-платформенных, и нет (чтобы обернуть их в качестве драйвера). Главный минус скулита — это отсутствие bidirectional cursors (есть только forward курсоры). А всякие fetch_table работают довольно медленно на сколь-нибудь больших объемах данных. Второй минус — это отсутствие человеческого ALTER TABLE.
А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ).
M>Если первая (главная) проблема может не такая и главная (зависит от имплементации демона), то вторая может стать серьезным препятствием при реструктуризации базы данных большого объема.
+
A>>Может пока просто для одного пользователя сделать. Освои реструктуризатор, gSOAP, сеть, БД. A>>По моему и так уже не плохо для начала. Вроде крутых линуксоидов пока не видно
M>Лучше уж сразу делать по-человечески, имхо. Как я тут где-то уже писал, гуи-часть — это ерунда при условии человеческого демона ("человеческий демон" — этакий оксюморон получился )
+
Здравствуйте, aka50, Вы писали:
A>Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк A>3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух A>ориентироваться?
Чтоото мешает обновится?
Хотя в принципе согласен...
A>А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ).
А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. А от бд я изначально предлагал абстрагироватся.
Кстати есть предложение указывать БД еще при сборке (на #ifdef'ах разрулить) чтоб не терять в скорости...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, aka50, Вы писали:
A>>Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк A>>3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух A>>ориентироваться? S>Чтоото мешает обновится?
Если вся система построена 3.4 зачем одну вещь строить 4-кой. К тому же не известно
когда она до stable доживет. Но при этом бонус остается — то что компиляется 3.3/3.4
будет (90%) компиляться и 4-кой. Это как под виндой программу только под например Longhorn
затачивать . Область использование резко сужается.
A>>А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ). S>А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. А от бд я изначально предлагал абстрагироватся. S>Кстати есть предложение указывать БД еще при сборке (на #ifdef'ах разрулить) чтоб не терять в скорости...
Дык это OTL и позволяет делать. ИМХО вполне адекватная либа.
1. Похожа на STL
2. Поддерживает достаточно большое количество БД:
The current version of the OTL supports Oracle 7 (natively via OCI7), Oracle 8 (natively via OCI8), Oracle 8i (natively via OCI8i), Oracle 9i (natively via OCI9i), Oracle 10g (natively via OCI10g), DB2 (natively via DB2 CLI), ODBC 3.x as well as ODBC 2.5 compliant data sources in MS Windows and Unix (e.g. Oracle, MS SQL Server, Sybase, MySQL, DB2, Interbase / Firebird, PostgreSQL, SQLite, etc.). The list of supported database backends is constantly growing.
#include <iostream>
using namespace std;
#include <stdio.h>
#define OTL_ODBC_MYSQL // Compile OTL 4/MyODBC
// #define OTL_ODBC_UNIX // uncomment this line if UnixODBC is used#include <otlv4.h> // include the OTL 4 header file
otl_connect db; // connect objectvoid select()
{
otl_stream i(1, // buffer size"select * from test_tab",
// SELECT statement
db // connect object
);
// create select stream
otl_column_desc* desc;
int desc_len;
desc=i.describe_select(desc_len);
for(int n=0;n<desc_len;++n){
cout<<"========== COLUMN #"<<n+1<<" ==========="<<endl;
cout<<"name="<<desc[n].name<<endl;
cout<<"dbtype="<<desc[n].dbtype<<endl;
cout<<"otl_var_dbtype="<<desc[n].otl_var_dbtype<<endl;
cout<<"dbsize="<<desc[n].dbsize<<endl;
cout<<"scale="<<desc[n].scale<<endl;
cout<<"prec="<<desc[n].prec<<endl;
cout<<"nullok="<<desc[n].nullok<<endl;
}
}
int main()
{
otl_connect::otl_initialize(); // initialize ODBC environmenttry{
db.rlogon("uid=scott;pwd=tiger;dsn=mysql"); // connect to ODBC
otl_cursor::direct_exec
(
db,
"drop table test_tab",
otl_exception::disabled // disable OTL exceptions
); // drop table
otl_cursor::direct_exec
(
db,
"create table test_tab(f1 int, f2 varchar(30), f3 text)"
); // create table
select(); // select records from table
}
catch(otl_exception& p){ // intercept OTL exceptions
cerr<<p.msg<<endl; // print out error message
cerr<<p.stm_text<<endl; // print out SQL that caused the error
cerr<<p.var_info<<endl; // print out the variable that caused the error
}
db.logoff(); // disconnect from ODBCreturn 0;
}
Здравствуйте, aka50, Вы писали:
A>Если вся система построена 3.4 зачем одну вещь строить 4-кой. К тому же не известно A>когда она до stable доживет. Но при этом бонус остается — то что компиляется 3.3/3.4 A>будет (90%) компиляться и 4-кой. Это как под виндой программу только под например Longhorn A>затачивать . Область использование резко сужается.
Ок, согласен. Раз 4ка не стабл занчит делать со стаблем.
A>Дык это OTL и позволяет делать. ИМХО вполне адекватная либа. A>1. Похожа на STL A>2. Поддерживает достаточно большое количество БД:
Бесплатна ? пости линк в БД
Здравствуйте, Sheridan, Вы писали:
S>А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. Это утопия.
A>>Дык это OTL и позволяет делать. ИМХО вполне адекватная либа. A>>1. Похожа на STL A>>2. Поддерживает достаточно большое количество БД: S>Бесплатна ? пости линк в БД
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, HotDog, Вы писали:
HD>>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.
AVK>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.
+
Здравствуйте, Sheridan, Вы писали:
S>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших Или ты нехочеш переносить янус в линукс?
Лично моя улыбка за эту чущь:
шарп недолюбливаю изза того что оно всетаки интерпритатор
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
S>>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших
AVK>А я уже говорил — не сделаете вы его. Если бы вы делали на mono или Java, да не трехзвенку, а обычного клиента, то небольшие шансы еще были бы. А так их 0 с минусом.
Не, ну, если им постоянно напоминать, что они его не сделают, то глядишь что-то они да сделают. Вот только можно ли будет этим полноценно пользоваться и насколько это чудо сможет развиваться?
В общем, согласен, что куда проще было бы перетащить Янус под Моно или переписать на Яве. А это все баловство.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sheridan, Вы писали:
ехидным "ню-ню"...
S>Ну так поправь. Что есть ассембли?
Давай я поправлю.
Если не хочешь выглядить шутом гороховым, то просто не трепись о том, в чем вообще ничего не понимашь. На этом сайте информации о производительности дотнета и том, что в нем применяется JIT-компиляция море. Зайди в раздел статей по дотнету... Сделай поиск по форумам. Глядишь в следущющий раз никто смеяться не будет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sheridan, Вы писали:
MC>>Да и то, вроде-бы IL компилируеться в машинный код в первый запуск. S>угу, и во второй и в 3й... строчечка за строчечкой..
Если твои познания в С++ столь же глубоки, то этот проект ждет бльшое будущее... вот в этом форуме.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
Вот, например, boost::serialization вроде умеет XML поднимать/сохранять. Не знаю, правда, его фич и насколько он гибок.
Буду ... эээ... windows release manager 
Мы уже победили, просто это еще не так заметно...
Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших 