Здравствуйте, eao197, Вы писали:
E>Мало уступает, да?
На то есть разные мнения. Есть, напрмер, мнение что малость превосходит. А есть, что сильно...
E>А как тогда на C# сделать такое: А generic-и так могут?
АВК тебе уже сказал в чем проблема твоего вопроса. Могу повторить еще раз. Изучать тонкости твоих проблем и вникать в горы кода никто не хочет.
Скорее всего твои проблемы связанны с тем, что ты хочешь решать задачи на C# так же как если бы ты решал их на С++. Но это другой язык. Программирование на нем — это классическое ООП + компонентное проеграммирование. Если не задаваться целью решать задачи так же как на С++, то обычно, задачи решаются значительно поще и быстрее.
или как сделать сериализацию на С++ такой же простой как в дотнете.
МС++, о котором иедт речь в данном эссе, это конечно не С++. Это анаптация С++ к дотнету. Разница между ним и Шарпом уже не критична, так как все они позволяют использовать мошь дотнета. Так что о нем разговор особый.
VD>АВК тебе уже сказал в чем проблема твоего вопроса. Могу повторить еще раз. Изучать тонкости твоих проблем и вникать в горы кода никто не хочет.
А так всегда -- на словах все мудрецы и монстры. А как до реальных решений доходит, то "твои проблемы", "горы кода".
Я помниться когда-то спросил, почему Янус на C++ не был написан. Так я стал сразу одним из тех самых умных, которые никогда ничего не делают. А здесь реальная проблема, которая на C++ решилась без труда и могла бы быть решена еще проще. Но стоило всего лишь поинтересоваться, как ее решить средствами generic-ов, как C#-евангелисты отмазки начали приводить. Здорово (еще бы, это не C# c Python-ом в разработке игр применять). Только проблема в том, что я и так привел минимальный реальный код. В дейсвительности там еще больше навороты на более высоких уровнях есть. И на C++ это все работает и является сопровождаемым.
VD>Скорее всего твои проблемы связанны с тем, что ты хочешь решать задачи на C# так же как если бы ты решал их на С++.
Я не хочу решать задачи на C#. Мне просто интересно, как это могло бы быть.
VD>Если ты действительно хочешь что-то сравнить, то порпробуй ответить на вопрос как на С++ сделать вот это: http://rsdn.ru/article/dotnet/dnetappcfg.xml
или как сделать сериализацию на С++ такой же простой как в дотнете.
Ok. Статью посмотрю. Подумаю.
Сериализаций для C++ как собак нерезанных. Сам персонально одной такой занимаюсь -- успешно применяется в production code уже около 2-х лет и нет проблем.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Если ты действительно хочешь что-то сравнить, то порпробуй ответить на вопрос как на С++ сделать вот это: http://rsdn.ru/article/dotnet/dnetappcfg.xml
или как сделать сериализацию на С++ такой же простой как в дотнете.
Посмотрел, увидел теже самые тоны кода. Подумал, не понял что должен был ответить.
Ну сделали вы для C# удобное решение с использованием встроенной в платформу поддержки XML сериализации и атрибутами (или как они в .Net-е называются). И что, это должно было продемонстрировать преимущества C# над C++? Ok. Если ты в этом уверен, то пусть в данной конкреной области будет так.
Алаверды привожу код на C++ для парсинга конфигов следующего вида:
Реализуется эта кухня следующим образом. Вот описания структур для хранения информации:
//! Коды операций над значениями источников данных.enum op_codes_t {
//! ==
op_equal,
//! !=
op_not_equal,
//! <
op_less,
//! <=
op_less_equal,
//! >
op_greater,
//! >=
op_greater_equal,
//! Неизвестный код операции.
op_invalid
};
//! Получить код операции по строковому начертанию.inline op_codes_t
op_code( const std::string & o )
{
if( "==" == o ) return op_equal;
if( "!=" == o ) return op_not_equal;
if( "<" == o ) return op_less;
if( "<=" == o ) return op_less_equal;
if( ">" == o ) return op_greater;
if( ">=" == o ) return op_greater_equal;
return op_invalid;
}
//
// if_t
//
//! Описание условия и действий, которые нужно выполнить, если
//! это условие выполняется.template< class T >
struct if_t
{
//! Код операции над значением.
op_codes_t m_op;
//! Правый операнд операции сравнения со значением источника данных.
T m_right;
//! Действия, которые нужно выполнить, если условие выполняется.
actions_t m_actions;
//! Конструктор по умолчанию.
if_t()
: m_op( op_invalid )
{}
//! Инициализирующий конструктор.
if_t(
op_codes_t op,
const T & right,
const actions_t & actions )
: m_op( op )
, m_right( right )
, m_actions( actions )
{}
//! Проверить условие.
/*! \return true, если условие выполняется. */bool
operator()(
//! Значение источника данных.const T & left ) const
{
if( op_equal == m_op ) return ( left == m_right );
if( op_not_equal == m_op ) return ( left != m_right );
if( op_less == m_op ) return ( left < m_right );
if( op_less_equal == m_op ) return ( left <= m_right );
if( op_greater == m_op ) return ( left > m_right );
if( op_greater_equal == m_op ) return ( left >= m_right );
return false;
}
};
//! Коды состояния источников данныхenum data_source_status_t {
//! Источник был зарегистрирован
e_data_source_reg,
//! Источник работает в обычном режиме
e_data_source_work,
//! Источник был дерегистрирован
e_data_source_dereg
};
//
// data_class_t
//
//! Описание класса источника данных.template< class T >
struct data_class_t
{
//! Приоритет источников данных этого класса.
/*! Предположительно, значения в диапазоне 0..9. */unsigned char m_priority;
//! Величина шрифта в пунктах.int m_font_size;
//! Список условий, которые нужно проверять.
std::vector< if_t< T > > m_conditions;
//! Действия, которые нужно выполнить, если ни одно
//! из условий не выполнено.
actions_t m_otherwise;
//! Действия, которые нужно выполнять при регистрации источника данных
actions_t m_on_register;
//! Действия, которые нужно выполнять при дерегистрации источника данных
actions_t m_on_deregister;
//! Конструктор по-умолчанию.
data_class_t()
: m_priority( 0 )
, m_font_size( 0 )
{}
//! Определить, какие действия нужно сделать над
//! данным значением источника данных.
/*!
В \a a помещается описание действий, которые
должны быть выполнены над значением. Если было выполнено
какое-то условие из m_conditions, то возвращаются действия,
назначенные для данного условия. В противном случае
возвращается значение m_otherwise.
\return Номер условия в m_conditions, которое
было выполнено (значение >= 0). -1, если
ни одно из условий в m_conditions не было
выполнено.
*/int
operator()(
//! Значение источника данных.const T & left,
//! Приемник описания действий.
actions_t & a,
//! Текущее состояние источника данных
data_source_status_t status = e_data_source_work ) const
{
switch( status )
{
case e_data_source_work:
for( int i = 0, i_max = (int)m_conditions.size();
i != i_max; ++i )
{
if( m_conditions[ i ]( left ) )
{
a = m_conditions[ i ].m_actions;
return i;
}
}
a = m_otherwise;
return -1;
case e_data_source_reg:
a = m_on_register;
return -2;
case e_data_source_dereg:
a = m_on_deregister;
return -3;
default:
a = m_otherwise;
return -1;
}
}
};
А вот сам парсинг конфигурационного файла:
//
// tag_op_t
//
/*!
Класс тега для разбора типа сравнения и величины для
сравнения.
*/template< class T >
class tag_op_t
: public cls_2::tag_scalar_t< T >
{
//! Псевдоним для базового типа.typedef cls_2::tag_scalar_t< T > base_type_t;
public :
//! Основной конструктор.
tag_op_t( cls_2::tag_t & owner )
: base_type_t( owner, "op", true )
{}
virtual ~tag_op_t()
{}
//! Определить, какой тип операции используется.virtual bool
compare_name( const char * name ) const
{
op_codes_t op = op_code( name );
if( op_invalid != op )
{
m_op = op;
return true;
}
return false;
}
//! Получить значения.void
get( if_t< T > & to ) const
{
to.m_op = m_op;
to.m_right = query_value();
}
private :
//! Тип операции.mutable op_codes_t m_op;
};
//! Заполнить ограничитель значений цветов.void
fill_color_constraint(
cls_2::scalar_constraint::one_of_t< std::string > & c )
{
c.add( "white" );
c.add( "black" );
c.add( "red" );
c.add( "dark_red" );
c.add( "green" );
c.add( "dark_green" );
c.add( "blue" );
c.add( "dark_blue" );
c.add( "cyan" );
c.add( "dark_cyan" );
c.add( "magenta" );
c.add( "dark_magenta" );
c.add( "yellow" );
c.add( "dakr_yellow" );
c.add( "gray" );
c.add( "dark_gray" );
c.add( "light_gray" );
}
//
// tag_if_t
//
/*!
Класс для разбора условий.
*/template< class T >
class tag_if_t
: public cls_2::tag_no_value_t
{
//! Псевдоним для базового типа.typedef cls_2::tag_no_value_t base_type_t;
private :
//! Условие сравнения.
tag_op_t< T > m_op;
//! Имя графического образа.
cls_2::tag_scalar_t< std::string > m_pixmap;
//! Фоновый цвет.
cls_2::tag_scalar_t< std::string > m_bkcolor;
//! Ограничения на значения цветов.
cls_2::scalar_constraint::one_of_t< std::string >
m_bkcolor_constraint;
//! Звуковой файл для воспроизведения.
cls_2::tag_scalar_t< std::string > m_sound;
//! Событие для log_writter.
tag_log_event_t m_log_event;
//! Список внешних приложений для запуска.
cls_2::tag_vector_of_tags_t< tag_launch_external_t >
m_launch_external;
//! Предикат для std::transform.static launch_external_t
launch_external_getter(
const tag_launch_external_t & tag )
{
return tag.get();
}
public :
tag_if_t(
const char * name,
bool is_mandatory )
: base_type_t( name, is_mandatory, true )
, m_op( self_tag() )
, m_pixmap( self_tag(), "pixmap", false )
, m_bkcolor( self_tag(), "bkcolor", false )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{
fill_color_constraint( m_bkcolor_constraint );
m_bkcolor.set_constraint( &m_bkcolor_constraint );
}
virtual ~tag_if_t()
{}
//! Получить значения.
if_t< T >
get() const
{
if_t< T > to;
m_op.get( to );
m_pixmap.query_opt_value( to.m_actions.m_pixmap );
m_bkcolor.query_opt_value( to.m_actions.m_bkcolor );
m_sound.query_opt_value( to.m_actions.m_sound );
if( m_log_event.is_defined() )
to.m_actions.m_log_event = m_log_event.get();
if( m_launch_external.is_defined() )
std::transform( m_launch_external.begin(),
m_launch_external.end(),
std::back_inserter(
to.m_actions.m_launch_external ),
launch_external_getter );
return to;
}
};
//
// tag_otherwise_t
//
/*!
Класс для разбора действий по умолчанию.
*/class tag_otherwise_t
: public cls_2::tag_no_value_t
{
//! Псевдоним для базового типа.typedef cls_2::tag_no_value_t base_type_t;
private :
//! Имя графического образа.
cls_2::tag_scalar_t< std::string > m_pixmap;
//! Фоновый цвет.
cls_2::tag_scalar_t< std::string > m_bkcolor;
//! Ограничения на значения цветов.
cls_2::scalar_constraint::one_of_t< std::string >
m_bkcolor_constraint;
//! Звуковой файл.
cls_2::tag_scalar_t< std::string > m_sound;
//! Событие для log_writter.
tag_log_event_t m_log_event;
//! Список внешних приложений для запуска.
cls_2::tag_vector_of_tags_t< tag_launch_external_t >
m_launch_external;
//! Предикат для std::transform.static launch_external_t
launch_external_getter(
const tag_launch_external_t & tag )
{
return tag.get();
}
public :
tag_otherwise_t( cls_2::tag_t & owner )
:
base_type_t( owner, "otherwise", false, true )
, m_pixmap( self_tag(), "pixmap", false )
, m_bkcolor( self_tag(), "bkcolor", false )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{
fill_color_constraint( m_bkcolor_constraint );
m_bkcolor.set_constraint( &m_bkcolor_constraint );
}
virtual ~tag_otherwise_t()
{}
//! Получить значения.void
get( actions_t & to ) const
{
m_pixmap.query_opt_value( to.m_pixmap );
m_bkcolor.query_opt_value( to.m_bkcolor );
m_sound.query_opt_value( to.m_sound );
if( m_log_event.is_defined() )
to.m_log_event = m_log_event.get();
if( m_launch_external.is_defined() )
std::transform( m_launch_external.begin(),
m_launch_external.end(),
std::back_inserter(
to.m_launch_external ),
launch_external_getter );
}
};
//
// tag_on_register_t
//
/*!
Класс для
*/class tag_on_register_t
: public cls_2::tag_no_value_t
{
//! Псевдоним для базового типа.typedef cls_2::tag_no_value_t base_type_t;
private :
//! Звуковой файл.
cls_2::tag_scalar_t< std::string > m_sound;
//! Событие для log_writter.
tag_log_event_t m_log_event;
//! Список внешних приложений для запуска.
cls_2::tag_vector_of_tags_t< tag_launch_external_t >
m_launch_external;
//! Предикат для std::transform.static launch_external_t
launch_external_getter(
const tag_launch_external_t & tag )
{
return tag.get();
}
public :
tag_on_register_t( cls_2::tag_t & owner )
:
base_type_t( owner, "on_register", false, true )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{}
virtual ~tag_on_register_t()
{}
//! Получить значения.void
get( actions_t & to ) const
{
m_sound.query_opt_value( to.m_sound );
if( m_log_event.is_defined() )
to.m_log_event = m_log_event.get();
if( m_launch_external.is_defined() )
std::transform( m_launch_external.begin(),
m_launch_external.end(),
std::back_inserter(
to.m_launch_external ),
launch_external_getter );
}
};
//
// tag_on_deregister_t
//
/*!
Класс для
*/class tag_on_deregister_t
: public cls_2::tag_no_value_t
{
//! Псевдоним для базового типа.typedef cls_2::tag_no_value_t base_type_t;
private :
//! Звуковой файл.
cls_2::tag_scalar_t< std::string > m_sound;
//! Событие для log_writter.
tag_log_event_t m_log_event;
//! Список внешних приложений для запуска.
cls_2::tag_vector_of_tags_t< tag_launch_external_t >
m_launch_external;
//! Предикат для std::transform.static launch_external_t
launch_external_getter(
const tag_launch_external_t & tag )
{
return tag.get();
}
public :
tag_on_deregister_t( cls_2::tag_t & owner )
:
base_type_t( owner, "on_deregister", false, true )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{}
virtual ~tag_on_deregister_t()
{}
//! Получить значения.void
get( actions_t & to ) const
{
m_sound.query_opt_value( to.m_sound );
if( m_log_event.is_defined() )
to.m_log_event = m_log_event.get();
if( m_launch_external.is_defined() )
std::transform( m_launch_external.begin(),
m_launch_external.end(),
std::back_inserter(
to.m_launch_external ),
launch_external_getter );
}
};
//
// tag_data_class_t
//
/*!
Класс для разбора описания типа источника данных.
*/template< class T >
class tag_data_class_t
: public cls_2::tag_scalar_t< std::string >
{
//! Псевдоним для базового типа.typedef cls_2::tag_scalar_t< std::string > base_type_t;
private :
//! Приоритет.
cls_2::tag_scalar_t< unsigned int > m_priority;
//! Ограничения на приоритет.
cls_2::scalar_constraint::min_max_t<
unsigned int >
m_priority_range;
//! Величина шрифта в пунктах.
cls_2::tag_scalar_t< int > m_font_size;
//! Тип списка тегов-условий.typedef cls_2::tag_vector_of_tags_t< tag_if_t< T > >
tag_conditions_t;
//! Список условий.
tag_conditions_t m_conditions;
//! Действия по умолчанию.
tag_otherwise_t m_otherwise;
//! Действие, выполняемое при регистрации источника данных
tag_on_register_t m_on_register;
//! Действие, выполняемое при дерегистрации источника данных
tag_on_deregister_t m_on_deregister;
public :
//! Основной конструктор.
tag_data_class_t(
const char * name,
bool is_mandatory )
:
base_type_t( name, is_mandatory )
, m_priority( self_tag(), "priority", true )
, m_priority_range( 0, 9 )
, m_font_size( self_tag(), "font_size", false )
, m_conditions( self_tag(), "if", false )
, m_otherwise( self_tag() )
, m_on_register( self_tag() )
, m_on_deregister( self_tag() )
{
m_priority.set_constraint( &m_priority_range );
}
virtual ~tag_data_class_t()
{}
//! Получить значения.
data_class_t< T >
get() const
{
data_class_t< T > to;
to.m_priority = m_priority.query_value();
if( m_otherwise.is_defined() )
m_otherwise.get( to.m_otherwise );
if( m_on_register.is_defined() )
m_on_register.get( to.m_on_register );
if( m_on_deregister.is_defined() )
m_on_deregister.get( to.m_on_deregister );
m_font_size.query_opt_value( to.m_font_size );
for( unsigned int i = 0, i_max = m_conditions.size();
i != i_max; ++i )
{
to.m_conditions.push_back(
m_conditions.at( i ).get() );
}
return to;
}
};
Собственно код был написан наспех и с тех пор рефакторингу из-за отсутствия времени не подвергался, поэтому классы tag_on_register_t и tag_on_deregister_t остались реализованными через copy&paste (изначально планировалось, что у них будет разных набор дочерних тегов).
Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А так всегда -- на словах все мудрецы и монстры. А как до реальных решений доходит, то "твои проблемы", "горы кода".
Умение четко и кратко сформулировать вопрос — это действительно твои проблемы. Многие вопросы остающиеся без ответа отсаются без оного только из-за того, что они слишком запвтаны и противоричивы.
E>Я помниться когда-то спросил, почему Янус на C++ не был написан. Так я стал сразу одним из тех самых умных, которые никогда ничего не делают.
Ты стал одним из тех которые никогда не сделают свою версию Януса. А про то что ты ничего не делаешь никто не говорил.
E> А здесь реальная проблема, которая на C++ решилась без труда и могла бы быть решена еще проще.
Опиши эту проблему. Только проблему, а не решение. И по возможности кратко и понятно.
E> Но стоило всего лишь поинтересоваться, как ее решить средствами generic-ов, как C#-евангелисты отмазки начали приводить.
Тебе замечательно ответил С++-ник. Попробуй воспринять его слова.
E> Здорово (еще бы, это не C# c Python-ом в разработке игр применять). Только проблема в том, что я и так привел минимальный реальный код. В дейсвительности там еще больше навороты на более высоких уровнях есть. И на C++ это все работает и является сопровождаемым.
Я так понимаю, ты не первый год программируешь. Раз так то должен понимать, что ценить нужно не навороты, а стройность и простоту кода. А навороты и дерзкие хаки пусть наворачивают молодые кул-хацкеры.
Лично я когда пишу код на Шарпе не испытываю потребности в замазывании дяр в виде трехэтажных конструкциях. Рефакторю часто. Паттерны разные применяю часто. А вот хаки как-то не нужны.
VD>>Скорее всего твои проблемы связанны с тем, что ты хочешь решать задачи на C# так же как если бы ты решал их на С++.
E>Я не хочу решать задачи на C#. Мне просто интересно, как это могло бы быть.
Проблема в том, что а) я лично не понял что тебе нужно, б) твои проблемы скорее всего являются следствием тараканов заведшихся от С++-мышления. Я открою тебе небольшой сикрет. Я программировал на С++ значительно дольше чем на Шарпе и в первое время, после перехода на Шарпм, тоже пытался писать как на С++. Потом понял неразумность этого и переучился на новый стиль.
E>Ok. Статью посмотрю. Подумаю. E>Сериализаций для C++ как собак нерезанных.
Ага. И все как одна неудобны В дотнете для того чтобы объект сериализовался достаточно добавить один атрибут. Разные хитрые случаи тоже разруливаются на атрибутах. В общем, другой мир.
E> Сам персонально одной такой занимаюсь -- успешно применяется в production code уже около 2-х лет и нет проблем.
Дошол до первого примера и дальше смотреть не стал. Как всегда куча сложностей на ровном месте. Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
Это в подтверждение закона Гринспуна о том, что в каждой программе на С++ есть, пусть слабенький, но интерпритатор лиспа?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали: E>>Алаверды привожу код на C++ для парсинга конфигов следующего вида: E>>
E>>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
ANS>Это в подтверждение закона Гринспуна о том, что в каждой программе на С++ есть, пусть слабенький, но интерпритатор лиспа?
Нет, на самом деле синтаксис был навеян языком Curl, а уж откуда ноги растут у Curl-а мне было не важно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А так всегда -- на словах все мудрецы и монстры. А как до реальных решений доходит, то "твои проблемы", "горы кода".
VD>Умение четко и кратко сформулировать вопрос — это действительно твои проблемы. Многие вопросы остающиеся без ответа отсаются без оного только из-за того, что они слишком запвтаны и противоричивы.
Да, такое может быть.
E>> А здесь реальная проблема, которая на C++ решилась без труда и могла бы быть решена еще проще.
VD>Опиши эту проблему. Только проблему, а не решение. И по возможности кратко и понятно.
А зачем? Ответ я от Павла Кузнецова получил. Воспринял и поставил соответствующую оценку.
E>> Здорово (еще бы, это не C# c Python-ом в разработке игр применять). Только проблема в том, что я и так привел минимальный реальный код. В дейсвительности там еще больше навороты на более высоких уровнях есть. И на C++ это все работает и является сопровождаемым.
VD>Я так понимаю, ты не первый год программируешь. Раз так то должен понимать, что ценить нужно не навороты, а стройность и простоту кода. А навороты и дерзкие хаки пусть наворачивают молодые кул-хацкеры.
Стройность и простота -- очень относительные понятия. И во многом зависят от квалификации разработчика. Для продвинутого C++ программиста использование boost::bind гораздо проще и понятнее, чем для начинающего (либо даже для C++ программиста с многолетним опытом, но не работавшем с шаблонами). Поэтому они могут дать совершенно разные оценки одному и тому же коду.
VD>Лично я когда пишу код на Шарпе не испытываю потребности в замазывании дяр в виде трехэтажных конструкциях. Рефакторю часто. Паттерны разные применяю часто. А вот хаки как-то не нужны.
Еще раз повторю -- в том конкретном случае нужно было сделать рефакторинг в базисе, на котором строилось много другого кода и который использовали другие проекты, к которым я даже отношения не имел. Если бы я нарушил совместимость на уровне исходного кода, то во всех этих проектах потребовался бы рефакторинг. И его стоимость бы оказалась гораздо выше полезности той фичи, которую я хотел добавить.
VD>>>Скорее всего твои проблемы связанны с тем, что ты хочешь решать задачи на C# так же как если бы ты решал их на С++.
E>>Я не хочу решать задачи на C#. Мне просто интересно, как это могло бы быть.
VD>Проблема в том, что б) твои проблемы скорее всего являются следствием тараканов заведшихся от С++-мышления. Я открою тебе небольшой сикрет.
Да, это я уже понял. Точно так же, как то, что C++ пытаются оценивать, используя тараканов из C#.
E>> Сам персонально одной такой занимаюсь -- успешно применяется в production code уже около 2-х лет и нет проблем.
VD>Дошол до первого примера и дальше смотреть не стал. Как всегда куча сложностей на ровном месте.
)? Ты, кстати, прочитал, для демонстрации чего был создан этот пример?
VD> Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.
Что-то я там с ходу не увидел, как с помощью BinaryFormatter можно десериализовать объекты, про которые принимающая сторона даже понятия не имеет? Или BinaryFormatter содержит в себе больше возможностей чем ASN1?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Если ты действительно хочешь что-то сравнить, то порпробуй ответить на вопрос как на С++ сделать вот это: http://rsdn.ru/article/dotnet/dnetappcfg.xml
или как сделать сериализацию на С++ такой же простой как в дотнете.
E>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
Прелесть XML не в том, что требуется меньше закорючек для описания структуры, и не в том, что его проще редактировать вручную, а в том, что он — СТАНДАРТ. С самопальными примочками типа Вашей можете разобраться только Вы. Для неё не сущесвует таких полезных и удобных технологий, как XML Schema (проверка), XSLT (преобразование), XPATH (запросы). Пользователи не смогут воспользоваться внешними высокоуровневыми редакторами этих файлов (а могли бы, если бы была XML схема).
...
Эх, велосипедный спорт пользуется огромной популярностью...
Здравствуйте, ihatelogins, Вы писали:
I>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, VladD2, Вы писали:
VD>>>Если ты действительно хочешь что-то сравнить, то порпробуй ответить на вопрос как на С++ сделать вот это: http://rsdn.ru/article/dotnet/dnetappcfg.xml
или как сделать сериализацию на С++ такой же простой как в дотнете.
E>>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
I>Прелесть XML не в том, что требуется меньше закорючек для описания структуры, и не в том, что его проще редактировать вручную, а в том, что он — СТАНДАРТ.
Стандарт чего?
Имхо, применение XML для конфигов объемом в 100-200 строк -- это из пушки по воробъям.
I> С самопальными примочками типа Вашей можете разобраться только Вы. Для неё не сущесвует таких полезных и удобных технологий, как XML Schema (проверка), XSLT (преобразование), XPATH (запросы). Пользователи не смогут воспользоваться внешними высокоуровневыми редакторами этих файлов (а могли бы, если бы была XML схема).
Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
I>Эх, велосипедный спорт пользуется огромной популярностью...
Да, и я большой его сторонник
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Посмотрел, увидел теже самые тоны кода. Подумал, не понял что должен был ответить.
Видимо не туда смотрел.
Если тебе влом вчитываться в суть статьи могу продемонстрировать упрощенный пример. Вот хэлпер-класс для упрощения сериализации в строку (в хмл-формате):
using System.Text;
using System.Xml;
using System.Xml.Serialization;
using System.IO;
static class MySerializer
{
public static string Serialize<T>(T obj)
{
XmlSerializer serializer = new XmlSerializer(typeof(T));
StringBuilder sb = new StringBuilder();
XmlWriterSettings settings = new XmlWriterSettings();
settings.Indent = true;
using (XmlWriter writer = XmlWriter.Create(sb, settings))
serializer.Serialize(writer, obj);
return sb.ToString();
}
public static T Deserialize<T>(string data)
{
XmlSerializer serializer = new XmlSerializer(typeof(T));
using (XmlReader reader = XmlTextReader.Create(new StringReader(data)))
return (T)serializer.Deserialize(reader);
}
}
Пишется один раз.
А вот как выглядит пример сериализации содержимого класса с его использованим:
using System;
using System.Xml.Serialization;
using System.Collections.Generic;
public class Test
{
public int Age; // Просто поле
// Далее все на свойствахprivate string _firstName;
public string FirstName
{
get { return _firstName; }
set { _firstName = value; }
}
private string _lastName;
public string LastName
{
get { return _lastName; }
set { _lastName = value; }
}
// Сериализуем коллекцию строк. Тоже все почит в автомате.
List<string> _addresses = new List<string>();
// Атрибут XmlArrayItem позволяет задать имя для элементов
// содержащих конкретные адреса. Если его не указать, то они
// будут иметь имя "<string>".
[XmlArrayItem("Address")]
public List<string> Addresses
{
get { return _addresses; }
}
}
class Program
{
static void Main(string[] args)
{
Test test = new Test();
test.Age = 31;
test.FirstName = "Чистяков";
test.LastName = "Влад";
test.Addresses.Add("Первый адрес");
test.Addresses.Add("Второй адрес");
// Сохраняем состояние в ХМЛ.string data = MySerializer.Serialize(test);
Console.WriteLine("Выводим сериализованные данные:");
Console.WriteLine(data);
test = null;
Console.WriteLine();
Console.WriteLine("Выводим содержимое объекта состояние "
+ "которого только что считано из строки:");
// Загружаем состояние...
test = MySerializer.Deserialize<Test>(data);
Console.WriteLine("FirstName: " + test.FirstName);
Console.WriteLine("Address 1: " + test.Addresses[0]);
}
}
Как видишь практически никаких лишних телодвижений. Код получается чистым и красивым.
E>Ну сделали вы для C# удобное решение с использованием встроенной в платформу поддержки XML сериализации и атрибутами (или как они в .Net-е называются). И что, это должно было продемонстрировать преимущества C# над C++? Ok. Если ты в этом уверен, то пусть в данной конкреной области будет так.
Не. Это демонстрция возможностей компонентного подхода. На С++ без внешнего хранилища метаинформации и без отдельного генератора код подобное сделать не удастся. Любые выкрутасы на шаблонах приведут к куче лишних движений при программировании и все равно окажутся мнее гибкими и более медленными нежели это.
Причем не нужно пытаться сомтреть на этот пример как не некую магию предоставляемую фрэймворком. XmlSerializer — это обыкновенный класс написанный на C#. Просто он задействует самые мощьные фичи дотнета вроде рефлекшона, компиляции в рантайме и динамической загрузки сборок.
E>Алаверды привожу код на C++ для парсинга конфигов следующего вида:
...
Хотел было оставить всю эту гору кода чтобы в конце поставить смайли, но уж очень огромный оверквотинг вышел бы. К тому же это все не смешно. Это грустно.
Фиг с бы с тем, что формат конфига стршен сам по себе. Но такие горы кода для столь простых задачь. Зачем?
E>Собственно код был написан наспех и с тех пор рефакторингу из-за отсутствия времени не подвергался, поэтому классы tag_on_register_t и tag_on_deregister_t остались реализованными через copy&paste (изначально планировалось, что у них будет разных набор дочерних тегов).
Прочитать эту гору кода я лично не в состоянии. (время жалко) Так что заметить подобные мелочи просто не смог. Но ты привел замечательный пример того сколько кода нужно надалбливать на С++ чтобы решить примитивные задачи.
Как я понимаю твой код не умеет впихивать информацию в объекты и читать ее из них. Попробуй ради хохмы добавить такую возможность.
E>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
Гы-гы. Это типичный пример заката слонца вручную. Если уж разрабатывался свой формат файла, да еще с зачатками языка программировани, то нужно было просто описать его грамтику в BNF/EBNF нотации и скормить любому генератору парсеров. Уверяю тебя, что даже н С++ объем кода сократился бы до пары страниц. Что до твоего формата, то извини, но это тоже велосипед. Этот формат придется изучать. А что до простоты правки... дык ХМЛ то можно править редакторами поддреживающими схемы. При этом убдет и комплит и подсветка. Твой же формат прдется править как плоский текст. Так что что удобнее еще не известно.
Если же ты попыташься внимательно прочесть статью на которую я давал ссылку, то ты увидишь, что благодоря развитой компонентной модели в дотнете можно относительно малой кровью реализовать и качественное ГУИ для редактирования данных хранящихся непосредственно в объекте. Причем код будет универсальный и ему можно будет подсовывать любой объект размеченный специальными атрибутами. В стаье этого нет, но эта схема, в Янусе, на сегодня ко всему прочему поддерживает многоязычную поддржку.
Все это конечно можно написать на С++, но это будет не один человекогод. И так почти в каждой области. Именно по этому мы (разработчики Януса) смело заявляем, что повторить Янус на С++ на объщественных началах практически невозможно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да.
> Это демонстрция возможностей компонентного подхода. На С++ без > внешнего хранилища метаинформации и без отдельного генератора код > подобное сделать не удастся. Любые выкрутасы на шаблонах приведут к > куче лишних движений при программировании и все равно окажутся мнее > гибкими и более медленными нежели это.
Был бы в С++ нормальный compile-time reflection — все стало бы еще
намного проще.
> Все это конечно можно написать на С++, но это будет не один > человекогод. И так почти в каждой области. Именно по этому мы > (разработчики Януса) смело заявляем, что повторить Янус на С++ на > объщественных началах практически невозможно.
Берем Thunderbird и пишем к ней расширение для RSDN. На С++
<...код поскипан...> VD>Как видишь практически никаких лишних телодвижений. Код получается чистым и красивым.
Влад, ты сам, вероятно, мало читаешь то, что пишут опоненты, поэтому и других в этих грехах обвиняешь?
Код получается нормальным. Почти как в boost::serialization
Если серьезно, то я признаю, что в C# удобно делать сериализацию в XML. Так ведь для языка, который появился в расцвет XML-я это и не удивительно, не так ли?
E>>Ну сделали вы для C# удобное решение с использованием встроенной в платформу поддержки XML сериализации и атрибутами (или как они в .Net-е называются). И что, это должно было продемонстрировать преимущества C# над C++? Ok. Если ты в этом уверен, то пусть в данной конкреной области будет так.
VD>Не. Это демонстрция возможностей компонентного подхода. На С++ без внешнего хранилища метаинформации и без отдельного генератора код подобное сделать не удастся. Любые выкрутасы на шаблонах приведут к куче лишних движений при программировании и все равно окажутся мнее гибкими и более медленными нежели это.
Ой-ли? Не убедительно. Лично я останусь при своем мнении.
E>>Алаверды привожу код на C++ для парсинга конфигов следующего вида: VD>...
VD>Хотел было оставить всю эту гору кода чтобы в конце поставить смайли, но уж очень огромный оверквотинг вышел бы. К тому же это все не смешно. Это грустно.
VD>Фиг с бы с тем, что формат конфига стршен сам по себе.
Это дело вкуса. По мне, так гораздо страшнее было бы работать с конфигом вида:
# Our web share
resource drbd0 {
net {
sync-group=0
}
on node1 {
device=/dev/nb0
disk=/dev/sda1
}
on node2 {
device=/dev/nb0
disk=/dev/sda1
}
}
# Our MySQL share
resource drbd1 {
net {
sync-group=1
}
on node1 {
device=/dev/nb1
disk=/dev/sda2
}
on node2 {
device=/dev/nb1
disk=/dev/sda2
}
}
Неужели бы он выиграл бы от XML-формата?
VD>Но такие горы кода для столь простых задачь. Зачем?
Ну я в свое время насмотрелся (на Java и C++), как хранят конфиги в XML а затем извлекают из них значения. Если используется DOM-модель, то после нескольких строчек обращения к парсингу шла масса строк с поиском и извлечением значений из DOM-элементов. А если использовалась SAX-модель, то код все равно получался таким же, как у меня, только нужно было еще корректно из строк в int-ы преобразовывать.
VD>Как я понимаю твой код не умеет впихивать информацию в объекты и читать ее из них. Попробуй ради хохмы добавить такую возможность.
Вот именно -- ради хохмы. А в реальности мне такая фишка пока не потребовалась.
E>>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
VD>Гы-гы. Это типичный пример заката слонца вручную. Если уж разрабатывался свой формат файла, да еще с зачатками языка программировани, то нужно было просто описать его грамтику в BNF/EBNF нотации и скормить любому генератору парсеров.
Там нет зачатков языка программирования. Просто похожие конструкции.
Кроме того, у граматик и парсеров есть большие проблемы с раширяемостью. Вот потребуется в тег {pixmap} еще один подтег добавить, и придется граматику править. И еще не понятно, насколько проще это окажется, особенно если граматика получится сильно контекстно-чувствительная.
VD>Если же ты попыташься внимательно прочесть статью на которую я давал ссылку, то ты увидишь, что благодоря развитой компонентной модели в дотнете можно относительно малой кровью реализовать и качественное ГУИ для редактирования данных хранящихся непосредственно в объекте. Причем код будет универсальный и ему можно будет подсовывать любой объект размеченный специальными атрибутами. В стаье этого нет, но эта схема, в Янусе, на сегодня ко всему прочему поддерживает многоязычную поддржку.
Влад, я прочел статью.
Но оценить всю видимую тобой прелесть я не могу. Вероятно в силу того, что занимаюсь другими вещами.
VD>Именно по этому мы (разработчики Януса) смело заявляем, что повторить Янус на С++ на объщественных началах практически невозможно.
Имхо, тебе пора перестать использовать в качестве доказательства крутости C# тот факт, что на C++ нет аналога Януса. На C# нет аналога GNOME или KDE, почему бы не сказать, что на C# эти проекты нереализуемы?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Шутку понял. Смешно.
>> Это демонстрция возможностей компонентного подхода. На С++ без >> внешнего хранилища метаинформации и без отдельного генератора код >> подобное сделать не удастся. Любые выкрутасы на шаблонах приведут к >> куче лишних движений при программировании и все равно окажутся мнее >> гибкими и более медленными нежели это.
C>http://boost.org/libs/serialization/doc/index.html , в частности C>http://boost.org/libs/serialization/doc/tutorial.html#simplecase
Да, хорошая демонстрация очередного заката солнца вручную. Ради хохмы приведу аналог вот этого:
class gps_position
{
private:
friend class boost::serialization::access;
// When the class Archive corresponds to an output archive, the
// & operator is defined similar to <<. Likewise, when the class Archive
// is a type of input archive the & operator is defined similar to >>.template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & degrees;
ar & minutes;
ar & seconds;
}
int degrees;
int minutes;
float seconds;
public:
gps_position(){};
gps_position(int d, int m, float s) :
degrees(d), minutes(m), seconds(s)
{}
};
на Шарпе:
[Serializable]
class gps_position
{
private int degrees;
private int minutes;
private float seconds;
};
C>Был бы в С++ нормальный compile-time reflection — все стало бы еще C>намного проще.
Был бы у бабушки хрен...
>> Все это конечно можно написать на С++, но это будет не один >> человекогод. И так почти в каждой области. Именно по этому мы >> (разработчики Януса) смело заявляем, что повторить Янус на С++ на >> объщественных началах практически невозможно.
C>Берем Thunderbird и пишем к ней расширение для RSDN. На С++
Ага... языком.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
AVK>Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
А уж IDE-то здесь к чему?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
AVK>>Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
E>А уж IDE-то здесь к чему?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
AVK>>>Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
E>>А уж IDE-то здесь к чему?
AVK>Попробуй — узнаешь
Хотя бы для какого языка программирования эта IDE должна быть?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, ihatelogins, Вы писали:
I>>Здравствуйте, eao197, Вы писали:
E>>>Здравствуйте, VladD2, Вы писали:
VD>>>>Если ты действительно хочешь что-то сравнить, то порпробуй ответить на вопрос как на С++ сделать вот это: http://rsdn.ru/article/dotnet/dnetappcfg.xml
или как сделать сериализацию на С++ такой же простой как в дотнете.
E>>>Имхо, на C++ без существенных издержек и накладных расходов был реализован разбор сложных конфигурационных файлов. Причем не XML формата, а более удобного для редактирования вручную.
I>>Прелесть XML не в том, что требуется меньше закорючек для описания структуры, и не в том, что его проще редактировать вручную, а в том, что он — СТАНДАРТ.
E>Стандарт чего?
Стандарт описания структурированной информации.
E>Имхо, применение XML для конфигов объемом в 100-200 строк -- это из пушки по воробъям.
Использование XML оправдано даже для config-файлов в 1 строку. Размер файла значения не имеет.
I>> С самопальными примочками типа Вашей можете разобраться только Вы. Для неё не сущесвует таких полезных и удобных технологий, как XML Schema (проверка), XSLT (преобразование), XPATH (запросы). Пользователи не смогут воспользоваться внешними высокоуровневыми редакторами этих файлов (а могли бы, если бы была XML схема).
E>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
XML Schema — для проверки корректности структуры.
XSLT в HTML может быть удобен для визуального отображения config-файла.
XPath можеь быть использован для быстрого получения конкретных настроек в config-файле в сторонних приложениях.
Как видите, всё логично, и, САМОЕ ГЛАВНОЕ, стандартизованно. Проще разрабатывать СЕЙЧАС, легче (дешевле, быстрее) поддерживать в будущем.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>> E>>Хотя бы для какого языка программирования эта IDE должна быть?
AVK>Для любого. Подойдет VS2003-2005, IDEA.
С такими выражениями стоило бы быть поосторожнее. VS2003 -- это C++, C#, VB (или что-то еще)? IDEA -- это Java.
Но под понятие "любой" подойдут так же языки Perl, Python, Ruby, Smalltalk, Oberon, Ada, Modula-2, Eiffel, Prolog, Lisp (все, что сразу удалось вспомнить) и еще куча языков.
Так что-же я должен увидеть?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ihatelogins, Вы писали:
I>>>Прелесть XML не в том, что требуется меньше закорючек для описания структуры, и не в том, что его проще редактировать вручную, а в том, что он — СТАНДАРТ.
E>>Стандарт чего?
I>Стандарт описания структурированной информации.
Тогда бы я сказал, что это один из стандартов описания структурированной информации. Со своими недостатками.
I>>> С самопальными примочками типа Вашей можете разобраться только Вы. Для неё не сущесвует таких полезных и удобных технологий, как XML Schema (проверка), XSLT (преобразование), XPATH (запросы). Пользователи не смогут воспользоваться внешними высокоуровневыми редакторами этих файлов (а могли бы, если бы была XML схема).
E>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
I>XML Schema — для проверки корректности структуры.
I>XSLT в HTML может быть удобен для визуального отображения config-файла.
I>XPath можеь быть использован для быстрого получения конкретных настроек в config-файле в сторонних приложениях.
I>Как видите, всё логично, и, САМОЕ ГЛАВНОЕ, стандартизованно. Проще разрабатывать СЕЙЧАС, легче (дешевле, быстрее) поддерживать в будущем.
Из всего перечисленного тобой самое важное, имхо, это возможность чтения конфигов сторонними приложениями. Но вот есть два вопроса:
— что, если это не нужно? Конфиги только для C++. В таких случаях проще таскать за собой самописную библиотеку разбора конфигов, чем какой-нибудь Xerces или libxml2;
— что, если в других языках (скажем Python или Ruby) принято использовать другие форматы конфигов, скажем YAML?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>С такими выражениями стоило бы быть поосторожнее. VS2003 -- это C++, C#, VB (или что-то еще)? IDEA -- это Java.
Тем не менее и та и другая IDE позволяют редактировать XML.
E>Но под понятие "любой" подойдут так же языки Perl, Python, Ruby, Smalltalk, Oberon, Ada, Modula-2, Eiffel, Prolog, Lisp (все, что сразу удалось вспомнить) и еще куча языков.
Возможно и в их средах встречается приличный редактор XML.
E>Так что-же я должен увидеть?
VladD2 wrote:
> Да, хорошая демонстрация очередного заката солнца вручную. Ради хохмы > приведу аналог вот этого: > >class gps_position >{ >private: > friend class boost::serialization::access; > // When the class Archive corresponds to an output archive, the > // & operator is defined similar to <<. Likewise, when the class Archive > // is a type of input archive the & operator is defined similar to >>. > template<class Archive> > void serialize(Archive & ar, const unsigned int version) > { > ar & degrees; > ar & minutes; > ar & seconds; > } > int degrees; > int minutes; > float seconds; >public: > gps_position(){}; > gps_position(int d, int m, float s) : > degrees(d), minutes(m), seconds(s) > {} >}; > > > на Шарпе: > >[Serializable] >class gps_position >{ > private int degrees; > private int minutes; > private float seconds; >}; > >
Не забудь еще конструторы.
Между этими примерами вся разница в методе serialize, на самом деле. При
наличии compile-time reflection он делается автоматом.
> C>Был бы в С++ нормальный compile-time reflection — все стало бы еще > C>намного проще. > Был бы у бабушки хрен...
Будет
>>> Все это конечно можно написать на С++, но это будет не один >>> человекогод. И так почти в каждой области. Именно по этому мы >>> (разработчики Януса) смело заявляем, что повторить Янус на С++ на >>> объщественных началах практически невозможно. > C>Берем Thunderbird и пишем к ней расширение для RSDN. На С++ > Ага... языком.
Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило
абсолютно. Понятно, что если переизобретать ньюсридер, то потребуется
куча кода. Для того же Thunderbird'а я оцениваю требуемый объем кода
расширений примерно в 200Кбайт на С++ и JavaScript.
Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и
читаю про использование custom-форм в нем, так что в будущем (в конце
лета во время отпуска) возможно будет Janus for Outlook
Здравствуйте, eao197, Вы писали:
AVK>>Редактор XML.
E>Блин, а я уж думал, что должен увидеть прозрачное отображение структур данных на XML в любом языке программирования
Ты еще помнишь, что я отвечал на твой вопрос о нужности XML Schema для конфигурационных файлов?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Редактор XML.
E>>Блин, а я уж думал, что должен увидеть прозрачное отображение структур данных на XML в любом языке программирования
AVK>Ты еще помнишь, что я отвечал на твой вопрос о нужности XML Schema для конфигурационных файлов?
Уже нет . Вот если бы ты сразу об этом сказал, тогда помнил бы. А так фантазия разыгралась, уже не знал о чем и думать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А зачем? Ответ я от Павла Кузнецова получил. Воспринял и поставил соответствующую оценку.
Паша в шарпе сам не на много больше твоего знает. К тому же он ярый приверженец С++ и к шарпу пока что относится предвзято.
E>>> Здорово (еще бы, это не C# c Python-ом в разработке игр применять). Только проблема в том, что я и так привел минимальный реальный код. В дейсвительности там еще больше навороты на более высоких уровнях есть. И на C++ это все работает и является сопровождаемым.
E>Стройность и простота -- очень относительные понятия.
Да нет. Они очень даже конкретны. Просто иногда люди привыкают к непросым и громоздким решениями считая их в норме вещей.
E> И во многом зависят от квалификации разработчика. Для продвинутого C++ программиста использование boost::bind гораздо проще и понятнее, чем для начинающего (либо даже для C++ программиста с многолетним опытом, но не работавшем с шаблонами). Поэтому они могут дать совершенно разные оценки одному и тому же коду.
Вот, вот. boost::bind — это заплатка языка. В том же шарпе ты просто имешь превокласную сущность — делегат. Ее одинаково хорошо понимаю и используют и продвинутый программист, и неофит.
E>Еще раз повторю -- в том конкретном случае нужно было сделать рефакторинг в базисе, на котором строилось много другого кода и который использовали другие проекты, к которым я даже отношения не имел.
Без разницы. При наличии соотвествующих средств это не является проблемой. Проблемой это является только для плюсов сложность синтаксиса которого отталкивает разработчиков утилит рефакторинга.
E> Если бы я нарушил совместимость на уровне исходного кода, то во всех этих проектах потребовался бы рефакторинг.
Опять же никаких проблем. Автоматизированный рефакторинг легко править все связи. Даже вне проекта.
E> И его стоимость бы оказалась гораздо выше полезности той фичи, которую я хотел добавить.
Исключительно для С++. Буквально вчера я отрефакторил кучу кода где-то за час. Все скомпилировалось и заработало без ошибок с первого раза.
E>Да, это я уже понял. Точно так же, как то, что C++ пытаются оценивать, используя тараканов из C#.
Ты забывашь, что для многих (в том числе и для меня) Шарп был даже не вторы языком. С++ я знаю не намного хуже шарпа и использовал его очень долго. Так что я более чем знаком с обоими языками и могу смело сказать, что после изучения других языков начинашь лучше писть и на том же С++. Это я просек еще когда два года провозился с Дельфи.
E>А можно подробнее об этой куче (можно вот в эту ветку: [ANN] ObjESSty — еще один проект сериализации
Откровенна говоря с некоторых пор проблемы трехколенных вывертов на С++ для решения примитивных задач меня перестали интересовать. Эта как раз такая. Тратить время не нее мен не хочется.
E> Ты, кстати, прочитал, для демонстрации чего был создан этот пример?
Дошел до фразы "как средства сериализации в организации межпроцессовых взаимодействий" и потирял всякий интерес читать дальше, так как это поять же тараканы С++ на которые мне смотреть не интересно. Мне проще писать на языках не имеющих таких проблем, или на худой конце воспользоваться КОМ-ом или Корбой.
VD>> Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.
E>Что-то я там с ходу не увидел, как с помощью BinaryFormatter можно десериализовать объекты, про которые принимающая сторона даже понятия не имеет? Или BinaryFormatter содержит в себе больше возможностей чем ASN1?
Незнаю как такое можно не заметить...
BinaryFormatter formatter = new BinaryFormatter();
object obj = formatter.Deserialize(mySream);
Вопрос только что дальше делать с этим самым obj.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Уже нет . Вот если бы ты сразу об этом сказал, тогда помнил бы.
AVK>А я сразу и сказал. Я, в отличие от некоторых, цитирую только по делу.
Поскольку под некоторыми понимаюсь я, то для расстановки точек над i я хотел бы привести исходную цитату:
E>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
Так вот в русле предыдущего обсуждения, когда Влад дал ссылку на статью с описанием автоматической сериализации C# в XML-конфигурационные файлы, ничто не мешало мне проинтерпритировать твою фразу как намек на то, что любая современная IDE позволяет делать такое прозрачное отображение структур на XML с помощью XML Schema.
А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат), чем таскать за собой монстрообразные XML-парсеры и использовать их в угоду тому, что XML считается стандартом. ASN1 так же является стандартом. И что из того?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Вот, вот. boost::bind — это заплатка языка. В том же шарпе ты просто имешь превокласную сущность — делегат. Ее одинаково хорошо понимаю и используют и продвинутый программист, и неофит.
Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.
E>>Еще раз повторю -- в том конкретном случае нужно было сделать рефакторинг в базисе, на котором строилось много другого кода и E>> И его стоимость бы оказалась гораздо выше полезности той фичи, которую я хотел добавить.
VD>Исключительно для С++. Буквально вчера я отрефакторил кучу кода где-то за час. Все скомпилировалось и заработало без ошибок с первого раза.
Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.
VD>>> Почитай про BinaryFormatter и про XmlSerializer (в приведенной выше статье). Думаю разницу ты ощутишь сразу.
E>>Что-то я там с ходу не увидел, как с помощью BinaryFormatter можно десериализовать объекты, про которые принимающая сторона даже понятия не имеет? Или BinaryFormatter содержит в себе больше возможностей чем ASN1?
VD>Незнаю как такое можно не заметить... VD>
VD>BinaryFormatter formatter = new BinaryFormatter();
VD>object obj = formatter.Deserialize(mySream);
VD>
VD>Вопрос только что дальше делать с этим самым obj.
Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AVK>>А я сразу и сказал. Я, в отличие от некоторых, цитирую только по делу.
E>Поскольку под некоторыми понимаюсь я
Не угадал.
E>Так вот в русле предыдущего обсуждения, когда Влад дал ссылку на статью с описанием автоматической сериализации C# в XML-конфигурационные файлы, ничто не мешало мне проинтерпритировать твою фразу как намек на то, что любая современная IDE позволяет делать такое прозрачное отображение структур на XML с помощью XML Schema.
Ну вот не надо читать между строк и все будет впорядке.
E>А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат),
В каких?
E> чем таскать за собой монстрообразные XML-парсеры
Парсер XML входит в состав фреймворка, специально таскать его не нужно. Кроме того, парсеры xml для конфигурационных файлов можно уложить в 5-10Кб кода, прецеденты есть.
Здравствуйте, Cyberax, Вы писали:
C>Не забудь еще конструторы.
Не забыл. Они не нужны.
C>Между этими примерами вся разница в методе serialize, на самом деле. При C>наличии compile-time reflection он делается автоматом.
Ага. Все разнца в том, что нужно писать код. Причем чем сложнее случай, тем больше будет кода. В дотнете же в 99% случаев код писать попросту не прийдется.
C>Будет
Хрен или дедушка?
Ну, да когда будет тогда и поговорим. Пока что новый стандарт ожидаетя не ранее 2008 года, до тех пор еще много воды утечет.
C>Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило C>абсолютно.
Самом собой. Найди лучше.
C> Понятно, что если переизобретать ньюсридер, то потребуется C>куча кода. Для того же Thunderbird'а я оцениваю требуемый объем кода C>расширений примерно в 200Кбайт на С++ и JavaScript.
Безумству храбрых поем мы песню. (с)
C>Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и C>читаю про использование custom-форм в нем, так что в будущем (в конце C>лета во время отпуска) возможно будет Janus for Outlook
Опоздал. У нас уже 100 лет как есть NNTP. Просто подпишись на него любой читалкой новостей и мучаться не прийдется.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Если серьезно, то я признаю, что в C# удобно делать сериализацию в XML.
Дело в том, что в нем оОоочень многое делать оОооочень удобно.
E> Так ведь для языка, который появился в расцвет XML-я это и не удивительно, не так ли?
Открою тебе сикрет. Шарп неимеет ни одной запятой рассчитанной на ХМЛ. Это такой же универсальный язык как и С++. Вся поддержка ХМЛ в дотнете реализо на Шарпе. Более того этот код досупен в Роторе (ну, или декомпилятором).
VD>>Не. Это демонстрция возможностей компонентного подхода. На С++ без внешнего хранилища метаинформации и без отдельного генератора код подобное сделать не удастся. Любые выкрутасы на шаблонах приведут к куче лишних движений при программировании и все равно окажутся мнее гибкими и более медленными нежели это.
E>Ой-ли?
Еще как ой.
E> Не убедительно. Лично я останусь при своем мнении.
Ну, тут ничего не поделашь. Чтобы понять как все устроено прийдетс глубоко углубиться в изучение дотнета и поторатить на это год-другой времени. Так вот на польцах тут ничего не объяснить.
Я же просто хотел объснить тебе, что примеры того как на С++ можно замазать проблему этого языка ничто по сравнению с птимерами использования возможностей дотнета. В купе получается что писать программы на Шарпе под дотнетом значительно проще и результат получается куда надежнее.
E>Это дело вкуса.
Это не дело вкуса. Это дело стандартизации и дизайна.
E> По мне, так гораздо страшнее было бы работать с конфигом вида:...
Дык не создавай избыточных конструкций. А работать один фиг будет проще, так как есть такие мощьные вещи как: DOM, XSLT, XPath, XQuery. Боюсь ты даже представить себе не можешь как они могут облегчить жизнь.
E>Неужели это выглядит более читабельными и понятным?
Примерно как твой. Все равно сахивает на Лисп.
E>...Неужели бы он выиграл бы от XML-формата?
Не особо хуже. За-то изучать его было бы проще.
E>Ну я в свое время насмотрелся (на Java и C++), как хранят конфиги в XML а затем извлекают из них значения. Если используется DOM-модель, то после нескольких строчек обращения к парсингу шла масса строк с поиском и извлечением значений из DOM-элементов.
Видимо те кто это делали не знали про XPath.
E> А если использовалась SAX-модель, то код все равно получался таким же, как у меня, только нужно было еще корректно из строк в int-ы преобразовывать.
Как у тебя не получится, так как ты полностю парсер вручную написал. Я кажется тебе уже говорил, что для таких вещей нужно построители парсеров использовать.
VD>>Как я понимаю твой код не умеет впихивать информацию в объекты и читать ее из них. Попробуй ради хохмы добавить такую возможность.
E>Вот именно -- ради хохмы. А в реальности мне такая фишка пока не потребовалась.
Ага. "А нам и не надо". Не думаю, что кто-то по своей воле отказался бы просто работать с объектами и сохранять или загружать их состояние с помощью одной строчки кода. Ну, разве что "на зло". Типа выбью себе глаз, чтобы у тещи зять кривой был.
E>Там нет зачатков языка программирования. Просто похожие конструкции. E>Кроме того, у граматик и парсеров есть большие проблемы с раширяемостью.
Не замечал.
E> Вот потребуется в тег {pixmap} еще один подтег добавить, и придется граматику править.
Да, уж проблема страшная. То ли дело отыскать в горе код нужную функцию и приписать еще горку кода.
E> И еще не понятно, насколько проще это окажется, особенно если граматика получится сильно контекстно-чувствительная.
У тебя примитивнейшая граматика описываемая в LL(1). В любом случае ручной парсинг более менее сложного формата всегда сложнее создания аналога вручную.
E>Но оценить всю видимую тобой прелесть я не могу. Вероятно в силу того, что занимаюсь другими вещами.
Возможно. Но попробовать стоит. Иначе зачем вообще пытаться что-то сравнивать?
E>Имхо, тебе пора перестать использовать в качестве доказательства крутости C# тот факт, что на C++ нет аналога Януса.
Это не доказательство. Но это очень показательный факт, так как о том что это как пару байт переслать здесь рассужать очень многие любят.
E> На C# нет аналога GNOME или KDE,
На C# есть винформс который полносью перекрыват возможности их как библиотек ГУИ. Если ты об оболчке, то в Лонгхорне большая ее часть писана на том же шарпе. Ну, и к шарпу есть GTK .
E>почему бы не сказать, что на C# эти проекты нереализуемы?
Ты где-нибудь слышал о том, что их нужно переписывать на Шарпе и тем более что это как пару байт переслать? То-то же, а про янус это уже стало местным приколов. Раз в неделю-другую появлется очередной орел и предлагает переписать Янус на шарпе. Все как один случае кончаются на пустопорожних обещаниях. Вот тут рядом еще одно обещание дали.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот не надо читать между строк и все будет впорядке.
Ok. Наследие советского прошлого
E>>А оказалось, что IDE оказывает помощь в редактировании XML файлов, если для них есть XML Scheme. Но это совсем другая область, ведь XML-конфигурационный файл нужно еще разобрать в программе и извлечь из него значения. И в некоторых случаях проще иметь собственную библиотеку парсинга конфигов (и их формат),
AVK>В каких?
Когда решение на разные платформы нужно перетаскивать и вместе с исходниками заказчику передавать. А то бывает, отгребаешь массу проблем, когда на платформе у заказчика libxml или openssl не той версии стоит, а нужную версию ставить отказываются.
E>> чем таскать за собой монстрообразные XML-парсеры
AVK>Парсер XML входит в состав фреймворка, специально таскать его не нужно. Кроме того, парсеры xml для конфигурационных файлов можно уложить в 5-10Кб кода, прецеденты есть.
Да, но если речь идет об C++, то такие парсеры не чуть не лучше собственных поделок.
Кроме того, если речь идет именно о конфигах, а не об интероперабельности на уровне документов, то XML здесь, имхо, не стандарт. Особенно на Unix-ах.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Если серьезно, то я признаю, что в C# удобно делать сериализацию в XML.
VD>Дело в том, что в нем оОоочень многое делать оОооочень удобно.
В частности, создавать в generic-ах объекты заданных в параметре шаблона типов с передачей аргументов в конструкторе
E>> По мне, так гораздо страшнее было бы работать с конфигом вида:...
VD>Дык не создавай избыточных конструкций. А работать один фиг будет проще, так как есть такие мощьные вещи как: DOM, XSLT, XPath, XQuery. Боюсь ты даже представить себе не можешь как они могут облегчить жизнь.
Правда? Столько жутких слов для обработки какого-то конфигурационного файла.
E>>...Неужели бы он выиграл бы от XML-формата?
VD>Не особо хуже. За-то изучать его было бы проще.
Да уж. Зачем же тогда различные DSL придумывают? Не для того ли, чтобы семантику предметной области можно было выражать без излишних XML-синтаксических заморочек?
E>>Ну я в свое время насмотрелся (на Java и C++), как хранят конфиги в XML а затем извлекают из них значения. Если используется DOM-модель, то после нескольких строчек обращения к парсингу шла масса строк с поиском и извлечением значений из DOM-элементов.
VD>Видимо те кто это делали не знали про XPath.
Я думаю, что тогда его еще не было (2001 год). А затем унаследованный код нужно было рефакторить на перехода на XPath? А затем на что-то после XPath?
E>> А если использовалась SAX-модель, то код все равно получался таким же, как у меня, только нужно было еще корректно из строк в int-ы преобразовывать.
VD>Как у тебя не получится, так как ты полностю парсер вручную написал. Я кажется тебе уже говорил, что для таких вещей нужно построители парсеров использовать.
И где ты в моем коде увидел вручную написанный парсер? Ткни носом, плз. А то ведь библиотека cls_2, которая парсингом занимается, для программиста выглядит такой же готовой штукой, как Xerces или libxml2.
VD>Ага. "А нам и не надо". Не думаю, что кто-то по своей воле отказался бы просто работать с объектами и сохранять или загружать их состояние с помощью одной строчки кода. Ну, разве что "на зло". Типа выбью себе глаз, чтобы у тещи зять кривой был.
Ты, кстати, не заметил, что само описание прикладных структур было отделено от классов, которые эти структуры из конфига поднимают?
А ведь это не с проста. Это дает возможность сериализовать прикладные структуры совершенно разными способами, не трогая их описания совершенно.
E>>Там нет зачатков языка программирования. Просто похожие конструкции. E>>Кроме того, у граматик и парсеров есть большие проблемы с раширяемостью.
VD>Не замечал.
А я замечал в yacc, когда одно и тоже ключевое слово в разных контекстах для разных понятий использовать нужно было.
E>> Вот потребуется в тег {pixmap} еще один подтег добавить, и придется граматику править.
VD>Да, уж проблема страшная. То ли дело отыскать в горе код нужную функцию и приписать еще горку кода.
E>> На C# нет аналога GNOME или KDE,
VD>На C# есть винформс который полносью перекрыват возможности их как библиотек ГУИ. Если ты об оболчке, то в Лонгхорне большая ее часть писана на том же шарпе. Ну, и к шарпу есть GTK .
Ба, да мы, вероятно, об KDE и понятия не имеем? Может выберешь время, зайдешь на http://www.kde.org как нибудь?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Правда? Я вот надеюсь, что boost::bind станет частью языка, тогда это будет такой же стандартный механизм, как делегаты, а не заплатка.
Не беспокойся — не станет. Я тут прочел твою ссылку на очередное откровение Страуструпа и понял, что основные вещи он уеж решил (ну, классы есть же?) а мелочи вроде делегатов или процедурных типов он делать не желает. Это мелкие частности. Ну, что поделать если человек настолко образован, что ему плевать на целую парадигму функционального программирования? В общем, орлам вроде Степанова и дальше прийдется извращаться, чтобы написать примитивную фичу вроде boost::bind. Причем компилироваться это будет часами. В общем, маразм крепчал...
E>Ключевое слово -- "я". Если бы я мог все сам отрефакторить, я бы отрефакторил. А если я говорю своим коллегам: "Друзья мои, я сделал маленькое дополнение к библиотечке, из-за которого вы должны отрефакторить свой код", то я расчитываю услышать массу слов в свой адрес.
А ты рафактри сам. Нечего сваливать на молодежь.
E>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне?
Именно по этому я тебе и говорил, что тебе прийдется потратить год, чтобы изучить дотнет в той мере, чтобы не удивляться таким примитивным вещам.
Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>В частности, создавать в generic-ах объекты заданных в параметре шаблона типов с передачей аргументов в конструкторе
Когда все вокруг объект и ты о всем можешь прочепсть описание, невозможного просто нет.
E>Правда? Столько жутких слов для обработки какого-то конфигурационного файла.
Это унивесальные заклинания.
E>Да уж. Зачем же тогда различные DSL придумывают?
Не боись. Их все чаще на ХМЛ лабают.
E> Не для того ли, чтобы семантику предметной области можно было выражать без излишних XML-синтаксических заморочек?
А ты точно уверен, что не путаешь синтаксис с семантикой?
E>Я думаю, что тогда его еще не было (2001 год).
Вроде был.
E>И где ты в моем коде увидел вручную написанный парсер? Ткни носом, плз. А то ведь библиотека cls_2, которая парсингом занимается, для программиста выглядит такой же готовой штукой, как Xerces или libxml2.
Ну, не знаю. Выглядит это жутко. Бизон был бы куда проще.
E>Ты, кстати, не заметил, что само описание прикладных структур было отделено от классов, которые эти структуры из конфига поднимают? E>А ведь это не с проста. Это дает возможность сериализовать прикладные структуры совершенно разными способами, не трогая их описания совершенно.
Дык зак этим морем кода заметить было что либо не просто.
E>А я замечал в yacc, когда одно и тоже ключевое слово в разных контекстах для разных понятий использовать нужно было.
Ну, я как-то парсер C# создал который такой финей страдет постоянно. Прадва не на яке, ана КокоР, но это не так важно.
E>Ба, да мы, вероятно, об KDE и понятия не имеем? Может выберешь время, зайдешь на http://www.kde.org как нибудь?
И что виликого мы там узреем?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> C>Не забудь еще конструторы. > Не забыл. Они не нужны.
Тогда бы хоть property поставил. Как ты эти поля читать/писать
собираешься, если они приватные.
В С++ном варианте конструкторы, кстати, тоже можно убрать — для
сериализации они не важны.
> C>Между этими примерами вся разница в методе serialize, на самом деле. > При > C>наличии compile-time reflection он делается автоматом. > Ага. Все разнца в том, что нужно писать код. Причем чем сложнее > случай, тем больше будет кода. В дотнете же в 99% случаев код писать > попросту не прийдется.
Макрос ORDERED_OBJECT развертывается в реализацию лексиографического
оператора сравнения (попробуй то же самое сделать в С#) и прочие
производные операторы (>,==, !=, <=, >=), а SERIALIZABLE_OBJECT — в
сериализатор.
Если бы можно было перечислить члены класса, то даже этого бы не
понадобилось.
> C>Будет > Хрен или дедушка?
И то, и другое Вот сейчас с GCCXML играюсь, возможно получится
сделать что-то типа атрибутов для С++.
> Ну, да когда будет тогда и поговорим. Пока что новый стандарт ожидаетя > не ранее 2008 года, до тех пор еще много воды утечет.
Как раз к выходу Longhorn, где будет Net 2.0 и всеобщее счастье...
> C>Я, кстати, поставил себе посмотреть Янус еще раз — не впечатлило > C>абсолютно. > Самом собой. Найди лучше.
Сейчас NNTP пользуюсь, оно лучше.
> C>Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и > C>читаю про использование custom-форм в нем, так что в будущем (в конце > C>лета во время отпуска) возможно будет Janus for Outlook > Опоздал. У нас уже 100 лет как есть NNTP. Просто подпишись на него > любой читалкой новостей и мучаться не прийдется.
Здравствуйте, eao197, Вы писали:
AVK>>В каких?
E>Когда решение на разные платформы нужно перетаскивать и вместе с исходниками заказчику передавать.
С парсером XML на разных платформах вроде как проблем нет. Да и несильно сложно написать свой вариант парсера. Наконец есть готовые, к примеру TinyXML — бесплатный, маленький, переносимый.
E>Да, но если речь идет об C++, то такие парсеры не чуть не лучше собственных поделок.
Лучше, поскольку как минимум уже есть и имеют историю использования не в одном проекте.
E>Кроме того, если речь идет именно о конфигах, а не об интероперабельности на уровне документов, то XML здесь, имхо, не стандарт. Особенно на Unix-ах.
XML это стандарт вне зависимости от его применения.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>В частности, создавать в generic-ах объекты заданных в параметре шаблона типов с передачей аргументов в конструкторе
VD>Когда все вокруг объект и ты о всем можешь прочепсть описание, невозможного просто нет.
А, идея стала понятна! Волшебное слово "reflection".
Смущает только то, что в спорах про динамическую типизацию ты был ярым сторонником статической типизации. А в данном случае, когда вызов конструктора объекта при компиляции проверить нельзя, тебя динамизм устраивает
E>> Не для того ли, чтобы семантику предметной области можно было выражать без излишних XML-синтаксических заморочек?
VD>А ты точно уверен, что не путаешь синтаксис с семантикой?
Обычно нет, но когда семантика выражения скрывается за горами синтаксического мусора, то начинаю путать
E>>Я думаю, что тогда его еще не было (2001 год).
VD>Вроде был.
Видимо в зачаточном состоянии.
E>>И где ты в моем коде увидел вручную написанный парсер? Ткни носом, плз. А то ведь библиотека cls_2, которая парсингом занимается, для программиста выглядит такой же готовой штукой, как Xerces или libxml2.
VD>Ну, не знаю. Выглядит это жутко. Бизон был бы куда проще.
Не верю, сам yacc-ом пользовался, так там, чтобы сохранить где-то значения по ходу разбора, то приходилось много чего делать.
E>>Ба, да мы, вероятно, об KDE и понятия не имеем? Может выберешь время, зайдешь на http://www.kde.org как нибудь?
VD>И что виликого мы там узреем?
Ну хотя бы то, что KDE -- это не GUI библиотека
А функциональность и сложность входящих в KDE продуктов на порядки превосходит Янус (ничего личного). Более того, компонент khtml из KDE был использован Apple для создания своего браузера Safari.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да и несильно сложно написать свой вариант парсера.
У меня уже есть готовый, для формата, который, имхо, более подходит для конфигурационных файлов.
AVK> Наконец есть готовые, к примеру TinyXML — бесплатный, маленький, переносимый.
Такая же хрень, как и мой велосипед. Хрень, потому, что берет из XML только синтаксис. Ничего больше с ним не сделаешь.
Если же больше ничего и не нужно, то я не вижу смысла в XML, кроме как "чтобы было как у всех".
AVK>XML это стандарт вне зависимости от его применения.
Здравствуйте, eao197, Вы писали:
AVK>>Да и несильно сложно написать свой вариант парсера.
E>У меня уже есть готовый, для формата, который, имхо, более подходит для конфигурационных файлов.
Ну так и xml парсеры есть. С куда более удобными редакторами этих файлов.
E>Такая же хрень, как и мой велосипед. Хрень, потому, что берет из XML только синтаксис. Ничего больше с ним не сделаешь.
Нет. Потому что это валидный XML, следовательно его могут парсить другие парсеры, редактировать другие редакторы, а пользователям не нужно будет разбираться с неизвестным синтаксисом.
E>Про убежденность в том, что XML должен применяться везде, где только можно,
Это ты про кого?
E>и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.
Здесь кто то предлагает насаждатьт XML повсеместно? Или речь все же о хранении в XML конфигурационной информации?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Да и несильно сложно написать свой вариант парсера.
E>>У меня уже есть готовый, для формата, который, имхо, более подходит для конфигурационных файлов.
AVK>Ну так и xml парсеры есть. С куда более удобными редакторами этих файлов. AVK>Нет. Потому что это валидный XML, следовательно его могут парсить другие парсеры, редактировать другие редакторы, а пользователям не нужно будет разбираться с неизвестным синтаксисом.
Ну насчет синтаксиса, здесь можно поспорить. Например, в Curl очень простой синтаксис, чем-то сишный напоминает, например, зарезервированные символы с помощь простых escape-последовательностей записываются: \\, \{, \}, \|, \". Не в пример XML-ным &, <, >.
Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал.
Ну и насчет редакторов можно поспорить -- хорошо, когда они есть. А если конфиг нужно поправить через SSH-подключение на удаленной машине, то в vi Curl-подобный конфиг поправить или написать труда не составляет совершенно.
E>>Про убежденность в том, что XML должен применяться везде, где только можно,
AVK>Это ты про кого?
Да так, сложилось у меня такое мнение по ходу обсуждения.
E>>и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.
AVK>Здесь кто то предлагает насаждатьт XML повсеместно? Или речь все же о хранении в XML конфигурационной информации?
Имхо, когда XML применяют для создания конфигурационных файлов объемом в 100-200 строк, это уже и есть насаждение.
Хотя, все зависит от характера конфигурационной информации. А так же от предпочтений разработчиков.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Нет. Потому что это валидный XML, следовательно его могут парсить другие парсеры, редактировать другие редакторы, а пользователям не нужно будет разбираться с неизвестным синтаксисом.
E>Ну насчет синтаксиса, здесь можно поспорить. Например, в Curl очень простой синтаксис, чем-то сишный напоминает, например, зарезервированные символы с помощь простых escape-последовательностей записываются: \\, \{, \}, \|, \".
Каким бы простым он не был, он неизвестен пользователю.
E>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал.
Именно XML парсеры? Ни разу не сталкивался, хотя перевидал их немало.
E>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть.
А они есть.
E> А если конфиг нужно поправить через SSH-подключение на удаленной машине, то в vi Curl-подобный конфиг поправить или написать труда не составляет совершенно.
Тем не менее в общем случае есть как минимум ftp. Поэтому затачиваться под исключительные случаи несколько странно.
E>>>Про убежденность в том, что XML должен применяться везде, где только можно,
AVK>>Это ты про кого?
E>Да так, сложилось у меня такое мнение по ходу обсуждения.
Это не ответ на вопрос.
AVK>>Здесь кто то предлагает насаждатьт XML повсеместно? Или речь все же о хранении в XML конфигурационной информации?
E>Имхо, когда XML применяют для создания конфигурационных файлов объемом в 100-200 строк, это уже и есть насаждение.
И в чем же насаждение? У XML проблемы как раз с файлами больших объемов, с маленькими обьемами у него никаких проблем нет.
E>Хотя, все зависит от характера конфигурационной информации. А так же от предпочтений разработчиков.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Нет. Потому что это валидный XML, следовательно его могут парсить другие парсеры, редактировать другие редакторы, а пользователям не нужно будет разбираться с неизвестным синтаксисом.
E>>Ну насчет синтаксиса, здесь можно поспорить. Например, в Curl очень простой синтаксис, чем-то сишный напоминает, например, зарезервированные символы с помощь простых escape-последовательностей записываются: \\, \{, \}, \|, \".
AVK>Каким бы простым он не был, он неизвестен пользователю.
Есть много пользователей, для которых, что XML, что Curl -- все равно изучать нужно.
E>>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал.
AVK>Именно XML парсеры? Ни разу не сталкивался, хотя перевидал их немало.
Не именно парсеры, а проблемы, когда софт пишется для одной версии библиотеки, а у заказчика стоит другая версия и менять он ее не хочет. Поскольку я XML редко использовал, то особенно с этим не сталкивался. А вот с openssl и iconv проблемы время от времни случаются.
E>> А если конфиг нужно поправить через SSH-подключение на удаленной машине, то в vi Curl-подобный конфиг поправить или написать труда не составляет совершенно.
AVK>Тем не менее в общем случае есть как минимум ftp. Поэтому затачиваться под исключительные случаи несколько странно.
Не-а, нет. Есть SSH вход и все. И это в полне нормальная ситуация.
E>>Да так, сложилось у меня такое мнение по ходу обсуждения.
AVK>Это не ответ на вопрос.
, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH. И вся последующая ветка -- это обсуждение как раз применения XML в конфигах.
AVK>>>Здесь кто то предлагает насаждатьт XML повсеместно? Или речь все же о хранении в XML конфигурационной информации?
E>>Имхо, когда XML применяют для создания конфигурационных файлов объемом в 100-200 строк, это уже и есть насаждение. AVK>И в чем же насаждение? У XML проблемы как раз с файлами больших объемов, с маленькими обьемами у него никаких проблем нет. E>>Хотя, все зависит от характера конфигурационной информации. А так же от предпочтений разработчиков. AVK>А я думал от предпочтений пользователей.
Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> Не именно парсеры, а проблемы, когда софт пишется для одной версии > библиотеки, а у заказчика стоит другая версия и менять он ее не хочет. > Поскольку я XML редко использовал, то особенно с этим не сталкивался. > А вот с openssl и iconv проблемы время от времни случаются.
Линкуешь статически, и никаких проблем.
> Хочется спросить по другому: имеет ли право на существование для > конфигурационных файлов формат, отличный от XML?
Для каких-либо слишком извращенных кастомных конфигов.
Здравствуйте, Cyberax, Вы писали:
C>eao197 wrote:
>> Не именно парсеры, а проблемы, когда софт пишется для одной версии >> библиотеки, а у заказчика стоит другая версия и менять он ее не хочет. >> Поскольку я XML редко использовал, то особенно с этим не сталкивался. >> А вот с openssl и iconv проблемы время от времни случаются.
C>Линкуешь статически, и никаких проблем.
1. Проблемы начинаются, если нужно компилироваться на машине у заказчика. Тогда нужно свою версию библиотеки устанавливать и конфигурировать отдельно, а не бросать в /usr/include, /usr/local/lib.
2. Линковать статически к каждой so-шке, которая входит в программный комплекс? Зачем же тогда DLL придумали?
>> Хочется спросить по другому: имеет ли право на существование для >> конфигурационных файлов формат, отличный от XML?
C>Для каких-либо слишком извращенных кастомных конфигов.
Или наоборот из желания сделать конфиги более простыми
Вообще пора уже завязывать. Я все равно останусь при своем мнении.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
>>> Не именно парсеры, а проблемы, когда софт пишется для одной версии >>> библиотеки, а у заказчика стоит другая версия и менять он ее не хочет. >>> Поскольку я XML редко использовал, то особенно с этим не сталкивался. >>> А вот с openssl и iconv проблемы время от времни случаются. > C>Линкуешь статически, и никаких проблем. > 1. Проблемы начинаются, если нужно компилироваться на машине у > заказчика. Тогда нужно свою версию библиотеки устанавливать и > конфигурировать отдельно, а не бросать в /usr/include, /usr/local/lib.
Нормальные либы элементарно кладутся в дерево исходников своего приложения.
> 2. Линковать статически к каждой so-шке, которая входит в программный > комплекс? Зачем же тогда DLL придумали?
Тогда можно сделать проблемным so-шкам свое имя.
>>> Хочется спросить по другому: имеет ли право на существование для >>> конфигурационных файлов формат, отличный от XML? > C>Для каких-либо слишком извращенных кастомных конфигов. > Или наоборот из желания сделать конфиги более простыми
Здравствуйте, Cyberax, Вы писали:
C>Нормальные либы элементарно кладутся в дерево исходников своего приложения. C>Тогда можно сделать проблемным so-шкам свое имя.
Но тогда создаются проблемы админам при необходимости обновления версий софта. Скажем, стоит на машине OpenSSL 9.6.* и админ сам его обновляет по мере надобности. И все софтины, которые этот OpenSSL используют, автоматически переходят на новую версию. А если рядом, в сторонке, поставить OpenSSL 9.7.*, то админу работы поприбавиться, чему он будет несказанно рад.
C>Не знаю уже, что может быть проще XML.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
AVK>Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
[Offtopic]
Извините, не правильнее было бы написать что Вы конкретно имели в виду. Ну представьте себе, что я просто читаю этот форум — чтобу понять про что эта Ваша мысль, мне придется потратить некоторые усилия (скачать, поставить и т.д.). Таких читающих может быть человек 100. Может надо сделать хорошее дело и рассказать прямо здесь? Или это неподъемные затраты энергии? Я допускаю что не понимаю целей (и соответственно стиля) дискуссии, но тогда я был бы признателен если бы Вы мне все поставили на место и их объяснили).
[/Offtopic]
Возвращясь к config файлам:
У меня другие use cases — когда наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file, он может полагаться только на то, что уже есть на компьютере пользователя — поэтому download современной IDE это не опция. Единственный встроенный XML editor, который я знаю — это редактор property files на Mac OS X. Он не поддерживает XML Schema etc.
Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
Здравствуйте, eao197, Вы писали:
AVK>>Каким бы простым он не был, он неизвестен пользователю.
E>Есть много пользователей, для которых, что XML, что Curl -- все равно изучать нужно.
Есть. Зато есть и те, кто с XML знаком и таких со временем будет только больше. А вот про велосипед я такого сказать не могу.
AVK>>Именно XML парсеры? Ни разу не сталкивался, хотя перевидал их немало.
E>Не именно парсеры, а проблемы, когда софт пишется для одной версии библиотеки, а у заказчика стоит другая версия и менять он ее не хочет.
Я тебе уже на бесплатный парсер в исходниках кроссплатформный приводил. Бери да пользуйся. А под .NET таких проблем просто нет.
E> Поскольку я XML редко использовал, то особенно с этим не сталкивался. А вот с openssl и iconv проблемы время от времни случаются.
Ну да, Пастернака мы не читали, но осуждаем
E>>>Да так, сложилось у меня такое мнение по ходу обсуждения.
AVK>>Это не ответ на вопрос.
E>Для меня -- ответ.
Для тебя может и ответ, но спрашивал то я.
E> Я сказал
, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH. И вся последующая ветка -- это обсуждение как раз применения XML в конфигах.
Ну и? Кто же все таки предлагает использовать XML везде?
E>>>Хотя, все зависит от характера конфигурационной информации. А так же от предпочтений разработчиков. AVK>>А я думал от предпочтений пользователей.
E>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
Право? Не знаю, наверное имеет. Я вобще в вопросах прав не так чтобы особо компетенетен. А вот с технической точки зрения использование ныне для конфигов чего то отличного от XML в новых проектах ИМХО не очень оправдано.
Здравствуйте, mbergal, Вы писали:
M>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
Выглядит как отмазка ИМХО. Ерунда это все — удобно, неудобно. XML вполне удобно править и без нормальных редакторов, вопрос привычки (я к примеру правлю и в Far бывает, и никаких проблем не испытываю, бо привык уже давно за много лет использования, и любой другой текстовый формат вызывает у меня инстинктивную неприязнь). Самое главное — не выдавать свою привычку за технический аргумент.
P.S. — Что касается твоего оффтопа, то в данном конкретном случае лучше действительно один раз увидеть.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Каким бы простым он не был, он неизвестен пользователю.
E>>Есть много пользователей, для которых, что XML, что Curl -- все равно изучать нужно.
AVK>Есть. Зато есть и те, кто с XML знаком и таких со временем будет только больше. А вот про велосипед я такого сказать не могу.
Это так, но, Андрей, я придерживаюсь чуть другой точки зрения. Если мне что-то не нравиться, что я могу либо с этим смириться, либо сделать и развивать то, что мне нравится. Вот в случае XML для конфигов я иду по второму варианту. Велосипед? Конечно. Но такими велосипедами в свое время были многие разработки. Вот, тот же YAML -- велосипед. Но в Ruby он активно применяется.
AVK>Я тебе уже на бесплатный парсер в исходниках кроссплатформный приводил. Бери да пользуйся.
Но аргументы против TinyXML я так же привел. А если брать что-то серьезнее, то опять вернемся к уже обсужденным вещам.
AVK>А под .NET таких проблем просто нет.
Везет вам
А я на C++ программирую. И пока нет необходимости в .NET переходить.
E>> Поскольку я XML редко использовал, то особенно с этим не сталкивался. А вот с openssl и iconv проблемы время от времни случаются.
AVK>Ну да, Пастернака мы не читали, но осуждаем
Это не тот случай. Я знаю, что у моих коллег были проблемы при установке xmlsec у заказчика, когда оказалось, что там не та версия libxml2 стоит. Про openssl и iconv я говорил т.к. сам с ними работаю.
E>> Я сказал
, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH. И вся последующая ветка -- это обсуждение как раз применения XML в конфигах.
AVK>Ну и? Кто же все таки предлагает использовать XML везде?
Имхо, ты и предлагаешь, см. ниже.
E>>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
AVK>Право? Не знаю, наверное имеет. Я вобще в вопросах прав не так чтобы особо компетенетен. А вот с технической точки зрения использование ныне для конфигов чего то отличного от XML в новых проектах ИМХО не очень оправдано.
Ну и как воспринять твои слова про "не очень оправдано"? Т.е. "нужно"? Если нужно, то, имхо, это и есть насаждение.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mbergal, Вы писали:
M>>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
AVK>Выглядит как отмазка ИМХО. Ерунда это все — удобно, неудобно. XML вполне удобно править и без нормальных редакторов, вопрос привычки (я к примеру правлю и в Far бывает, и никаких проблем не испытываю, бо привык уже давно за много лет использования, и любой другой текстовый формат вызывает у меня инстинктивную неприязнь). Самое главное — не выдавать свою привычку за технический аргумент.
Два момента:
— ты говорил о себе, а как же пользователи?
— допускаешь ли ты подобные аргументы со стороны твоих опонентов (я про "любой другой текстовый формат вызывает у меня инстинктивную неприязнь")?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Андрей, по-моему, ты немного потерял use case...
> M> Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
> Выглядит как отмазка ИМХО. Ерунда это все — удобно, неудобно. XML вполне удобно править и без нормальных редакторов, вопрос привычки <...>
Use case был такой:
наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Это так, но, Андрей, я придерживаюсь чуть другой точки зрения. Если мне что-то не нравиться, что я могу либо с этим смириться, либо сделать и развивать то, что мне нравится.
Ради бога. Только тогда так и говори — я нарисовал свой парсер исключительно из личных предпочтений и не ищи фатальных недостатков в XML.
E> Вот в случае XML для конфигов я иду по второму варианту. Велосипед? Конечно. Но такими велосипедами в свое время были многие разработки. Вот, тот же YAML -- велосипед. Но в Ruby он активно применяется.
Были, я сам такие парсеры писал неоднократно. И что? А еще раньше даже сложение чисел длинее разрядности процессора руками писали.
E>Но аргументы против TinyXML я так же привел. E> А если брать что-то серьезнее, то опять вернемся к уже обсужденным вещам.
Для конфигов TinyXML более чем достаточно. Я как то давно его использовал. А сейчас он мог стать только круче . А еще раньше, когда XML только появлялся, я написал собственный на Дельфи, дня за 3. И, что характерно, прекрасно работал.
AVK>>А под .NET таких проблем просто нет.
E>Везет вам
Никакого везения. Я сам выбирал что мне делать.
AVK>>Ну и? Кто же все таки предлагает использовать XML везде?
E>Имхо, ты и предлагаешь, см. ниже.
Вот так чтобы прям везде? ИМХО ты видимо неверно меня понял.
AVK>>Право? Не знаю, наверное имеет. Я вобще в вопросах прав не так чтобы особо компетенетен. А вот с технической точки зрения использование ныне для конфигов чего то отличного от XML в новых проектах ИМХО не очень оправдано.
E>Ну и как воспринять твои слова про "не очень оправдано"? Т.е. "нужно"? Если нужно, то, имхо, это и есть насаждение.
Это есть, скажем так, некорректные приемы ведения дискуссии.
Здравствуйте, eao197, Вы писали:
E>Два момента: E>- ты говорил о себе, а как же пользователи?
Да.
E>- допускаешь ли ты подобные аргументы со стороны твоих опонентов (я про "любой другой текстовый формат вызывает у меня инстинктивную неприязнь")?
Я не приводил это в качестве аргумента (в отличие от), не передергивай.
AndrewVK,
> E>Такая же хрень, как и мой велосипед. Хрень, потому, что берет из XML только синтаксис. Ничего больше с ним не сделаешь. > > Нет. Потому что это валидный XML, следовательно его могут парсить другие парсеры, редактировать другие редакторы, а пользователям не нужно будет разбираться с неизвестным синтаксисом.
Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто. В другом случае (в javascript) в готовом виде были доступны только регулярные выражения, которыми XML, очевидно, не парсится, т.к. не является регулярной грамматикой. В общем, вряд ли верно говорить о безусловном превосходстве XML в качестве языка конфигурационных файлов без анализа конкретных use cases.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Use case был такой: ПК>
ПК>наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
2) Если же их редактирует админ хотя бы, то современный админ с тем что такое XML обычно знаком. Сейчас по аське спросил нескольких знакомых админов — все о том что такое XML прекрасно знают. А в таком разе править XML по телефону ничуть не сложнее любого другого текстового формата.
ПК>Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.
ПРавить руками пользователям любой текстовый фоайл вобще совершенно неразумно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Это так, но, Андрей, я придерживаюсь чуть другой точки зрения. Если мне что-то не нравиться, что я могу либо с этим смириться, либо сделать и развивать то, что мне нравится.
AVK>Ради бога. Только тогда так и говори — я нарисовал свой парсер исключительно из личных предпочтений и не ищи фатальных недостатков в XML.
Так ведь я в этом контексте и старался говорить. Именно исходя из своего взгляда на то, как должен выглядеть конфигурационный файл, я и сделал свой парсер. А дальше только отстаивал точку зрения, что для конфигов у XML есть реальные альтернативы, пусть и в виде собственных велосипедов. Вот, собственно, и все.
AVK>Никакого везения. Я сам выбирал что мне делать.
Вот и я выбрал для себя не связываться с XML, если этого можно избежать. Пока полет нормальный.
E>>Имхо, ты и предлагаешь, см. ниже.
AVK>Вот так чтобы прям везде? ИМХО ты видимо неверно меня понял.
Вероятно.
AVK>Это есть, скажем так, некорректные приемы ведения дискуссии.
Ok. Приношу извинения, если что-то сказал не так.
Я давно предлагал эту тему закрыть.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто.
Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
ПК> В другом случае (в javascript) в готовом виде были доступны только регулярные выражения, которыми XML, очевидно, не парсится, т.к. не является регулярной грамматикой.
Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
ПК> В общем, вряд ли верно говорить о безусловном превосходстве XML в качестве языка конфигурационных файлов без анализа конкретных use cases.
Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
E>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал.
Да, была привычка выпускать продукты до утверждения стандарта. Или утверждать стандарт после выпуска продукта. Но сейчас xml и схемы приведены к единому знаменателю. Непонятно откуда это утверждение. E>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть.
У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко. Чем я и пользуюсь. (а вот такую вещь как в статье, я за любые коврижки делать не буду. Оно интересна только в познавательном смысле).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал. GZ>Да, была привычка выпускать продукты до утверждения стандарта. Или утверждать стандарт после выпуска продукта. Но сейчас xml и схемы приведены к единому знаменателю. Непонятно откуда это утверждение.
Я вообще-то говорил об API библиотек. Не скажу точно за libxml2, а вот с OpenSSL частенько раньше бывали грабли из-за того, что есть две ветки OpenSSL: 0.9.6* и 0.9.7*. Причем в 0.9.7* есть функции, которых нет в 0.9.6*. Вот если их задействовать, то при попадании на машину, где 0.9.7 отказываются ставить принципиально, приходится либо переубеждать тамошних админов, либо переписывать свой код, либо ставить 0.9.7 втихаря в свой каталог
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Andrei N.Sobchuck wrote:
> Подходит под определении простого конфига. > > C>Для каких-либо слишком извращенных кастомных конфигов. > > Или наоборот из желания сделать конфиги более простыми > ЗЫ. Имхо в .ini 2 уровня.
Здравствуйте, AndrewVK, Вы писали:
ПК>>Use case был такой: ПК>>
ПК>>наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
AVK>1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
Представляю сценарий:
— Алё, служба поддержки? У меня приложение не инсталлируется.
. . .
— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
— У меня вообще ничего не инсталлируется, утилита тоже.
— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
Упс.
Или еще:
— Алё, служба поддержки? У меня приложение не запускается.
. . .
— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
— Утилита тоже не запускается; тоже выдает какую-то странную ошибку XYZ.
— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
Упс.
В общем, "обязательно" может оказаться "желательно". А если формат файла простой, то и вовсе "по желанию".
AVK> 2) Если же их редактирует админ хотя бы, то современный админ с тем что такое XML обычно знаком.
Нет, не современный. Нет, не админ. Нет, не знаком.
ПК>> Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.
AVK> ПРавить руками пользователям любой текстовый фоайл вобще совершенно неразумно.
Зависит от обстоятельств. В реестр или еще куда просить пользователей лазить тоже "неразумно", но иногда приходится.
P.S. А все ради чего? "Чтоб был XML" Прошу понять меня правильно, я за XML в определенных случаях, даже на прошлой работе поддерживал перевод конфигурационных файлов игрушки на XML, т.к., имхо, дополнительные возможности XML (например, XPath) там были полезны. Вопрос в том, всегда ли плюсы от использования XML в качестве формата конфигурационных файлов перевешивают минусы...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто.
AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
В том случае из MsSql вызывался "голый" JavaScript server-side.
ПК>> В другом случае (в javascript) в готовом виде были доступны только регулярные выражения, которыми XML, очевидно, не парсится, т.к. не является регулярной грамматикой.
AVK>Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
А если JavaScript используется не в браузере, а сам по себе, в качестве скриптового языка в составе приложения?
ПК>> В общем, вряд ли верно говорить о безусловном превосходстве XML в качестве языка конфигурационных файлов без анализа конкретных use cases.
AVK>Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
Ну, если отметать чужие use cases как "несущественные", то конечно...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто. AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
VD>Да, хорошая демонстрация очередного заката солнца вручную. Ради хохмы приведу аналог вот этого:
[...] VD>на Шарпе:
[...]
Вся проблема в том, что как правило, закодировать саму сериализацию куда как проще, чем определиться с тем, что именно хранить, зачем хранить и как и когда читать/писать. А закодировано это в три строки или в десять — ну никакой разницы: ни в разработке, ни в сопровождении.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
P.S.
> ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто. > > AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю. > > В том случае из MsSql вызывался "голый" JavaScript server-side.
В том смысле, что этот самый JavaScript, помимо прочего, возвращал строку с XML, из которой нужно было "выудить" некоторую информацию. Почему-то у нас это "элементарно" сделать не вышло.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
ПК>В том случае из MsSql вызывался "голый" JavaScript server-side.
Ну вот из MSSQL отпарсить XML нет никаких проблем и не надо никакой JavaScript звать.
AVK>>Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
ПК>А если JavaScript используется не в браузере, а сам по себе, в качестве скриптового языка в составе приложения?
Еще проще.
AVK>>Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
ПК>Ну, если отметать чужие use cases как "несущественные", то конечно...
Я не отметаю, я пытаюсь услышать реальные причины. Пока ничего круче личных предпочтений я не услышал.
Здравствуйте, TK, Вы писали:
TK>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В том смысле, что этот самый JavaScript, помимо прочего, возвращал строку с XML, из которой нужно было "выудить" некоторую информацию. Почему-то у нас это "элементарно" сделать не вышло.
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
ПК>Представляю сценарий: ПК>
ПК>— Алё, служба поддержки? У меня приложение не инсталлируется.
ПК>. . .
ПК>— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
ПК>— У меня вообще ничего не инсталлируется, утилита тоже.
ПК>— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
ПК>Упс.
ПК>Или еще: ПК>
ПК>— Алё, служба поддержки? У меня приложение не запускается.
ПК>. . .
ПК>— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
ПК>— Утилита тоже не запускается; тоже выдает какую-то странную ошибку XYZ.
ПК>— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
ПК>Упс.
А казалось бы, при чем здесь XML?
ПК>В общем, "обязательно" может оказаться "желательно". А если формат файла простой, то и вовсе "по желанию".
Можно определение понятия "простой формат"? Так чтобы было понятно, чем самопальный велосипед проще XML.
AVK>> 2) Если же их редактирует админ хотя бы, то современный админ с тем что такое XML обычно знаком.
ПК>Нет, не современный. Нет, не админ. Нет, не знаком.
Тогда см. выше.
AVK>> ПРавить руками пользователям любой текстовый фоайл вобще совершенно неразумно.
ПК>Зависит от обстоятельств.
Не зависит. Если конечно не принимать за таковые лень разработчика.
ПК>P.S. А все ради чего? "Чтоб был XML"
Нет, ради стандарта. Вот к примеру современная схема управления автомобилем далека от совершенства. Однако почему то никому не приходит в голову в серийном автомобиле от нее отходить. Здесь то же самое. Появится новый стандарт, который поддержит заметное количество производителей, можно будет обсудить преимущество того и другого. А вот сравнивать самопальный формат и индустриальный можно только при очень особых обстоятельствах.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, TK, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
AVK>Мы еще про конфиги говорим?
Guru считают что конфиги надо читать исключительно через SQL Server 2000?
Здравствуйте, AndrewVK, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
AVK>Мы еще про конфиги говорим?
Не, про то, что "из SQL это делается вовсе непросто"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот из MSSQL отпарсить XML нет никаких проблем и не надо никакой JavaScript звать.
XML приходит из JavaScript -- как теперь с ним работать в SQL? Можешь считать, что последний "интеллектуально" подбирает подходящий конфиг.
AVK>>>Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
ПК>>А если JavaScript используется не в браузере, а сам по себе, в качестве скриптового языка в составе приложения?
AVK>Еще проще.
А именно? На всякий случай: ActiveX и т.п. использовать нельзя: платформа не Windows.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>>>1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
ПК>>Представляю сценарий: <...>
ПК>>Или еще: <...>
AVK>А казалось бы, при чем здесь XML?
При том, что, вопреки твоему утверждению об обязательном редактировании специальной утилитой, в итоге легко встречаются use cases, где это приходится делать "руками".
ПК>>В общем, "обязательно" может оказаться "желательно". А если формат файла простой, то и вовсе "по желанию".
AVK>Можно определение понятия "простой формат"? Так чтобы было понятно, чем самопальный велосипед проще XML.
Даже ini-файл проще, т.к. описывается регулярной грамматикой, и может разбираться регулярными выражениями.
ПК>>P.S. А все ради чего? "Чтоб был XML"
AVK>Нет, ради стандарта.
Это и есть "чтоб был XML".
> Вот к примеру современная схема управления автомобилем <...>
"Пока наши корабли бороздят просторы космоса"
> Появится новый стандарт, который поддержит заметное количество производителей, можно будет обсудить преимущество того и другого.
Есть масса уже существующих стандартов, начиная с пресловутых .ini-файлов. Поддержка "производителями" формата моих конфигов меня интересует в последнюю очередь.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>Ну вот из MSSQL отпарсить XML нет никаких проблем и не надо никакой JavaScript звать.
ПК>XML приходит из JavaScript -- как теперь с ним работать в SQL?
Поднять парсер и распарсить. Посмотри в инете примеры передачи параметров в ХП ввиде XML.
AVK>>Еще проще.
ПК>А именно? На всякий случай: ActiveX и т.п. использовать нельзя: платформа не Windows.
JavaScript не в браузере и не в Windows? Ну так обеспечте тогда доступ к парсеру.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mbergal, Вы писали:
M>>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
AVK>Выглядит как отмазка ИМХО.
Извините, слово "отмазка" отсутствует в лексиконе который я использую для ведения технической дискуссии (да и любой другой). Так что это Ваше утверждение я просто не понял.
AVK>Ерунда это все — удобно, неудобно.
В моем случае "неудобство" — это потеря времени и денег. Не XML-ные config файлы позволяют мне в некоторых моих случаях maximize value/cost ratio. Если все еще непонятно как, то надо тогда мне потратить денек и написать обзор — — попробую сделать его на следующей неделе (обещать не могу).
AVK> XML вполне удобно править и без нормальных редакторов, вопрос привычки (я к примеру правлю и в Far бывает, и никаких проблем не испытываю, бо привык уже давно за много лет использования, и любой другой текстовый формат вызывает у меня инстинктивную неприязнь).
AVK> Самое главное — не выдавать свою привычку за технический аргумент.
Опять не понимаю — Вы имеете в виду, что написанное Вами в предыдущем абзаце это не "технический аргумент". Тогда зачем Вы его тогда писали? Или может быть Вы имели в виду, что отсутствие у меня привычки редактировать XML файлы сводит на нет мои доводы что XML не всегда удобный формат? Но вроде я писал не про себя а пользователей моих продуктов.
AVK>P.S. — Что касается твоего оффтопа, то в данном конкретном случае лучше действительно один раз увидеть.
Ну хорошо, я screenshots сделаю и зашлю сюда. Как насчет редактирования ASP.NET web.config? Поможет проиллюстрировать Вашу мысль? Или лучше что-то другое?
AndrewVK,
> ПК>А именно? На всякий случай: ActiveX и т.п. использовать нельзя: платформа не Windows. > > JavaScript не в браузере и не в Windows? Ну так обеспечте тогда доступ к парсеру.
Зачем эта морока? Только для того, чтоб удовлетворенно говорить, что конфиги у нас в XML?.. С использованием конфигов, основанных на регулярных грамматиках, жизнь становится намного проще: никакие парсеры не нужны, достаточно простых регулярных выражений. И пользователям, вынужденным править конфиги руками, легче объяснить, что там сделать нужно: никаких "заморочек" типа закрытия тегов и &.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Месье любитель извращений?
C>Макрос ORDERED_OBJECT развертывается в реализацию лексиографического C>оператора сравнения (попробуй то же самое сделать в С#)
Гы-гы.
C>Если бы можно было перечислить члены класса, то даже этого бы не C>понадобилось.
Ну, кое где это не проблема. Только не для современных плюсов.
>> C>Будет >> Хрен или дедушка?
C>И то, и другое
C> Вот сейчас с GCCXML играюсь, возможно получится C>сделать что-то типа атрибутов для С++.
А, ну давай...
C>Сейчас NNTP пользуюсь, оно лучше.
Это да. Никаких лишних возможностей. Не напрягает.
>> C>Сейчас дописываю свою личную реализацию MAPI-хранилища для Outlook'а, и >> C>читаю про использование custom-форм в нем, так что в будущем (в конце >> C>лета во время отпуска) возможно будет Janus for Outlook >> Опоздал. У нас уже 100 лет как есть NNTP. Просто подпишись на него >> любой читалкой новостей и мучаться не прийдется.
C>Он кривоват, нет некоторых важных фич Януса.
Во оно как? А в аутлуке они сами появятся?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вся проблема в том, что как правило, закодировать саму сериализацию куда как проще, чем определиться с тем, что именно хранить, зачем хранить и как и когда читать/писать. А закодировано это в три строки или в десять — ну никакой разницы: ни в разработке, ни в сопровождении.
Да, я и не подумал, что у людей бывают стль серьезные проблемы.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А, идея стала понятна! Волшебное слово "reflection". E>Смущает только то, что в спорах про динамическую типизацию ты был ярым сторонником статической типизации. А в данном случае, когда вызов конструктора объекта при компиляции проверить нельзя, тебя динамизм устраивает
Одно другому не мешает. Наличие метаинформации позволяет делать очень много. Например сгенерировать код для часного случая. Но в данном случае все проще.
VD>>А ты точно уверен, что не путаешь синтаксис с семантикой?
E>Обычно нет, но когда семантика выражения скрывается за горами синтаксического мусора, то начинаю путать
Это ни тот случай?
E>Не верю, сам yacc-ом пользовался, так там, чтобы сохранить где-то значения по ходу разбора, то приходилось много чего делать.
Что, больше чем врукопашную парсер сворганить?
E>Ну хотя бы то, что KDE -- это не GUI библиотека
KDE == QT.
E>А функциональность и сложность входящих в KDE продуктов на порядки превосходит Янус (ничего личного).
Я вообще-то видел KDE. Ничего сложного там не заметил.
E> Более того, компонент khtml из KDE был использован Apple для создания своего браузера Safari.
Я бы на их месте взял бы Мозлу. Фаер-фокс однозначно лучше показывает хтмл. Мы взяли ИЕ. Он его показывает еще лучше.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Ну хотя бы то, что KDE -- это не GUI библиотека
VD>KDE == QT.
Ты бы еще сказал, что Windows == MFC
KDE просто использует Qt.
E>>А функциональность и сложность входящих в KDE продуктов на порядки превосходит Янус (ничего личного).
VD>Я вообще-то видел KDE. Ничего сложного там не заметил.
Видимо, ты проглядел: Konqueror, Koffice, Kontact, KDevelop, PIM, и еще много чего.
E>> Более того, компонент khtml из KDE был использован Apple для создания своего браузера Safari.
VD>Я бы на их месте взял бы Мозлу. Фаер-фокс однозначно лучше показывает хтмл. Мы взяли ИЕ. Он его показывает еще лучше.
Да уж, в Apple явно дураки сидят
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>>>А ты точно уверен, что не путаешь синтаксис с семантикой?
E>>Обычно нет, но когда семантика выражения скрывается за горами синтаксического мусора, то начинаю путать
VD>Это ни тот случай?
Под синтаксическим мусором в данном случае я имел в виду не C++ код для парсинга, а синтаксис конфигурационного файла в XML.
E>>Не верю, сам yacc-ом пользовался, так там, чтобы сохранить где-то значения по ходу разбора, то приходилось много чего делать.
VD>Что, больше чем врукопашную парсер сворганить?
Подробнее про генераторы парсеров. Я довольно много в свое время поработал с yacc-ом, поэтому могу говорить о его особенностях (LL(1)-граматики в лице Antlr или COCO/R не использовал, может там что-то и попроще). Вот, например, пусть в конфиге нужно задать серию значений include_path, чтобы конфиг мог иметь приблизительно такой вид:
Поскольку по ходу разбора правил paths нужно будет где-то накапливать значения, я должен буду в каждом из синтаксических правил что-то куда-то сохранять:
paths : /* empty */
| INCLUDE_PATH STR SEMICOLON
{ /* сохраняем значение */ }
| paths INCLUDE_PATH STR SEMICOLON
{ /* еще раз сохраняем значение */ }
Со временем потребовалось расширить синтаксис конфига -- теперь для каждого пути можно указать, относительно чего он задан:
(смысл в том, что реальное значение common_storage может быть задано при старте приложения в командной строке).
Причем, хорошо бы для гибкости сделать возможным указывать relative_to как до значения пути, так и после (для максимальной гибкости). Тут уж правила начнут расширяться:
paths : /* empty */
| INCLUDE_PATH path_value SEMICOLON
{ /* сохраняем значение */ }
| paths INCLUDE_PATH path_value SEMICOLON
{ /* еще раз сохраняем значение */ }
path_value : STR
{ /* куда-то нужно сохранить STR */ }
| STR relative_to
{ /* куда-то нужно сохранить STR и relative_to */ }
| relative_to STR
{ /* куда-то нужно сохранить STR и relative_to */ }
relative_to : RELATIVE_TO STR
{ /* куда-то сохраняем relative_to */ }
А затем конфиг потребовалось еще расширить: представим, что в include_path задается имя каталога, в котором может располагаться несколько архивов. И нужные файлы следует искать не только в самом каталоге, но и внутри этих архивов. В результате конфигурационный файл может принять вид:
Вот тогда составлять граматику становится вообще весело. Более того, каков уровень знаний в области синтаксического разбора должен быть у разработчика, чтобы сопровождать такие конфиги на yacc?
В случае же с XML-DOM парсингом вообще проблем особых нет. Все, что нужно сделать -- это получить DOM-дерево, пробежатся по его элементам, извлекая оттуда значения нужных дочерних элементов. Причем, что хорошо, все значения уже находятся в DOM-дереве, по ходу синтаксического разбора их не нужно нигде сохранять. Что лично мне не нравиться:
1. Естественно, синтаксис:
2. Способ прохода по DOM-у: это будет цикл, в котором будут извлекаться дочерние элементы из DOM-узлов, их значения куда-то будут сохраняться, затем будут вызываться процедуры для извлечения значений из дочерних элементов текущего узла и т.д. В общем-то не так уж и плохо, если это не написано в одной функции объемом в 1500 строк
В моем же подходе синтаксис получается более читабельным:
А для парсинга нужно сделать всего несколько вещей:
1. Определить класс для тега {include_path}, в котором нужно объявить атрибуты для дочерних тегов {arch} и {relative_to}, а так же метод для извлечения готового значения. Получается довольно просто (имхо, опять же):
using namespace cls_2;
class tag_include_t : public tag_scalar_t< std::string >
{
// Вектор дочерних тегов {arch}.
tag_vector_of_tags_t< tag_scalar_t< std::string > > m_arch;
// Дочерний тег {relative_to}
tag_scalar_t< std::string > m_relative_to;
static std::string
arch_extractor( const tag_scalar_t< std::string > & a )
{
return a.query_value();
}
public :
<Конструктор опущен>
...
include_path_t
query_include_path() const
{
include_path_t result( query_value() );
// Если задан relative_path, то извлекаем его.
m_relative_path.query_opt_value( result.m_relative_value );
// Если заданы arch, то извлекаем и их.
std::transform( m_arch.begin(), m_arch.end(),
std::back_inserter( result.m_arch ),
arch_extractor );
return result;
}
};
2. При парсинге конфигурационного файла указать объект tag_include_t или обертку вокруг него (tag_vector_of_tags_t, например).
По объему код получается не намного больше, чем извлечение значений из DOM-представления. Но весь код по работе с конкретным тегом оказывается в одном классе. Это позволяет проще сопровождать данный тег. И, кроме того, позволяет использовать простые теги для формирования более сложных конструкций (например, tag_include_t может быть атрибутом какого-то другого класса-тега).
Ну и плюс к тому, в моем подходе можно сочетать DOM-парсинг (когда в процесс разбора вообще не вмешиваются) и SAX-парсинг (например, можно проверять корректность значений сразу после их синаксического разбора, по завершению очередного тега инициировать парсинг дополнительных файлов и т.д.).
Так что, по удобству парсинга конфигов на C++ (понятно, что это все проигрывает приведенной тобой статье про C#) я оцениваю свой подход равнозначным использованию XML. Но к этому добавляется более читабельный синтаксис. Хотя и отнимается стандартность XML. Но я еще не видел, чтобы у кого-то возникли сложности с освоением как самого формата, так и подобного подхода к разбору конфигов.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2,
> Фаер-фокс однозначно лучше показывает хтмл. Мы взяли ИЕ. Он его показывает еще лучше.
Internet Explorer HTML (т.е. стандартный HTML) показывает хуже, чем Mozilla или Opera. Лучше он показывает только сайты, разработанные специально для него. Т.е. в качестве встраиваемого компонента выбор IE можно объяснять скорее удобством его встраивания при использовании определенных API, нежели тем, как он отображает HTML.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Мы еще про конфиги говорим? TK>>Не, про то, что "из SQL это делается вовсе непросто"
AVK>Я о конфигах говорил, а не о XML вобще.
хм. а мне показалось, что ты говорил про использование XML для хранения кофигурационной информации. Или, было что-то еще?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, mbergal, Вы писали:
AVK>>Выглядит как отмазка ИМХО.
M>Извините, слово "отмазка" отсутствует в лексиконе который я использую для ведения технической дискуссии (да и любой другой). Так что это Ваше утверждение я просто не понял.
Давай воздержимся от мелких подколок, не на корову спорим. Я имел ввиду что то, что ты написал, не выглядит как серьезный технический аргумент.
AVK>>Ерунда это все — удобно, неудобно.
M>В моем случае "неудобство" — это потеря времени и денег. Не XML-ные config файлы позволяют мне в некоторых моих случаях maximize value/cost ratio.
Остается только верить тебе на слово, бо доказательств и аргументов никаких.
AVK>> Самое главное — не выдавать свою привычку за технический аргумент.
M>Опять не понимаю — Вы имеете в виду, что написанное Вами в предыдущем абзаце это не "технический аргумент". Тогда зачем Вы его тогда писали?
Это доказательство от обратного.
M>Но вроде я писал не про себя а пользователей моих продуктов.
Т.е. ты принудительно заставил пользователей изучить свой формат и теперь трактуешь это как фатальный недостаток XML? Ну тогда вопросов нет. Я технический специалист и в вопросах окучивания покупателей не силен.
AVK>>P.S. — Что касается твоего оффтопа, то в данном конкретном случае лучше действительно один раз увидеть. M>Ну хорошо, я screenshots сделаю и зашлю сюда.
Не, скриншот полного представления не даст. Надо именно попробовать.
M>Как насчет редактирования ASP.NET web.config? Поможет проиллюстрировать Вашу мысль? Или лучше что-то другое?
web.config не очень хороший пример, там динамически подключаются потребители, поэтому описать это схемой сложно.
Здравствуйте, eao197, Вы писали:
E> и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.
Вот я тоже против его повсеместного насождения. Но это еще не означет, что нужно быть его полным противником и бороться за малопонятные велосипеды основания для применения нет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>Возвращясь к config файлам: M>У меня другие use cases — когда наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file, он может полагаться только на то, что уже есть на компьютере пользователя — поэтому download современной IDE это не опция. Единственный встроенный XML editor, который я знаю — это редактор property files на Mac OS X. Он не поддерживает XML Schema etc.
M>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mbergal, Вы писали:
M>Извините, слово "отмазка" отсутствует в лексиконе который я использую для ведения технической дискуссии (да и любой другой). Так что это Ваше утверждение я просто не понял.
M>...моих случаях maximize value/cost ratio.
Долго смеялся прочтя эти два фрагмента.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Зачем эта морока? Только для того, чтоб удовлетворенно говорить, что конфиги у нас в XML?.. С использованием конфигов, основанных на регулярных грамматиках, жизнь становится намного проще: никакие парсеры не нужны, достаточно простых регулярных выражений. И пользователям, вынужденным править конфиги руками, легче объяснить, что там сделать нужно: никаких "заморочек" типа закрытия тегов и &.
Напомню, что в замен предлагается написать парсер собственного формата на С++. Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Зачем эта морока? Только для того, чтоб удовлетворенно говорить, что конфиги у нас в XML?.. С использованием конфигов, основанных на регулярных грамматиках, жизнь становится намного проще: никакие парсеры не нужны, достаточно простых регулярных выражений. И пользователям, вынужденным править конфиги руками, легче объяснить, что там сделать нужно: никаких "заморочек" типа закрытия тегов и &.
> Напомню, что в замен предлагается написать парсер собственного формата на С++.
Необязательно. Можно использовать любой из миллиона уже существующих. Например, для формата .ini-файлов.
> Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
Уже приводили use cases неоднократно: 1) нужно, чтоб пользователю было легко править конфигурационный файл "вручную"; 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК> А именно? На всякий случай: ActiveX и т.п. использовать нельзя: платформа не Windows. > > ДЛЛ или SO подойдет?
Вряд ли (см. ниже).
> Так вот я не знаю серверов не способных подключать ДЛЛ-и, и знаю реализации парсеров в виде ДЛЛ-ей.
Там два случая: один — серверный, второй — клиентский. Клиент кросс-платформенный, в нем используется реализация JavaScript из Mozilla (JSRef). Чтоб туда что-нибудь "прикрутить", нужно писать набор переходников в C++. Вопрос: зачем, если конфиги в стиле .ini-файлов прекрасно работают?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Даже ini-файл проще, т.к. описывается регулярной грамматикой, и может разбираться регулярными выражениями. > > ini-файл не сильно проще.
Сильно, т.к. для разбора можно использовать регулярные выражения.
> Вот возвратись на дцать постов назад и погляди на формат для котого привел парсер (простенький, в десять килобайт) eao197.
У eao197 свой use case, отличающийся от приведенного Мишей, тоже вполне жизненный.
К тому же, если посмотреть на дцать постов назад, то выяснится, что речь шла не о выборе между своим форматом и XML, а о решении некоторой задачи на C++. Вместо обсуждения решения автору начали "втирать", что ему решать эту задачу вообще не нужно.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
> ПК>наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
> ПК>
> ПК>Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.
> Развей свою мысль и объясни чем будет проще править самопальный конфиг сделанный под впечателением от Кюрла и т.п.
В данном случае речь идет о правке конфигов такого формата:
name1 = value1
name2 = value2
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> M>Возвращясь к config файлам: > M>У меня другие use cases <...>
> Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
Вывод неверный. Нужно анализировать use cases своих пользователей, и на основе анализа принимать соответствующие решения. Пытаться следовать какой-либо заранее выбранной схеме без учета use cases своих пользователей (например, безусловно использовать XML, или безусловно "изобредать собственные языки на базе синтаксиса разных Кюрлов"), тем более навязывать другим свою схему без учета их use cases — зачастую ошибочно.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Напомню, что в замен предлагается написать парсер собственного формата на С++.
Если говорить про меня, то предлагается использовать на C++ готовый парсер собственного формата.
Имхо, "написать" и "использовать" -- это две большие разницы.
Если тебе не нравится объем кода, в который это использование выливается, то пусть кто-нибудь попробует сделать на C++ разбор аналогичного XML-ного представления средствами того же TinyXML. Тогда и посмотрим.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>> и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.
VD>Вот я тоже против его повсеместного насождения. Но это еще не означет, что нужно быть его полным противником
Т.е., если я считаю, что для конфигурационных файлов есть более удобные форматы, то я являюсь полным противником XML?
VD> и бороться за малопонятные велосипеды основания для применения нет.
Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Даже ini-файл проще, т.к. описывается регулярной грамматикой, и может разбираться регулярными выражениями.
VD>ini-файл не сильно проще. Но тут о нем и речи не шло. Речь идет о сравнении дремучих сомаопальных велосипедах с конфигами на базе ХМЛ.
Влад, говоря про XML ты как бы автоматически подразумеваешь, что C++ код по извлечению данных из XML автоматически не может быть дремучим. Он просто обязательно будет компактным, понятным и сопровождаемым. Просто по определению.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mbergal, Вы писали:
M>>Возвращясь к config файлам: M>>У меня другие use cases — когда наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file, он может полагаться только на то, что уже есть на компьютере пользователя — поэтому download современной IDE это не опция. Единственный встроенный XML editor, который я знаю — это редактор property files на Mac OS X. Он не поддерживает XML Schema etc.
M>>Найти что-то в XML файле непосвященному пользователю достаточно сложно, как и достаточно сложно его корректно модифицировать. 7" (seven inches) нужно писать в Notepad как 7". Надо писать закрывающие тэги — не так и удобно — лишний шанс совершить ошибку.
VD>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
А почему бы и нет? Серьезно, почему нет?
Ведь если следовать твоей логике, то следовало бы на Коболе и Фортране до сих пор программировать. И вообще, зачем было C# делать, если за пять лет до него появилась почти такая же Java?
И разработчики Ruby такие же дремучие велосипедисты как я -- они почему-то YAML для конфигов используют, а не XML (у меня в Ruby 1.8.2 девятнадцать xml-файлов, три из них в тестах, остальные в примерах, и 2024 YAML файлов, которые используются инструментом ri (ruby index)). Да и вообще, взяли да язык свой придумали. Им, видимо, делать больше нечего было.
Кстати, я не изобретал синтаксис -- он уже был изобретен, причем даже не авторами Курла. Я просто сделал парсер этого формата (уже четыре года тому) и использую его для работы с конфигами и подобными вещами. Более того, когда в 2001 году я узнал про Курл, я написал одному из разработчиков Курла о том, что для конфигов Курл удобнее XML (на примере конфига для Java Web Application). И со мной согласились.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Напомню, что в замен предлагается написать парсер собственного формата на С++. Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
Тут правильно подметили, что даже при наличии готового XML-парсера, разбор конфигурационных файлов — не самая простая задача. Особенно если есть уровни вложенности. Вряд ли будет экономнее, чем то, что приведено в самописном парсере.
Для сравнения можно посмотреть в рефлекторе ту гору кода, которая пляшет вокруг довольно-таки строго размеченного app.config в .Net. И это при том, что формат app.config с его секциями и именами классов — далеко не user-friendly, скорее наоборот. На "человеческий" config вся эта белиберда мало похожа.
(Хотя я, как программист, вижу здесь весьма гибкое решение, но опять же — с т.з. программиста)
приведенный тобой фрагмент XML — это просто несбыточный идеал. На деле же, если XML генерить и парсить не "в ручную", а пользуясь стандартной XML сериализацией, или, того хуже app.config/web.config, то получаешь еще более нечитабельное преставление. В последнем случае вообще доступное пониманию лишь программиста.
E>
E>Неужели это выглядит более читабельными и понятным?
Если бы все XML выглядели так же, то это было бы весьма неплохо.
Хотя, тут не поспоришь. На специализированном языке всегда можно проще и понятней написать.
Что касается степени благородства задачи "писания своих велосипедов" — это зависит от сравнительных размеров проектов: целевого и "велосипедного". Если относительный размер второго пренебрежимо мал, а удобства с т.з. первого на лицо, то тут даже и обсуждать нечего, просто делай свое дело хорошо.
Здравствуйте, eao197, Вы писали:
E>Ну хотя бы то, что KDE -- это не GUI библиотека E>А функциональность и сложность входящих в KDE продуктов на порядки превосходит Янус (ничего личного). Более того, компонент khtml из KDE был использован Apple для создания своего браузера Safari.
Кстати, Safari — это весЧь.
не думал, что бывают в природе такие приятные браузеры.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Напомню, что в замен предлагается написать парсер собственного формата на С++.
ПК>Необязательно. Можно использовать любой из миллиона уже существующих. Например, для формата .ini-файлов.
Ненужно подменять тему разговора. О приемуществе инифайлов над хмл я и говорить бы не стал. Если они удовлетворяют, то используй. Тоже какой-ни-какой но стандарт. Да и парсинг этого формата примитивне. Речь же шла о навороте очередных велосипедов на ровном месте. Поднимись на несколько сообщения вверх и перечитай их.
>> Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
ПК>Уже приводили use cases неоднократно: 1) нужно, чтоб пользователю было легко править конфигурационный файл "вручную";
Значит нельзя? Жаль. А я бы хотел послушать про простоту правки вот этого:
По сравлению с форматом основанным на ХМЛ-е.
ПК> 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.
И как ты это собирашся обесечить для подобного формата? Я немного знаком с парсингом и уверяю тебя, что регексами это не отпарсить. Объем кода парсера написанного на С++ ты тоже можешь увидить понявшись на пару веток в верх.
Между тем надыбыть ХМЛ-парсер для любого языка на сегондя не составляет проблем.
ЗЫ
Тут кое-то може подтвержить, что я точно не являюсь фанатом ХМЛ, но для таких задач как конфиги — это почти идеальное решение.
В общем, твой спор
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Напомню, что в замен предлагается написать парсер собственного формата на С++.
E>Если говорить про меня, то предлагается использовать на C++ готовый парсер собственного формата.
Готовым он стал через неделю траха (в лучшем случае). И кроме тебя никому ненужен. Так как люди не хотят изучать все велосипеды мира. Уж извини за прямоту.
E>Имхо, "написать" и "использовать" -- это две большие разницы.
Ага. По этому кое-что использует, а кое-кто пишет обвязочные фрэйморки.
E>Если тебе не нравится объем кода, в который это использование выливается,
Однозначно. Это половина кода полноценного редактора текста. У меря код конфирурировния занял намного меньше.
E> то пусть кто-нибудь попробует сделать на C++ разбор аналогичного XML-ного представления средствами того же TinyXML. Тогда и посмотрим.
А тут смотреть не на что. Готовый парсер всегда будет требовать меньше кодирования. Это аксиома.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> ДЛЛ или SO подойдет?
ПК>Вряд ли (см. ниже).
>> Так вот я не знаю серверов не способных подключать ДЛЛ-и, и знаю реализации парсеров в виде ДЛЛ-ей.
ПК>Там два случая: один — серверный, второй — клиентский. Клиент кросс-платформенный, в нем используется реализация JavaScript из Mozilla (JSRef). Чтоб туда что-нибудь "прикрутить", нужно писать набор переходников в C++.
Не надо песен, а... Для той же мозилы и его скриптов уже давно есть ХМЛ-парсеры. Погляди тот же Кокон. Там ХМЛ из яваскриптов (именно мозильных) на право и на лево используется.
ПК> Вопрос: зачем, если конфиги в стиле .ini-файлов прекрасно работают?
Это очередная подмена понятий. Об ini-файлах речь никто не вел. Речь велась о клепании влосипедов. Короче, не хочу повторяться.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TK, Вы писали:
TK>хм. а мне показалось, что ты говорил про использование XML для хранения кофигурационной информации. Или, было что-то еще?
Ну, и что рукопашный парсер лучше?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Т.е., если я считаю, что для конфигурационных файлов есть более удобные форматы, то я являюсь полным противником XML?
Ты предпочиташь написать велосипд с самопальным форматом вместо того чтобы воспользоваться почти готовым решением. Это твоя огромная проблема. И ХМЛ тут всего лишь частный случай.
Вот ПК тут потихоньку, ну, чтобы было о чем поспорить, постоянно подсовывает разговор о ini-файлах. Так вот по мне они ничем ХМЛ-лю не уступают... до тех пор пока не нжно хранить информацию более сложную чем поимиьивгый ассоциативный список. Но ты же не об этом ведешь речь? Ты предлагашь страгать свои велосипеды только ради банального микроскопического хранилища настроичных данных. Да еще убеждашь, что людей нужно учить твоему доморощенному формату только на основании того, что он тебе кажется более удобным.
VD>> и бороться за малопонятные велосипеды основания для применения нет.
E>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Это не сравнимые вещи. По твоей аналогии я делаю пасрер ХМЛ для дотнета, так как для него его еще нет. Я не изобретаю свой тип редактора. Я всего лишь реализую то что уже стало стандартом.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сильно, т.к. для разбора можно использовать регулярные выражения.
Я об испоьзовании. ХМЛ-парсеры есть почти везде. Так что эта работа уже сделана. Еще раз повторюсь, что тут речь идет о создании велосипеда с оригинальным дизайном.
>> Вот возвратись на дцать постов назад и погляди на формат для котого привел парсер (простенький, в десять килобайт) eao197.
ПК>У eao197 свой use case, отличающийся от приведенного Мишей, тоже вполне жизненный.
Не стоит заговаривать зубы. Или обоснуй необходимость создания подобного велосипеда, или прекращай спорить ради спора. Разговор про инифайлы мне не интересен.
ПК>К тому же, если посмотреть на дцать постов назад, то выяснится, что речь шла не о выборе между своим форматом и XML, а о решении некоторой задачи на C++. Вместо обсуждения решения автору начали "втирать", что ему решать эту задачу вообще не нужно.
Речь шало о бессмысленности решения задачь, для которых уже давно существуют обкатанные решения. Так что кончай "втирать".
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Влад, говоря про XML ты как бы автоматически подразумеваешь, что C++ код по извлечению данных из XML автоматически не может быть дремучим. Он просто обязательно будет компактным, понятным и сопровождаемым. Просто по определению.
Говоря про ХМЛ, я говорю об использовании (повтором и многокртаном) проверенных решений и надежных библиотек. Даже С++ становится не стольк ужасным выбором, если в нем есть отлаженная библиотека для решения конкретной задачи.
Я котигорически против самопальщины и новаторства на ровном месте. Решать нужно ненешенные задачи. А велосипеды лучше делать там где от этого есть отдача. Ну, хотя бы маральная. Конфиги — это не та облась.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Развей свою мысль и объясни чем будет проще править самопальный конфиг сделанный под впечателением от Кюрла и т.п.
ПК>В данном случае речь идет о правке конфигов такого формата: ПК>
ПК>name1 = value1
ПК>name2 = value2
ПК>
Да? Ну, ты мастер подменять тему. А вот такой не хочешь:
Что до инифайлов, то они конечно хороши... до тех пор пока информация умещается в рамках идиомы словаря. А как только данные в конфиге становятся иерархическими (или вообще грфом), то инифайлы становятся сущим адом. И намного проще будет обучить пользователя правть ХМЛ, чем изобретать свои под-форматы и обучать им пользователей. Ну, а еще разумнее будет сделать визуальный редактор. Мы вот вместо того чтобы трепаться в том же Янусе так и поступили. А ты можешь дальще искать гипотетические проблемы в ХМЛ. Мне эта тему уже надоела.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК> Нужно анализировать use cases своих пользователей, и на основе анализа принимать соответствующие решения. Пытаться следовать какой-либо заранее выбранной схеме без учета use cases своих пользователей (например, безусловно использовать XML, или безусловно "изобредать собственные языки на базе синтаксиса разных Кюрлов"), тем более навязывать другим свою схему без учета их use cases — зачастую ошибочно.
Особенно понравилась последняя фраза. Вспоминается нетленка — и ты права жена (с).
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E> Им, видимо, делать больше нечего было.
Японцы. Что с них возьмшь?
E>Кстати, я не изобретал синтаксис -- он уже был изобретен, причем даже не авторами Курла. Я просто сделал парсер этого формата (уже четыре года тому) и использую его для работы с конфигами и подобными вещами. Более того, когда в 2001 году я узнал про Курл, я написал одному из разработчиков Курла о том, что для конфигов Курл удобнее XML (на примере конфига для Java Web Application). И со мной согласились.
Ну, вот теперь попробуй обдуать (я уж и не говорю сделать) что нужно добавить к твоему велосипеду, чтобы сделать универсальный ГУИ для его редактирования. Потом откой Янус... откой его настройки и погляди как редактируется ХМЛ в нем. Потом открой исходники януса и погляди как этот "ХМЛ" вглядит в коде. Думаю ты будешь удивлен, что это просто объект. Потом погляди на объем кода и попробуй оценить перерасход своих сил и потерю от не использования готовых решений и стандартов.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Internet Explorer HTML (т.е. стандартный HTML) показывает хуже, чем Mozilla или Opera. Лучше он показывает только сайты, разработанные специально для него. Т.е. в качестве встраиваемого компонента выбор IE можно объяснять скорее удобством его встраивания при использовании определенных API, нежели тем, как он отображает HTML.
Ой, не нужно мне это расскззывать. Расскажи это, ну, тому же рсдн-у. А то даже через файр-фокс смотреть на него не очень.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ой, не нужно мне это расскззывать. Расскажи это, ну, тому же рсдн-у. А то даже через файр-фокс смотреть на него не очень.
Здравствуйте, VladD2, Вы писали:
>>> Напомню, что в замен предлагается написать парсер собственного формата на С++.
ПК>>Необязательно. Можно использовать любой из миллиона уже существующих. Например, для формата .ini-файлов.
VD>Ненужно подменять тему разговора. О приемуществе инифайлов над хмл я и говорить бы не стал. Если они удовлетворяют, то используй. Тоже какой-ни-какой но стандарт. Да и парсинг этого формата примитивне. Речь же шла о навороте очередных велосипедов на ровном месте. Поднимись на несколько сообщения вверх и перечитай их.
Влад, это два разных use case, не нужно валить их в одну кучу. К собственному формату, предложенному eao197, данные use cases не относятся вообще. Это были use cases не "за формат eao197", а против утверждений Андрея о безусловном преимуществе использования XML для конфигов.
>>> Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
ПК>>Уже приводили use cases неоднократно: 1) нужно, чтоб пользователю было легко править конфигурационный файл "вручную";
VD>Значит нельзя? Жаль. А я бы хотел послушать про простоту правки вот этого:
Это не ко мне, хотя людей, предпочитающих использовать свои собственные форматы конфигов в случае, когда они точнее отражают происходящее, чем XML, я вполне понимаю.
VD>
В данном случае XML отдыхает по полной программе по причине громоздкости и слабой читабельности. Точно также, например, как выбор XML для скриптов NAnt является откровенно неудачной идеей: выражение императивных конструкций через декларативные представляет собой достаточно жалкое зрелище.
ПК>> 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.
VD>И как ты это собирашся обесечить для подобного формата?
Это все было для .ini-подобных файлов. Подветка, начинающаяся с сообщения Миши Бергала к формату, описанному eao197 ранее, не относится.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
ПК>>Там два случая: один — серверный, второй — клиентский. Клиент кросс-платформенный, в нем используется реализация JavaScript из Mozilla (JSRef). Чтоб туда что-нибудь "прикрутить", нужно писать набор переходников в C++.
VD>Не надо песен, а... Для той же мозилы и его скриптов уже давно есть ХМЛ-парсеры.
Так... А ну бегом разбираться в том, как встраивается JSRef в сторонние приложения, и входит ли в комплект JSRef парсер XML...
ПК>> Вопрос: зачем, если конфиги в стиле .ini-файлов прекрасно работают?
VD>Это очередная подмена понятий. Об ini-файлах речь никто не вел. Речь велась о клепании влосипедов.
Могу только порекомендовать внимательнее следить за поворотами дискуссии...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, eao197, Вы писали:
E>>> и я там отметился как противник XML-я. Не вообще, а против его повсеместного насаждения.
VD>>Вот я тоже против его повсеместного насождения. Но это еще не означет, что нужно быть его полным противником
E>Т.е., если я считаю, что для конфигурационных файлов есть более удобные форматы, то я являюсь полным противником XML?
VD>> и бороться за малопонятные велосипеды основания для применения нет.
E>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа.
Просто просятся на фабрику для вторсырья.
class Editor : public DocWatcher {
// Private so Editor objects can not be copied
Editor(const Editor &) : DocWatcher() {}
Editor &operator=(const Editor &) { return *this; }
protected: // ScintillaBase subclass needs access to much of Editor
/** On GTK+, Scintilla is a container widget holding two scroll bars
* whereas on Windows there is just one window with both scroll bars turned on. */
Window wMain; ///< The Scintilla parent window
/** Style resources may be expensive to allocate so are cached between uses.
* When a style attribute is changed, this cache is flushed. */bool stylesValid;
ViewStyle vs;
Palette palette;
int printMagnification;
int printColourMode;
int printWrapState;
int cursorMode;
int controlCharSymbol;
bool hasFocus;
bool hideSelection;
bool inOverstrike;
int errorStatus;
bool mouseDownCaptures;
/** In bufferedDraw mode, graphics operations are drawn to a pixmap and then copied to
* the screen. This avoids flashing but is about 30% slower. */bool bufferedDraw;
/** In twoPhaseDraw mode, drawing is performed in two phases, first the background
* and then the foreground. This avoids chopping off characters that overlap the next run. */bool twoPhaseDraw;
int xOffset; ///< Horizontal scrolled amount in pixelsint xCaretMargin; ///< Ensure this many pixels visible on both sides of caretbool horizontalScrollBarVisible;
int scrollWidth;
bool verticalScrollBarVisible;
bool endAtLastLine;
Surface *pixmapLine;
Surface *pixmapSelMargin;
Surface *pixmapSelPattern;
Surface *pixmapIndentGuide;
Surface *pixmapIndentGuideHighlight;
LineLayoutCache llc;
KeyMap kmap;
Caret caret;
Timer timer;
Timer autoScrollTimer;
enum { autoScrollDelay = 200 };
Point lastClick;
unsigned int lastClickTime;
int dwellDelay;
int ticksToDwell;
bool dwelling;
enum { selChar, selWord, selLine } selectionType;
Point ptMouseLast;
bool inDragDrop;
bool dropWentOutside;
int posDrag;
int posDrop;
int lastXChosen;
int lineAnchor;
int originalAnchorPos;
int currentPos;
int anchor;
int targetStart;
int targetEnd;
int searchFlags;
int topLine;
int posTopLine;
bool needUpdateUI;
Position braces[2];
int bracesMatchStyle;
int highlightGuideColumn;
int theEdge;
enum { notPainting, painting, paintAbandoned } paintState;
PRectangle rcPaint;
bool paintingAllText;
int modEventMask;
SelectionText drag;
enum { selStream, selRectangle, selRectangleFixed } selType;
int xStartSelect;
int xEndSelect;
bool primarySelection;
int caretXPolicy;
int caretXSlop; ///< Ensure this many pixels visible on both sides of caretint caretYPolicy;
int caretYSlop; ///< Ensure this many lines visible on both sides of caretint visiblePolicy;
int visibleSlop;
int searchAnchor;
bool recordingMacro;
int foldFlags;
ContractionState cs;
// Wrapping supportenum { eWrapNone, eWrapWord } wrapState;
int wrapWidth;
int docLineLastWrapped;
Document *pdoc;
Editor();
virtual ~Editor();
virtual void Initialise() = 0;
virtual void Finalise();
void InvalidateStyleData();
void InvalidateStyleRedraw();
virtual void RefreshColourPalette(Palette &pal, bool want);
void RefreshStyleData();
void DropGraphics();
virtual PRectangle GetClientRectangle();
PRectangle GetTextRectangle();
int LinesOnScreen();
int LinesToScroll();
int MaxScrollPos();
Point LocationFromPosition(int pos);
int XFromPosition(int pos);
int PositionFromLocation(Point pt);
int PositionFromLocationClose(Point pt);
int PositionFromLineX(int line, int x);
int LineFromLocation(Point pt);
void SetTopLine(int topLineNew);
bool AbandonPaint();
void RedrawRect(PRectangle rc);
void Redraw();
void RedrawSelMargin();
PRectangle RectangleFromRange(int start, int end);
void InvalidateRange(int start, int end);
int CurrentPosition();
bool SelectionEmpty();
int SelectionStart(int line=-1);
int SelectionEnd(int line=-1);
void SetSelection(int currentPos_, int anchor_);
void SetSelection(int currentPos_);
void SetEmptySelection(int currentPos_);
bool RangeContainsProtected(int start, int end) const;
bool SelectionContainsProtected() const;
int MovePositionOutsideChar(int pos, int moveDir, bool checkLineEnd=true);
int MovePositionTo(int newPos, bool extend=false, bool ensureVisible=true);
int MovePositionSoVisible(int pos, int moveDir);
void SetLastXChosen();
void ScrollTo(int line, bool moveThumb=true);
virtual void ScrollText(int linesToMove);
void HorizontalScrollTo(int xPos);
void MoveCaretInsideView(bool ensureVisible=true);
int DisplayFromPosition(int pos);
void EnsureCaretVisible(bool useMargin=true, bool vert=true, bool horiz=true);
void ShowCaretAtCurrentPosition();
void DropCaret();
void InvalidateCaret();
void NeedWrapping(int docLineStartWrapping=0);
bool WrapLines();
void LinesJoin();
void LinesSplit(int pixelWidth);
int SubstituteMarkerIfEmpty(int markerCheck, int markerDefault);
void PaintSelMargin(Surface *surface, PRectangle &rc);
LineLayout *RetrieveLineLayout(int lineNumber);
void LayoutLine(int line, Surface *surface, ViewStyle &vstyle, LineLayout *ll,
int width=LineLayout::wrapWidthInfinite);
ColourAllocated TextBackground(ViewStyle &vsDraw, bool overrideBackground, ColourAllocated background, bool inSelection, int styleMain, int i, LineLayout *ll);
void DrawIndentGuide(Surface *surface, int lineVisible, int lineHeight, int start, PRectangle rcSegment, bool highlight);
void DrawEOL(Surface *surface, ViewStyle &vsDraw, PRectangle rcLine, LineLayout *ll,
int line, int lineEnd, int xStart, int subLine, int subLineStart,
bool overrideBackground, ColourAllocated background);
void DrawLine(Surface *surface, ViewStyle &vsDraw, int line, int lineVisible, int xStart,
PRectangle rcLine, LineLayout *ll, int subLine=0);
void RefreshPixMaps(Surface *surfaceWindow);
void Paint(Surface *surfaceWindow, PRectangle rcArea);
long FormatRange(bool draw, RangeToFormat *pfr);
int TextWidth(int style, const char *text);
virtual void SetVerticalScrollPos() = 0;
virtual void SetHorizontalScrollPos() = 0;
virtual bool ModifyScrollBars(int nMax, int nPage) = 0;
virtual void ReconfigureScrollBars();
void SetScrollBars();
void ChangeSize();
void AddChar(char ch);
virtual void AddCharUTF(char *s, unsigned int len, bool treatAsDBCS=false);
void ClearSelection();
void ClearAll();
void ClearDocumentStyle();
void Cut();
void PasteRectangular(int pos, const char *ptr, int len);
virtual void Copy() = 0;
virtual bool CanPaste();
virtual void Paste() = 0;
void Clear();
void SelectAll();
void Undo();
void Redo();
void DelChar();
void DelCharBack(bool allowLineStartDeletion);
virtual void ClaimSelection() = 0;
virtual void NotifyChange() = 0;
virtual void NotifyFocus(bool focus);
virtual int GetCtrlID() { return ctrlID; }
virtual void NotifyParent(SCNotification scn) = 0;
virtual void NotifyStyleToNeeded(int endStyleNeeded);
void NotifyChar(int ch);
void NotifyMove(int position);
void NotifySavePoint(bool isSavePoint);
void NotifyModifyAttempt();
virtual void NotifyDoubleClick(Point pt, bool shift);
void NotifyUpdateUI();
void NotifyPainted();
bool NotifyMarginClick(Point pt, bool shift, bool ctrl, bool alt);
void NotifyNeedShown(int pos, int len);
void NotifyDwelling(Point pt, bool state);
void NotifyZoom();
void NotifyModifyAttempt(Document *document, void *userData);
void NotifySavePoint(Document *document, void *userData, bool atSavePoint);
void CheckModificationForWrap(DocModification mh);
void NotifyModified(Document *document, DocModification mh, void *userData);
void NotifyDeleted(Document *document, void *userData);
void NotifyStyleNeeded(Document *doc, void *userData, int endPos);
void NotifyMacroRecord(unsigned int iMessage, uptr_t wParam, sptr_t lParam);
void PageMove(int direction, bool extend=false);
void ChangeCaseOfSelection(bool makeUpperCase);
void LineTranspose();
void LineDuplicate();
virtual void CancelModes();
void NewLine();
void CursorUpOrDown(int direction, bool extend=false);
int StartEndDisplayLine(int pos, bool start);
virtual int KeyCommand(unsigned int iMessage);
virtual int KeyDefault(int/* key */, int/*modifiers*/);
int KeyDown(int key, bool shift, bool ctrl, bool alt, bool *consumed=0);
int GetWhitespaceVisible();
void SetWhitespaceVisible(int view);
void Indent(bool forwards);
long FindText(uptr_t wParam, sptr_t lParam);
void SearchAnchor();
long SearchText(unsigned int iMessage, uptr_t wParam, sptr_t lParam);
long SearchInTarget(const char *text, int length);
void GoToLine(int lineNo);
char *CopyRange(int start, int end);
void CopySelectionRange(SelectionText *ss);
void SetDragPosition(int newPos);
void DisplayCursor(Window::Cursor c);
virtual void StartDrag();
void DropAt(int position, const char *value, bool moving, bool rectangular);
/** PositionInSelection returns 0 if position in selection, -1 if position before selection, and 1 if after.
* Before means either before any line of selection or before selection on its line, with a similar meaning to after. */int PositionInSelection(int pos);
bool PointInSelection(Point pt);
bool PointInSelMargin(Point pt);
void LineSelection(int lineCurrent_, int lineAnchor_);
void DwellEnd(bool mouseMoved);
virtual void ButtonDown(Point pt, unsigned int curTime, bool shift, bool ctrl, bool alt);
void ButtonMove(Point pt);
void ButtonUp(Point pt, unsigned int curTime, bool ctrl);
void Tick();
virtual void SetTicking(bool on) = 0;
virtual void SetMouseCapture(bool on) = 0;
virtual bool HaveMouseCapture() = 0;
void SetFocusState(bool focusState);
void CheckForChangeOutsidePaint(Range r);
int BraceMatch(int position, int maxReStyle);
void SetBraceHighlight(Position pos0, Position pos1, int matchStyle);
void SetDocPointer(Document *document);
void Expand(int &line, bool doExpand);
void ToggleContraction(int line);
void EnsureLineVisible(int lineDoc, bool enforcePolicy);
int ReplaceTarget(bool replacePatterns, const char *text, int length=-1);
int CodePage() const;
virtual sptr_t DefWndProc(unsigned int iMessage, uptr_t wParam, sptr_t lParam) = 0;
public:
// Public so the COM thunks can access it.bool IsUnicodeMode() const;
// Public so scintilla_send_message can use it.virtual sptr_t WndProc(unsigned int iMessage, uptr_t wParam, sptr_t lParam);
// Public so scintilla_set_id can use it.int ctrlID;
};
#endif
Здравствуйте, Шахтер, Вы писали:
E>>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Ш>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.
Ш>
Ш><...>
Ш>
namespace RSharp.Compiler
{
/// <summary>
/// Компилятор/кодогенератор R#. Позволяет открыть проект VS или
/// набор фйлов R#/C#, осущесвить трансформацию и сгенерировать
/// C#-файлы которые в последствии можно откомпилировать стандартным
/// C#-компилятором.
/// </summary>public class Compiler
{
#region Properties & variables.
/// <summary>
/// Подкаталог в каталоге определяемом свойством
/// <see cref="RSharpSubfolder"/> в котором размещаются файлы
/// содержащие метакод (код именяющий код).
/// </summary>public const string MetaProjectSubfolder = "MetaCode";
/// <summary>
/// Подкаталог в каталоге определяемом свойством
/// <see cref="RSharpSubfolder"/> в котором размещаются файлы
/// генерируемые R#-ом конечный C#-файлы.
/// </summary>public const string ProjectSubfolder = "Generated";
private string _rSharpSubfolder = ".RSharp";
/// <summary>
/// Подкатало основного каталога проекта в котром размещаются
/// служебные файлы R#-а.
/// </summary>public string RSharpSubfolder
{
get { return _rSharpSubfolder; }
set { _rSharpSubfolder = value; }
}
string _projectRoot;
/// <summary>
/// Директория проекта.
/// </summary>public string ProjectRoot
{
get { return _projectRoot; }
set { _projectRoot = value.ToLower(); }
}
private RProject _project;
/// <summary>
/// Позволяет получить AST проекта.
/// </summary>protected RProject Project
{
get { return _project; }
}
private RProject _metaProject;
/// <summary>
/// Позволяет получить AST мета-проекта.
/// </summary>protected RProject MetaProject
{
get { return _metaProject; }
}
protected Result _result;
protected Parser _parser;
protected MetaCodeBuilder _builder;
#endregion Properties & variables.
#region Загрузка AST
/// <summary>
/// Считывает файл проекта VS 2003 или 2005, парся
/// файлы входящие в прокт.
/// </summary>
/// <param name="projectPath">Путь к проекту VS.</param>
/// <param name="parametrs">Дополнительные параметры.</param>public void LoadProjectFile(string projectPath, Parametrs parametrs)
{
projectPath = Path.GetFullPath(projectPath);
string[] fileNames = GetProjectFiles(projectPath);
this.ProjectRoot = Path.GetDirectoryName(projectPath);
LoadFiles(fileNames, parametrs);
}
/// <summary>
/// Позволяет загрузить список файлов как единый проект.
/// </summary>
/// <param name="fileNames">Список файлов проекта</param>
/// <param name="parametrs">Параметры комиляции/кодогенерации</param>
/// <returns></returns>public Result LoadFiles(string[] fileNames, Parametrs parametrs)
{
_result = new Result();
// Изменям пути к файлам чтобы в дальнейшем небыло проблем
// при контекстной замене.
MakePathLoverCase(ref fileNames);
_project = null;
PerfCounter timer = new PerfCounter(); // Изсеняем время загрузки.
timer.Start();
// Создаем прокт в который будут подключаться отпарсенные файлы.
RProject project = new RProject();
RProject metaProject = new RProject();
string rsharpRoot = Path.Combine(this.ProjectRoot, "rsharp");
project.ProjectRootPath = this.ProjectRoot;
metaProject.ProjectRootPath = rsharpRoot;
// Создаем и инициализируем парсер, сканер и объект-обработчик ошибок.if (_parser == null)
{
_parser = new Parser(new Scanner());
// Подключаем обработку событий к парсеру.
_parser.SemanticError += UserDefinedError;
_parser.UserDefinedError += UserDefinedError;
}
_parser.DefineConstants.Clear();
if (DefineConstants != null)
_parser.DefineConstants.AddRange(DefineConstants);
// Бежим по фйлам и прасим их...foreach (string fileName in fileNames)
{
try
{
_parser.Scanner.InitFromFile(fileName);
_parser.Parse();
// Добавляем результат парсинга файла в кроект.if (fileName.StartsWith(rsharpRoot))
metaProject.Add(_parser.CompileUnit);
else
project.Add(_parser.CompileUnit);
}
catch (Exception ex)
{
_result.Errors.Add(new CompilerError(
fileName,
_parser.CurrentToken == null ? 0 : _parser.CurrentToken.Location.Line,
_parser.CurrentToken == null ? 0 : _parser.CurrentToken.Location.Col,
"Exception",
"Error during process loading project file: " + ex.Message));
}
}
if (_result.Errors.Count > 0)
_result.Output.Add("R#: Parsing filed with "
+ _result.Errors.Count + " errors.");
else
_result.Output.Add("R#: Parse successfully by "
+ timer.Finish() + " sec.");
_project = project; // Запоминаем прокт для будущего использования.
_metaProject = metaProject;
return _result;
}
/// <summary>
/// Позволяет подключить готовое AST.
/// </summary>
/// <param name="project">AST проекта.</param>
/// <param name="metaProject">AST мета-проекта.</param>
/// <param name="parametrs">
/// Параметры компиляции/кодогенерации.
/// </param>
/// <returns></returns>public Result AttachAst(
RProject project,
RProject metaProject,
Parametrs parametrs)
{
_project = project;
_metaProject = metaProject;
return new Result();
}
#endregion
#region Формирование мета-кода (мета-правил).
// Позволяет выделить мета-код, поместить его в отдельные файлы,
// скомпилировать, и получить сборку содержащую мета-правила.public Result MakeMetaCode()
{
PerfCounter timer = new PerfCounter();
timer.Start();
string metaCodePath = Path.Combine(
Path.Combine(this.ProjectRoot, this.RSharpSubfolder),
MetaProjectSubfolder);
if (!Directory.Exists(metaCodePath))
Directory.CreateDirectory(metaCodePath);
if (_builder == null)
_builder = new MetaCodeBuilder();
_builder.Parser = _parser;
Result result = _builder.Init(_metaProject, metaCodePath,
this.ProjectRoot);
result.Output.Add("R#: Metacode generetion & metaassembly builded successfully by "
+ timer.Finish() + " sec.");
return result;
}
#endregion
#region Трансформация кода проекта мета-правилами.
// Позволяет произвести процесс преобразования.public Result Transform()
{
PerfCounter timer = new PerfCounter();
timer.Start();
string query = "/project/CompileUnits/compile-unit/AssemblyCustomAttributeSections/attribute-section/AttributeDeclarations";
AstNodeCollection globalAttrs =
XPathProvider.QueryNodes(_project, query);
// Вызвать для каждого мета-правила соотвествующий IMetaRule
IMetaRulesCaller metaRulesCaller = _builder.MetaRulesCaller;
metaRulesCaller.Parser = _parser;
metaRulesCaller.Project = _project;
metaRulesCaller.MetaProject = _metaProject;
metaRulesCaller.CallMetaRules(
globalAttrs.ToArray<RAttributeDeclaration>());
Result result = new Result();
if (metaRulesCaller.Errors.Count > 0)
{
result.Errors.AddRange(metaRulesCaller.Errors);
result.Output.Add("R#: Transformation execute failed with "
+ metaRulesCaller.Errors.Count
+ " errors.");
}
else
result.Output.Add("R#: Transformation execute successfully by "
+ timer.Finish() + " sec.");
//TODO: Разобраться с new Result();return result;
}
#endregion
#region Генерация C#-кода (по AST).
// Позволяет сгенерировать C#-код из АСТ.public Result MakeCsCode()
{
PerfCounter timer = new PerfCounter();
timer.Start();
string genPath = Path.Combine(
Path.Combine(this.ProjectRoot, this.RSharpSubfolder),
ProjectSubfolder);
if (!Directory.Exists(genPath))
Directory.CreateDirectory(genPath);
foreach (RCompileUnit unit in _project.CompileUnits)
{
string fileName = this.ProjectRoot.Length == 0
? Path.Combine(genPath, unit.FileName)
: unit.FileName.Replace(this.ProjectRoot,
Path.GetFullPath(genPath));
fileName = fileName.Replace(@"..\", "");
Utilits.SaveToFile(unit, fileName);
}
RSharp.Utils.WriteFile(Path.Combine(genPath, "Info.txt"),
string.Format(
"Code generetion successfully at {0}." + Environment.NewLine
+ "{1} files generated." + Environment.NewLine
+ "{2} AST nones processed.",
DateTime.Now.ToString(),
_project.CompileUnits.Count,
IdGenerator.Next() - 1));
Result result = new Result();
result.Output.Add("R#: C# code generetion successfully by "
+ timer.Finish() + " sec.");
return result;
}
#endregion
#region Work function
public string[] GetProjectFiles(string projectPath)
{
// Открываем диалог выбора фйла проекта.string dir = Path.GetDirectoryName(projectPath);
//if (dir.Length == 0)
// dir = Directory.GetCurrentDirectory();
// Файл проекта - это XML-файл содержащий ряд списков. Их проще
// всего читать датасетом. По этому читаем файл в датасет и
// выскребаем нужную нам информацию.
DataSet ds = new DataSet();
try
{
ds.ReadXml(projectPath);
}
catch (XmlException ex)
{
throw new ApplicationException(
string.Format("The file '{0}' not conform MS Visual Studio 2003/2005 "
+ "or MSBuild project format.", projectPath), ex);
}
// Список файлов хранится в таблице "File".
DataTable dt = ds.Tables["File"];
if (dt == null)
return ReadVs80Format(projectPath);
else
return ReadVs71Format(dt, dir);
}
private string _currentConfiguration;
public const string Configuration = "Configuration";
/// <summary>
/// Текущая конфигурация.
/// Если установить свойство в null, то при считывании
/// проекта в него бедт считано текущее значение.
/// </summary>
/// <value></value>public string CurrentConfiguration
{
get { return _currentConfiguration; }
set { _currentConfiguration = value; }
}
private string[] _loadItemTypes = { "Compile" };
/// <summary>
/// Список типов "Item-ов" которые нужно загружать из проектов
/// MSBuild (VS 2005).
/// По умолчанию он состоит только из "Compile".
/// Более подробно о Item-ах см. документацию на MSBuild MSDN.
/// </summary>public string[] LoadItemTypes
{
get { return _loadItemTypes; }
set { _loadItemTypes = value; }
}
private string[] _defineConstants;
/// <summary>
/// Список предопределенных define-ов. Напрмер, "DEBUG" и "TRACE".
/// </summary>public string[] DefineConstants
{
get { return _defineConstants; }
set { _defineConstants = value; }
}
private static string GetMSBuildPropertyValue(
MsBuildProjectHelper msbuild,
string propertyName)
{
BuildProperty prop = msbuild.Project.EvaluatedProperties[propertyName];
if (prop == null)
return"";
return prop.Value;
}
protected string[] ReadVs80Format(string projectPath)
{
string dir = Path.GetDirectoryName(projectPath);
MsBuildProjectHelper msbuild = new MsBuildProjectHelper(projectPath);
// Если конфигурация принятая по умолчанию не совпадает с
// CurrentConfiguration, то устанавливаем конфигурацию.
// Это приведет к тому, что будет считаны файлы и настройки именно этой
// конфигурации.if (CurrentConfiguration == null)
CurrentConfiguration =
GetMSBuildPropertyValue(msbuild, Configuration);
else
{
// Получаем значение конфигурации принятой по умолчанию.string configuration = GetMSBuildPropertyValue(msbuild, Configuration);
if (configuration != CurrentConfiguration)
msbuild.Project.SetProperty(Configuration, "CurrentConfiguration", "");
}
if (DefineConstants == null)
{
// Считываем предопределенные define-ы.string dc = GetMSBuildPropertyValue(msbuild, "DefineConstants");
DefineConstants = dc.Split(';');
}
// Считываем и филтруем список файлов проекта.
List<string> files = new List<string>(300); // все равно ему помирать :)foreach (string filePath in msbuild.GetProjectFiles(LoadItemTypes))
{
if (CheckCsFile(filePath))
files.Add(Path.Combine(dir, filePath));
}
return files.ToArray();
}
protected static string[] ReadVs71Format(DataTable dt, string dir)
{
// В этот массив будут добавлены файлв входящие в проект.
List<string> files = new List<string>(dt.Rows.Count);
// Получаем идентификаторы колонок содержащие нужную нам информацию.int relPathIndex = dt.Columns["RelPath"].Ordinal;
int subTypeIndex = dt.Columns["SubType"].Ordinal;
int linkIndex = dt.Columns["Link"] == null
? -1 : dt.Columns["Link"].Ordinal;
// Пробегаемся по таблие и читаем информацию о файлах входящих
// в прокт.foreach (DataRow row in dt.Rows)
{
// Относительный путь.string relPath = (string)row[relPathIndex];
// Подтип файлаstring subType = row[subTypeIndex] == DBNull.Value
? null : (string)row[subTypeIndex];
// Если это C#-ный файл и это не автогенеренный файл...if (subType == "Code" && CheckCsFile(relPath))
{
// ... выясняем является ли файл ссылкой на файл из дугого
// проекта или файлом входящим в прокт.string link = linkIndex < 0 || row[linkIndex] == DBNull.Value
? null : (string)row[linkIndex];
// Формируем полный путь к файлу.if (link != null)
files.Add(Path.Combine(dir, link));
else
files.Add(Path.Combine(dir, relPath));
}
}
return files.ToArray();
}
protected static bool CheckCsFile(string filePath)
{
return string.Compare(Path.GetExtension(filePath), ".cs", true) == 0
&& !filePath.EndsWith(".gen.cs");
}
void MakePathLoverCase(ref string[] paths)
{
int len = paths.Length;
string[] newPaths = new string[len];
for (int i = 0; i < len; i++)
{
string path = paths[i];
newPaths[i] = Path.Combine(
Path.GetDirectoryName(path).ToLower(),
Path.GetFileName(path));
}
paths = newPaths;
}
/// <summary>
/// Обработчик ошибок. Помещает ошибку компиляции в список ошибок.
/// </summary>protected void UserDefinedError(int line, int col, string error)
{
_result.Errors.Add(new CompilerError(
_parser.Scanner.FileName,
line,
col,
"err",
error));
}
#endregion
}
}
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VD>Что до инифайлов, то они конечно хороши... до тех пор пока информация умещается в рамках идиомы словаря. А как только данные в конфиге становятся иерархическими (или вообще грфом), то инифайлы становятся сущим адом. И намного проще будет обучить пользователя правть ХМЛ, чем
Здравствуйте, VladD2, Вы писали:
E>>Кстати, я не изобретал синтаксис -- он уже был изобретен, причем даже не авторами Курла. Я просто сделал парсер этого формата (уже четыре года тому) и использую его для работы с конфигами и подобными вещами. Более того, когда в 2001 году я узнал про Курл, я написал одному из разработчиков Курла о том, что для конфигов Курл удобнее XML (на примере конфига для Java Web Application). И со мной согласились.
VD>Ну, вот теперь попробуй обдуать (я уж и не говорю сделать) что нужно добавить к твоему велосипеду, чтобы сделать универсальный ГУИ для его редактирования. Потом откой Янус... откой его настройки и погляди как редактируется ХМЛ в нем. Потом открой исходники януса и погляди как этот "ХМЛ" вглядит в коде. Думаю ты будешь удивлен, что это просто объект. Потом погляди на объем кода и попробуй оценить перерасход своих сил и потерю от не использования готовых решений и стандартов.
Этот формат хорош тем, что он гораздо читабельнее XML и его правка не требует навороченных визуальных редакторов.
Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Т.е., если я считаю, что для конфигурационных файлов есть более удобные форматы, то я являюсь полным противником XML?
VD>Ты предпочиташь написать велосипд с самопальным форматом вместо того чтобы воспользоваться почти готовым решением. Это твоя огромная проблема. И ХМЛ тут всего лишь частный случай.
Формат не самопальный. Велосипед уже давно написан и активно используется в узких кругах, причем с очень низкой стоимостью вхождения в него. Для конфигурационных файлов, которые приходится править вручную, XML, имхо, далеко не самая лучшая альтернатива.
VD>Вот ПК тут потихоньку, ну, чтобы было о чем поспорить, постоянно подсовывает разговор о ini-файлах. Так вот по мне они ничем ХМЛ-лю не уступают... до тех пор пока не нжно хранить информацию более сложную чем поимиьивгый ассоциативный список. Но ты же не об этом ведешь речь? Ты предлагашь страгать свои велосипеды только ради банального микроскопического хранилища настроичных данных. Да еще убеждашь, что людей нужно учить твоему доморощенному формату только на основании того, что он тебе кажется более удобным.
Да, я считаю, что если какой-то подход для конкретной задачи удобнее и не дороже альтернатив, то его следует использовать. В моем подходе к парсингу конфигов я вижу следующие преимущества:
— удобочитаемый и простой формат, который реально легко осваивается админами;
— простой механизм парсинга в C++ подобных форматов. Хоть код и получается объемным, но это очень простой код, который так же легко осваивается (не впример XML с DTD и XSD);
— это мощный механиз парсинга. Если ты не заметил, то класс для представления тега {if} -- шаблонный. Один и тот же код применяется и для работы с std::string, и для работы с unsigned int. Точно так же его можно использовать для работы с int или более экзотическими форматами типа IPv4 или IPv6. В случае же с разбором DOM-XML потребуется много действий для преобразования значений из строк в конкретные типы данных (те же самые unsigned int, int, IPv4, IPv6).
VD>>> и бороться за малопонятные велосипеды основания для применения нет.
E>>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
VD>Это не сравнимые вещи. По твоей аналогии я делаю пасрер ХМЛ для дотнета, так как для него его еще нет. Я не изобретаю свой тип редактора. Я всего лишь реализую то что уже стало стандартом.
Нет, у меня другая аналогия. Вот если бы я сделал парсер XML для C++ -- это был бы чистой воды велосипед, т.к. этих парсеров для C++ (хороших и разных), пруд пруди. А вот ты еще один редактор для C# пишешь. Зачем-то.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Точно также, например, как выбор XML для скриптов NAnt является откровенно неудачной идеей: выражение императивных конструкций через декларативные представляет собой достаточно жалкое зрелище.
Можно поподробнее про императивные конструкции в NAnt? Если ты про <if>, то такие конструкции есть и в чисто функциональных языках.
Здравствуйте, vdimas, Вы писали:
V>Тут правильно подметили, что даже при наличии готового XML-парсера, разбор конфигурационных файлов — не самая простая задача. Особенно если есть уровни вложенности. Вряд ли будет экономнее, чем то, что приведено в самописном парсере.
Если воспользоваться XmlSerializer, то безусловно экономнее, потому что разбирать руками при этом вобще ничего не нужно.
V>Для сравнения можно посмотреть в рефлекторе ту гору кода, которая пляшет вокруг довольно-таки строго размеченного app.config в .Net.
Он не строго размеченный, он вобще на 90% реконфигурируемый.
V> И это при том, что формат app.config с его секциями и именами классов — далеко не user-friendly, скорее наоборот. На "человеческий" config вся эта белиберда мало похожа.
А по мне так более чем. Ничуть не сложнее, скажем, конфигов апача. (Если кто опять прицепится к словам — это опять же намек, а не аргумент).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Влад, говоря про XML ты как бы автоматически подразумеваешь, что C++ код по извлечению данных из XML автоматически не может быть дремучим. Он просто обязательно будет компактным, понятным и сопровождаемым. Просто по определению.
VD>Говоря про ХМЛ, я говорю об использовании (повтором и многокртаном) проверенных решений и надежных библиотек. Даже С++ становится не стольк ужасным выбором, если в нем есть отлаженная библиотека для решения конкретной задачи.
Влад, я не подвергал сомнению то, что какой-нибудь TinyXML успешно и без проблем (без: кодировка utf-8 в TinyXml ?
) поднимет конфиг в DOM-представление. Я сомневаюсь, что код по извлечению этого конфига из DOM-представления будет по-определению компактным, понятным и сопровождаемым.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Здравствуйте, Шахтер, Вы писали:
E>>>Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Ш>>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.
Ш>>
Здравствуйте, Andy Panda, Вы писали:
E>>>> Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Ш>>> Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.
Ш>>>
Ш>>><...>
Ш>>>
ПК>> ПК>>>
ПК>>><...>
ПК>>>
AP>?
Гм... Это пример исходников из R#. Не думаю, что исходники обсуждаемого редактора будут сильно отличаться по исполнению...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.
Для плюсов и всего остального есть msxml.dll.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.
IT>Для плюсов и всего остального есть msxml.dll.
Под Lunix-ом, *BSD и Solaris-ом
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
E>>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.
IT>Для плюсов и всего остального есть msxml.dll.
На Mac OS X не работает.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
IT>>>Для плюсов и всего остального есть msxml.dll.
E>>Под Lunix-ом, *BSD и Solaris-ом
IT>Ты подо всё под это пишешь софт?
Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
IT>>Ты подо всё под это пишешь софт?
E>Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).
И как ты обеспечиваешь совместимость для UI, DB, системных вызовов?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
IT>>>Ты подо всё под это пишешь софт?
E>>Если говорить именно про меня, то я пишу библиотеки и framework-и, на основе которых затем делают прикладной софт (в том числе и я делаю). И от нас жизнь реально требует, чтобы наши решения были портируемыми. Сейчас у нас есть запушенные в коммерческую эксплуатацию системы на Windows и Linux-платформах. FreeBSD, Solaris и HP NonStop постоянно мелькают в поле зрения, но дальше тестовых прогонов пока дело не шло, в последний момент заказчик выбирает Linux (RedHat или SuSe).
IT>И как ты обеспечиваешь совместимость для UI, DB, системных вызовов?
К счастью, UI в наших решения особенно и не требуется, это в основном, server-side системы. Но для работы с GUI на C++ мы используем Qt.
Для работы с DB применяем otl. Некоторые из наших систем вообще не нуждаются в БД.
Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.
О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров не будет на много сложнее.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Hello, IT!
You wrote on Fri, 24 Jun 2005 15:20:01 GMT:
E>> Для системных вызовов (сокеты, мультипоточность, работа с dll) пока E>> используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, E>> потихоньку, переползаем под E>> ACE.
I> О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров I> не будет на много сложнее.
Блин, и находят же люди о чем спорить Этих парсеров кроссплатформенных
как грязи — никакие обертки нафиг не нужны.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, потихоньку, переползаем под ACE.
IT>О! Это как раз оно
А о чем это ты?
IT>Думаю, что сделать свою обёртку для XML парсеров не будет на много сложнее.
Может быть, а есть ли смысл?
Исходя из моего скромного опыта работы с libxml2 и xerces получается, что нет единого C++ API для работы с XML парсерами. В таких условиях обертка должна не только содержать какие-то прикладные возможности (скажем преобразования unsigned int из строкового представления в двоичное), но и иметь адаптацию к конкретной XML-подложке (libxml2, xerces, expat, tinyxml, gsoap, ...). Довольно нехилый кусок работы. А если такой прозрачной адаптацией не заниматься, то зачем вообще подобная обертка нужна?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Да уж, сравнил слона и козу. Интерфейс с реализацией, притом реализация с комментариями.
И вообще, если не нравится код, то его следует рефакторить. А вот если не нравится функциональность, то можно и переписать. И причина Влада переписать редактор (как он утверждал сначала за 2 дня ) отнюдь не лежит в этой плоскости.
И вообще, можно прочитать пару книжек а ля Гамма или Фаулер и писать на каждом столбе что классы обязаны быть маленькими. А можно творить и попадаться на том, что не всегда это верно.
Если нам не нравятся большие интерфейсы предлагаю переписать gdi32.dll, user32.dll и kernel32.dll. Кто за?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Sergey, Вы писали:
S>>Блин, и находят же люди о чем спорить Этих парсеров кроссплатформенных как грязи — никакие обертки нафиг не нужны.
IT>Расскажи это нашим почётным велосипедистам
А что, уже такие звания раздают? Хочу!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>AndrewVK,
>> Если ты про <if>, то такие конструкции есть и в чисто функциональных языках.
ПК>Что является подтверждением наличия в большинстве "чисто" функциональных языков императивных конструкций.
<...>
Я бы даже сказал, что здесь есть присутствие двойного языка: первый, XML, отвечает за внешнее описание. А второй, за конструкции вида:
Т.е. кто-то, после извлечения атрибута message из тега echo должен проверить, что в нем содержится. И если там есть имя переменной, то нужно выполнить какое-то действие. Причем провека выполняется уже без использования возможностей XML.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
IT,
> IT>> Для плюсов и всего остального есть msxml.dll. > > ПК> На Mac OS X не работает. > > Значит там должно быть что-то другое.
Есть, конечно. Куча библиотек, из которых остаются кросс-платформенные, т.к. есть еще и Windows. Теперь доходим до дела: никакой готовой интеграции, подобной сериализации C# в XML там обычно нет, нужно делать. Иначе получится "красота" в таком духе: http://rsdn.ru/forum/Message.aspx?mid=1237916
. Часто может оказаться, что собственно формат при оценке затрат на сериализацию уже играет малую роль, т.к. "обвязка", не зависящая от формата, "съедает" большую часть усилий, и представляет наибольшую сложность в реализации. В свете чего вопрос: зачем в этом случае мучиться с XML, если можно сделать более удобный формат, лучше подходящий для нужд конкретного проекта?..
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
IT wrote:
> E>Для системных вызовов (сокеты, мультипоточность, работа с dll) пока > используем свои обертки, которые унаследовали еще из OS/2. Но сейчас, > потихоньку, переползаем под ACE > <http://www.cs.wustl.edu/%7Eschmidt/ACE.html>. > О! Это как раз оно Думаю, что сделать свою обёртку для XML парсеров не > будет на много сложнее.
А зачем? libxml есть везде — сам лично компилировал его для PocketPC
GlebZ,
> Да уж, сравнил слона и козу. Интерфейс с реализацией, притом реализация с комментариями. И вообще, если не нравится код, то его следует рефакторить.
Я сначала хотел выкинуть реализацию, оставив от методов и свойств только сигнатуры, но оставил ради того, чтоб более наглядно было, что именно делает та или иная функция. Особенно позабавило "Открываем диалог выбора фйла проекта" в классе с названием Compiler. В данном случае для меня было существенно качество проектирования на уровне классов, а не качество реализации.
> И вообще, можно прочитать пару книжек а ля Гамма или Фаулер и писать на каждом столбе что классы обязаны быть маленькими.
Здесь "прокол" не в объеме класса, а в неоднородности его обязанностей и в нарушении множества самых базовых принципов OOP: класс и диалоги открывает, и в "потроха" ассоциированных классов "лазит", и знания о формате файлов Visual Studio содержит, и т.п.
> А можно творить и попадаться на том, что не всегда это верно.
Правильно, по коду сразу виден подход: "что тут думать, тут прыгать надо".
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Сейчас взглянул на код повнимательней. Конечно в отсутсвие автора разбирать его как-то нехорошо, однако рискну (поскольку мое мнение его по-моему не обидет). ПК>Я сначала хотел выкинуть реализацию, оставив от методов и свойств только сигнатуры, но оставил ради того, чтоб более наглядно было, что именно делает та или иная функция. Особенно позабавило "Открываем диалог выбора фйла проекта" в классе с названием Compiler.
Меня позабавило название метода MakePathLoverCase. Я не эксперт в английском за пределами технических текстов, но что-то в названии этого методе есть.
ПК>Здесь "прокол" не в объеме класса, а в неоднородности его обязанностей и в нарушении множества самых базовых принципов OOP:
По порядку. ПК>класс и диалоги открывает,
Ты в MFC для вызова COpenSaveDialog делаешь свой класс? Открытие файлов это уже самодостаточные классы. Или ты кроешь людей которые придумали DOMDocument с его методом Load? ПК>и в "потроха" ассоциированных классов "лазит",
Че-то не нашел где? Намекни? ПК>и знания о формате файлов Visual Studio содержит, и т.п.
Может быть действительно два метода типа ReadVs80Format и ReadVs71Format следует выделить в классы. Но что-то сильно криминального в этом я не вижу. Когда следует ожидать 3 формат? И стоит это того?
>> А можно творить и попадаться на том, что не всегда это верно. ПК>Правильно, по коду сразу виден подход: "что тут думать, тут прыгать надо".
Припиши и меня в сей список. У меня тоже такое часто бывает. Начинаю писать, и получается как получается. Но странная вещь — чаще всего получается.
IT wrote:
> C>А зачем? libxml есть везде — сам лично компилировал его для PocketPC > Среди вариантов предложенных eao197 такого варианта не было
libxml2 — было. Вообще, при работе с XML через DOM/SAX и использовании
XPath не так уж и важна конкретная библиотека — разница будет, по
сути,только в синтаксисе.
Например, перевод достаточно большого (4Мб исходников на С++) проекта с
msxml на libxml занял у меня примерно день.
, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH. XML Schema позволяет сделать три вещи:
1. Сделать отображение файла в объект класса
2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации
3. Гарантировать, что подача синтаксически корректного, но неверного семантически конфига приведет к внятному сообщению об ошибке, а не к undefined behavior твоего приложения XSLT в конфигах вроде не очень нужен. Кроме как универсальный способ конвертировать конфиги из одной версии в другую. А, ну еще сделать нормальное отображение конфигурации в браузере. Вообще, кстати, могучая вещь. Сейчас это становится все моднее вообще для произвольных форматов. Вот, к примеру, есть у тебя билд лог. При этом у него с одной стороны, жесткий машинно-читаемый формат, а с другой — дабл-кликаешь его в браузере, а у тебя нормальный человеко-читабельный гипертекст. Конфиг в этом смысле ничуть не хуже.
XPATH позволяет тебе делать такие вещи, как программная модификация конфигов. Ну вот, к примеру, ты написал плагин к чему-то. И тебе надо его в этом чем-то зарегистрировать. В XML ты просто берешь и добавляешь свой тег в соответствующий тег конфига этого чего-то:
...
<extensions>
<data>
<extension name="Standard" path="..." author="Initial Author"/>
<extension name="Cool" path="...\" author="eao197">
<!-- пошли настройки специфичные для нашего плагина -->
<Timeout>97</Timeout>
<!-- конец настроек специфичных для нашего плагина -->
</extension>
</data>
</extensions>
...
При деинсталляции ты должен корректно удалить свою веточку, не тронув остальные. Поэтому банальный откат конфига к доинсталляционной версии не катит. Полное считывание конфига в память, правка и сохранение требуют от твоего плагина знания полной структуры. XPATH позволяет тебе найти место для вставки и удаления своей секции при помощи одного запроса. Причем если даже формат конфига радикально поменяется, тебе не придется обновлять свое описание этого формата. Достаточно будет подправить строку запроса XPath. E>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
Имеет. Но в наше время его применение уже надо обосновывать. Пока что это проще, чем обосновать применение goto, но эта радость ненадолго
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, TK, Вы писали: TK>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции.
Тут мне буквально позавчера рассказывали про маньяков, которые парсили 60000 килобайт XML (само собой, приезжающего с клиента) в процедуре на MS SQL. И ничего, работает. TK>Не набросаешь примерный код на T-SQL?
Гм. А у нас разве статей на эту тему мало?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>Да, я считаю, что если какой-то подход для конкретной задачи удобнее и не дороже альтернатив, то его следует использовать. В моем подходе к парсингу конфигов я вижу следующие преимущества: E>- удобочитаемый и простой формат, который реально легко осваивается админами; E>- простой механизм парсинга в C++ подобных форматов. Хоть код и получается объемным, но это очень простой код, который так же легко осваивается (не впример XML с DTD и XSD); E>- это мощный механиз парсинга. Если ты не заметил, то класс для представления тега {if} -- шаблонный. Один и тот же код применяется и для работы с std::string, и для работы с unsigned int. Точно так же его можно использовать для работы с int или более экзотическими форматами типа IPv4 или IPv6. В случае же с разбором DOM-XML потребуется много действий для преобразования значений из строк в конкретные типы данных (те же самые unsigned int, int, IPv4, IPv6).
Это неверно. Никаких действий вообще не потребуется для большинства несложных типов. Для структур типа IPv4/IPv6 придется дописать немножко кода — по одному разу на тип. Вряд ли объем кода специализации темплейта в твоем случае будет меньше.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.
Т.е. у нас есть ASP приложение. Все заинтересованные в конфигурации странички включают config.asp с примерно следующим содержанием:
Здорово, правда? Кстати, тут есть еще и такое преимущество, что в качестве значений настроек могут выступать не только константы, но и выражения. Что и не снилось ни ини файлам, ни XML .
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH. S>XML Schema позволяет сделать три вещи: S>1. Сделать отображение файла в объект класса
Мы все еще говорим про C++?
S>2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации
И потом научить пользователя применять этот редактор.
А затем заниматься сопровождением этого редактора.
S>3. Гарантировать, что подача синтаксически корректного, но неверного семантически конфига приведет к внятному сообщению об ошибке, а не к undefined behavior твоего приложения
Откуда информация об undefined behavior?
S>XPATH позволяет тебе делать такие вещи, как программная модификация конфигов. Ну вот, к примеру, ты написал плагин к чему-то. И тебе надо его в этом чем-то зарегистрировать. В XML ты просто берешь и добавляешь свой тег в соответствующий тег конфига этого чего-то:
Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение.
E>>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML? S>Имеет. Но в наше время его применение уже надо обосновывать. Пока что это проще, чем обосновать применение goto, но эта радость ненадолго
Мрачные времена нас ждут. Точно пора в технические писатели переходить
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
E>>- это мощный механиз парсинга. Если ты не заметил, то класс для представления тега {if} -- шаблонный. Один и тот же код применяется и для работы с std::string, и для работы с unsigned int. Точно так же его можно использовать для работы с int или более экзотическими форматами типа IPv4 или IPv6. В случае же с разбором DOM-XML потребуется много действий для преобразования значений из строк в конкретные типы данных (те же самые unsigned int, int, IPv4, IPv6). S>Это неверно. Никаких действий вообще не потребуется для большинства несложных типов. Для структур типа IPv4/IPv6 придется дописать немножко кода — по одному разу на тип. Вряд ли объем кода специализации темплейта в твоем случае будет меньше.
В моем случае не придется переделывать код по разбору тегов. А в случае парсинга DOM-представления для каждого нового типа операции извлечения данных из одних и тех же тегов и атрибутов придется переписывать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали: E>А вот потребуется pixmap-у дополнительные параметры указывать, что делать будешь? Теги-то они расширяемее
Дык не проблема. Кстати, у Resin, например, большинство параметров настройки могут быть представлены и тегами (тогда будет как раз value=) и атрибутами.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>В моем случае не придется переделывать код по разбору тегов. А в случае парсинга DOM-представления для каждого нового типа операции извлечения данных из одних и тех же тегов и атрибутов придется переписывать.
По-моему мы говорим про что-то разное. Для каждого нового атомарного типа нужно определить десериализацию из строки XML. Все. Все остальное доопределяется метаданными. У тебя метаданными выступают шаблоны — что естественно, с учетом отсутствия других метаданных в С++. Такой же подход можно применить к разбору XML. Только объем работ будет чуть поменьше, т.к. значительную часть возьмет на себя внешний парсер.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>Мы все еще говорим про C++?
Конечно. Натравливаем на схему соответствующий XSLT и получаем .h + .cpp. E>Откуда информация об undefined behavior?
Ну как откуда. У тебя же нет отдельного метода проверки конфига на валидность хотя бы на уровне проверки наличия обязательных тегов и немножественности единственных? E>Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение.
Вопрос остается открытым. Например, сделать резервную копию гораздо проще для одного файла настроек. Кроме того, даже если настройки самого плагина вынесены в его личные файлы, то регистрационная информация вносится в основной конфиг. Нет, я в курсе про то, что приложение может мониторить некоторый путь на предмет внезапного обнаружения подходящих плагинов. Но это далеко не всегда то, чего хочется. E>Мрачные времена нас ждут. Точно пора в технические писатели переходить
Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Здравствуйте, Andy Panda, Вы писали:
E>>>>> Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?
Ш>>>> Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.
Ш>>>>
Ш>>>><...>
Ш>>>>
ПК>>> ПК>>>>
ПК>>>><...>
ПК>>>>
AP>>?
ПК>Гм... Это пример исходников из R#. Не думаю, что исходники обсуждаемого редактора будут сильно отличаться по исполнению...
Не, ну я надеюсь, что после всех слов про ускорение разработки на порядок и пр. бла-бла у Влада просто нет другого выхода, кроме как блеснуть мастерством и заткнуть за пояс Scintillу.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали: VD>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п. S>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.
Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, VladD2, Вы писали: VD>>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п. S>>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.
ANS>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
Кстати да. На самом деле такая штука может быть гораздо более удобна. Например, если в качестве языка для конфигов использовать Python или Ruby. На эту тему даже большое обсуждение было: Python vs C#
доказывалось, что C# легко заменяет скриптовые языки.
Если продолжать в том же духе, то можно сказать:
— конфиги лучше писать на скриптовых языках;
— вместо скриптовых языков лучше использовать C#.
Следовательно, конфиги лучше писать на C#. Получается, что XML идет лесом
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>А вот потребуется pixmap-у дополнительные параметры указывать, что делать будешь? Теги-то они расширяемее S>Дык не проблема. Кстати, у Resin, например, большинство параметров настройки могут быть представлены и тегами (тогда будет как раз value=) и атрибутами.
Т.е. тогда мне нужно будет отдельно разбирать pixmap как атрибут тега if, и как отдельный подтег тега if.
Весело.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Павел Кузнецов, Вы писали:
Ш>>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья. Ш>>
Ш>><...>
Ш>>
ПК> ПК>
<...>
ПК>
Итого:
public/protected/private
0/3/7 полей
5/2/0 свойств
7/4/2 методов
3/0/0 константы
Вобщемто не много. А теперь посчитай тоже самое для хидера из Scintill'ы
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Следовательно, конфиги лучше писать на C#.
Ну, в частности именно такой выбор сделан в WinForms. В отличие от, например, Delphi, где форма описывается внешним ресурсом, в .Net форма сериализуется прямо в код.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>Т.е. тогда мне нужно будет отдельно разбирать pixmap как атрибут тега if, и как отдельный подтег тега if. E>Весело.
В С# тебе ничего не надо будет разбирать. Все сделает XMLSerializer и атрибуты.
В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Мы все еще говорим про C++? S>Конечно. Натравливаем на схему соответствующий XSLT и получаем .h + .cpp.
Это интересно. Нужно будет покурить.
Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах.
E>>Откуда информация об undefined behavior? S>Ну как откуда. У тебя же нет отдельного метода проверки конфига на валидность хотя бы на уровне проверки наличия обязательных тегов и немножественности единственных?
-- Ты суслика видишь?
-- Нет.
-- И я нет. А ведь он есть!
((C) к/ф "ДМБ")
Если этих методов не видно, то это не значит, что такой проверки нет.
Ведь в приведенном мной фрагменте есть только классы, которые описывают тег. И с подачи Влада почему-то все стали думать, что это парсер и есть . Все приведенные мной классы тегов являются, с одной стороны, своеобразным описанием граматики (что-то вроде DTD), а с другой стороны -- они используются для хранения разобранных значений.
А уже реальный вызов парсера (с большинством проверок, как синтаксических, так и семантических) вот он:
А про обязательность тегов и пр. нужно всего лишь посмотреть на конструктор, например, tag_if_t (оригинал исходников вот здесь: Re[4]: Has C# lost its point?
tag_if_t(
// Это имя тега. Оно не задается жестко здесь, т.к. будет задано родительским тегом.const char * name,
// Признак того, должен ли тег быть обязательным. Так же задается родительским тегом.bool is_mandatory )
// Передаем параметры базовому типу.
: base_type_t( name, is_mandatory,
// Вот этот true говорит, что тег {if} должен быть определен всего один раз.true )
// Тег {op} инициализируется собственным конструктором, в котором указывается, что
// он должен быть обязательным.
, m_op( self_tag() )
// У остальных тегов последний параметр равен false, значит они не обязательны.
, m_pixmap( self_tag(), "pixmap", false )
, m_bkcolor( self_tag(), "bkcolor", false )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{
// Вот здесь еще один интересный момент. Для тега {bkcolor} устанавливаются
// ограничения -- он может принимать только одно из фиксированного набора значений.
fill_color_constraint( m_bkcolor_constraint );
m_bkcolor.set_constraint( &m_bkcolor_constraint );
}
По умолчанию, однажды распарсенный тег не должен встречаться в конфиге еще раз. Поэтому, если, например, тег {bkcolor} будет указан два раза, произойдет диагностирование ошибки. Но, если такая семантика необходима, то можно переопределить метод tag_t::on_finish и сбросить в нем признак определенности тега.
Так что все необходимые проверки в парсер включены.
E>>Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение. S>Вопрос остается открытым. Например, сделать резервную копию гораздо проще для одного файла настроек.
Да уж, аргумент
Я тут пытался привести аргументы, что таскание за собой сторонних библиотек типа libxml2 или xerces на разные платформы может быть геморройно, но его в серьез не принимали. А тут оказывается, что сделать резервное копирование одного файла на порядок проще, чем резервное копирование подкаталога с конфигурационными файлами.
E>>Мрачные времена нас ждут. Точно пора в технические писатели переходить S>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя.
Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>В С# тебе ничего не надо будет разбирать. Все сделает XMLSerializer и атрибуты. S>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык? S>Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.
Здравствуйте, Sinclair, Вы писали: ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык? S>Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.
А почему этим не пользуются
S>>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
E>А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)?
Хм. http://rsdn.ru/?article/xml/xmlcpp.xml
Здравствуйте, eao197, Вы писали:
E>Это интересно. Нужно будет покурить. E>Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах.
А чем они будут являться? E>Если этих методов не видно, то это не значит, что такой проверки нет. E>Так что все необходимые проверки в парсер включены.
Ок, хорошо. E>Да уж, аргумент E>Я тут пытался привести аргументы, что таскание за собой сторонних библиотек типа libxml2 или xerces на разные платформы может быть геморройно, но его в серьез не принимали.
Конечно не принимали. Библиотеки таскаешь ты. Даже если тебе очень-очень не хочется выполнить статическую линковку, все библиотеки просто включены раз и навсегда в дистрибутив.
А плагины собственно и сделаны разными разработчиками. И гарантировать, что все их конфигурации будут в рамках одного подкаталога в общем случае не выйдет. В итоге, резервно копировать придется много хаотично разбросанных файлов, и уверенности в окончательности не будет. К тому же, даже если с этим согласиться, все равно как минимум регистрация плагина в конфиге основного приложения является весьма желательной. С точки зрения этой задачи неважно, где хранятся настройки самого плагина. E>А тут оказывается, что сделать резервное копирование одного файла на порядок проще, чем резервное копирование подкаталога с конфигурационными файлами.
S>>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя. E>Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению
Почему же? Дают. Нужно только внятно обосновать преимущества по сравнению с существующим. Я вот пока так и не уловил, чем конкретно провинился XML и почему синтаксис CSS тебе нравится больше.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Это интересно. Нужно будет покурить. E>>Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах. S>А чем они будут являться?
Ну например, вместо m_file_name удобнее бывает использовать pixmap-file-name или .pixmap.
Кроме того бывают случаи, когда после рефакторинга структура класса с конфигурацией не совпадает со структурой тегов в конфигурационном файле.
S>А плагины собственно и сделаны разными разработчиками. И гарантировать, что все их конфигурации будут в рамках одного подкаталога в общем случае не выйдет.
Это почему? Передавай плагинам имя каталога в котором им нужно работать и все.
S>В итоге, резервно копировать придется много хаотично разбросанных файлов, и уверенности в окончательности не будет. К тому же, даже если с этим согласиться, все равно как минимум регистрация плагина в конфиге основного приложения является весьма желательной. С точки зрения этой задачи неважно, где хранятся настройки самого плагина.
Не знаю на счет плагинов, но мы сейчас используем комплексы, которые в динамике собираются из нескольких DLL (в принципе, их можно рассматривать как плагины). Так вот каждая DLL хранит свои конфиги в отдельном подкаталоге общего каталога etc. Каталог etc находится под контролем svn. В такой архитектуре очень легко средствами svn копировать конфигурацию отдельной DLL (плагина) из одной инсталляции в другую. А если конкретный подкаталог вообще спроецирован через svn:externals, то тогда изменения конфигов в одной ветке репозитория автоматически распространяется на все инсталляции. Очень удобно.
S>>>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя. E>>Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению S>Почему же? Дают. Нужно только внятно обосновать преимущества по сравнению с существующим. Я вот пока так и не уловил, чем конкретно провинился XML и почему синтаксис CSS тебе нравится больше.
Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
я вряд ли смогу. Кроме того, это синтаксис не CSS, а Curl.
Если говорить про XML, то я так и не могу понять, зачем мне использовать его для ведения конфигов, особенно в системах, которые вообще в XML не нуждаются. Просто, чтоб был XML?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>>>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
E>>А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)? S>Хм. http://rsdn.ru/?article/xml/xmlcpp.xml
Ну, его еще от MSXML отвязать нужно. И что в результате получится? Проверенное промышленное решение? Или такой же велосипед, как у меня (но для XML-ного синтаксиса)?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Гуй это проперти-грид в Янусе?
В частности. А вообще — способов масса. Главное, что вместе с форматом данных конфига есть и формат метаданных.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: ANS>>Гуй это проперти-грид в Янусе? S>В частности. А вообще — способов масса. Главное, что вместе с форматом данных конфига есть и формат метаданных.
То есть, если я добавлю в конфиг свой тег, то в проперти-гриде он тоже появится?
А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Зачем? Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
Здравствуйте, eao197, Вы писали:
E>>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
Здравствуйте, AndrewVK, Вы писали:
ANS>>А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
AVK>Зачем?
Лишняя сущность. Вопросов бы не было, если бы в этом конфиге хранилась внешняя (по отношению к приложению) информация. Типа, параметры конекта к БД, прокси. Но параметры БД это у вас просто каталог, поркси можно у винды спрашивать.
Текстовый конфиг же для внутренних параметров удобен тем, что для него редактор писать не нужно. А коль у вас редактор есть, то не нужен и текстовый конфиг.
AVK>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
Решается через профили.
Кстати, а что там меняется кроме параметров прокси?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Лишняя сущность. Вопросов бы не было, если бы в этом конфиге хранилась внешняя (по отношению к приложению) информация. Типа, параметры конекта к БД, прокси.
А прокси там и хранится.
ANS> Но параметры БД это у вас просто каталог, поркси можно у винды спрашивать.
Как оказывается неможно. Думаешь ручную настройку добавили от нефиг делать?
ANS>Текстовый конфиг же для внутренних параметров удобен тем, что для него редактор писать не нужно. А коль у вас редактор есть, то не нужен и текстовый конфиг.
Нужен. Потому что и редактор, бывает, глючит, и отлаживаться надо, и вероятность того что он слетит и потом не восстановишь меньше.
AVK>>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
ANS>Решается через профили.
С отдельным конфигом намного проще.
ANS>Кстати, а что там меняется кроме параметров прокси?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали:
E>>>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
я вряд ли смогу. Кроме того, это синтаксис не CSS, а Curl.
ANS>>>Интересно, а почему CSS не XML?
E>>Не понял вопроса.
ANS>Синтаксис в CSS почему не XML?
Так ведь это не у меня нужно спрашивать, а у авторов CSS
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AVK>>>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
ANS>>Решается через профили.
AVK>С отдельным конфигом намного проще.
ANS>>Кстати, а что там меняется кроме параметров прокси?
AVK>Открой, посмотри. Много чего.
Я понимаю Мне интересно, что у тебя разного в офисе и дома? Может и я захочу.
ЗЫ. А список отправленных постов в Янусе как посмотреть?
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>То есть, если я добавлю в конфиг свой тег, то в проперти-гриде он тоже появится?
Нет. Что, в общем-то, правильно. Но внесение соответствующих изменений в класс конфига автоматически подхватится как UI, так и парсером конфига. ANS>А нафига в Янусе вообще конфиг в XML?
Так удобнее. ANS>Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Можно.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>С графами в xml намного лучше чем в .ini?
AVK>http://www.w3.org/TR/xlink/
Ты ЭТО называеш "лучше" и предлагаеш использовать в конфигах?
Здравствуйте, AndrewVK, Вы писали: ANS>>ЗЫ. А список отправленных постов в Янусе как посмотреть?
AVK>Никак. А зачем?
Да вот, несколько раз начал отвечать на один и тот же пост, потом (через час) смотрю висит несколько окон и не помню, я таки ответил или только собирался Решил проверить, что я отправлял, и, опаньки. Пришлось аж на сайт лезть.
Здравствуйте, WolfHound, Вы писали:
Ш>>>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья. Ш>>>
Ш>>><...>
Ш>>>
ПК>> ПК>>
WH><...>
ПК>>
WH>Итого: WH>public/protected/private WH>0/3/7 полей WH>5/2/0 свойств WH>7/4/2 методов WH>3/0/0 константы WH>Вобщемто не много. А теперь посчитай тоже самое для хидера из Scintill'ы
А почему такой упор на размер класса? Само по себе это мало что означает, может служить только косвенным признаком. Как уже говорилось
Здравствуйте, VladD2, Вы писали:
E>>Кстати, я не изобретал синтаксис -- он уже был изобретен, причем даже не авторами Курла. Я просто сделал парсер этого формата (уже четыре года тому) и использую его для работы с конфигами и подобными вещами. Более того, когда в 2001 году я узнал про Курл, я написал одному из разработчиков Курла о том, что для конфигов Курл удобнее XML (на примере конфига для Java Web Application). И со мной согласились.
VD>Ну, вот теперь попробуй обдуать (я уж и не говорю сделать) что нужно добавить к твоему велосипеду, чтобы сделать универсальный ГУИ для его редактирования. Потом откой Янус...
О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? И как ты себе представляешь "универсальный ГУИ" для такого языка?
VD>откой его настройки и погляди как редактируется ХМЛ в нем. Потом открой исходники януса и погляди как этот "ХМЛ" вглядит в коде. Думаю ты будешь удивлен, что это просто объект.
sic! Семантика Янусовых настроек легко аппроксимируется статичной структурой данных. eao197 приводит пример куда как более сложной ситуации.
VD>Потом погляди на объем кода и попробуй оценить перерасход своих сил и потерю от не использования готовых решений и стандартов.
Ещё можно посмотреть на перерасход сил от использования "готовых стандартов" там, где они не уместны.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Павел Кузнецов, Вы писали:
Ш>>>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья. Ш>>>
Ш>>><...>
Ш>>>
ПК>> ПК>>
WH><...>
ПК>>
WH>Итого: WH>public/protected/private WH>0/3/7 полей WH>5/2/0 свойств WH>7/4/2 методов WH>3/0/0 константы WH>Вобщемто не много. А теперь посчитай тоже самое для хидера из Scintill'ы
Механический подход тут не катит.
Попробуй объяснить, зачем в классе Compiler такие методы, как
protected static bool CheckCsFile(string filePath)
{
return string.Compare(Path.GetExtension(filePath), ".cs", true) == 0
&& !filePath.EndsWith(".gen.cs");
}
void MakePathLoverCase(ref string[] paths)
{
int len = paths.Length;
string[] newPaths = new string[len];
for (int i = 0; i < len; i++)
{
string path = paths[i];
newPaths[i] = Path.Combine(
Path.GetDirectoryName(path).ToLower(),
Path.GetFileName(path));
}
paths = newPaths;
}
public string[] GetProjectFiles(string projectPath)
{
// Открываем диалог выбора фйла проекта.string dir = Path.GetDirectoryName(projectPath);
//if (dir.Length == 0)
// dir = Directory.GetCurrentDirectory();
// Файл проекта - это XML-файл содержащий ряд списков. Их проще
// всего читать датасетом. По этому читаем файл в датасет и
// выскребаем нужную нам информацию.
DataSet ds = new DataSet();
try
{
ds.ReadXml(projectPath);
}
catch (XmlException ex)
{
throw new ApplicationException(
string.Format("The file '{0}' not conform MS Visual Studio 2003/2005 "
+ "or MSBuild project format.", projectPath), ex);
}
// Список файлов хранится в таблице "File".
DataTable dt = ds.Tables["File"];
if (dt == null)
return ReadVs80Format(projectPath);
else
return ReadVs71Format(dt, dir);
}
E>Ну например, вместо m_file_name удобнее бывает использовать pixmap-file-name или .pixmap.
Для этого досточно сделать примитивную операцию замены "-" на "_".
E>Кроме того бывают случаи, когда после рефакторинга структура класса с конфигурацией не совпадает со структурой тегов в конфигурационном файле.
Синклер тебе говорит об автоматической генерации С++-класса по описанию из схемы. Несовпадать структура не может. После перегенерации они будут идентичны. Метапрограммирование однако рулит.
E>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
Это не так.
E>Кроме того, это синтаксис не CSS, а Curl.
А это не важно.
E>Если говорить про XML, то я так и не могу понять, зачем мне использовать его для ведения конфигов, особенно в системах, которые вообще в XML не нуждаются. Просто, чтоб был XML?
Просто чтобы не создавать велосипед на ровном месте. Чтобы не городить горы кода и не застовлять пользователей изучать синтаксис твоего чуда.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В данном случае XML отдыхает по полной программе по причине громоздкости и слабой читабельности. Точно также, например, как выбор XML для скриптов NAnt является откровенно неудачной идеей: выражение императивных конструкций через декларативные представляет собой достаточно жалкое зрелище.
Жалким зрелещем является велосипидизм на ровном месте. А формат NAnt-а очень даже удобен. Императивные конструкции там применяются не часто и выглядя очень не плохо.
Вот только это очередная попытка подменить тему разговора. Мы роде о конфигах говорили (и о Шарпе если глянуть на название темы). NAnt-овские же файлы проектов — это контент, а не конфиги (в которых должны лежать настройки).
ПК>>> 2) нужно, чтоб можно было легко работать с форматом конфигурационного файла из компонент, в которых нет готовой поддержки XML, но есть, например, поддержка регулярных выражений.
VD>>И как ты это собирашся обесечить для подобного формата?
ПК>Это все было для .ini-подобных файлов. Подветка, начинающаяся с сообщения Миши Бергала к формату, описанному eao197 ранее, не относится.
Нет, Паша, про ини-файлы только ты пыташся речь завести. Если их формат устраивает, то это тоже вполне стандартное и общепринятое решение. Так что завязывать по всюду кивать на ини-файлы.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Напомню, что в замен предлагается написать парсер собственного формата на С++. Можно привести обоснования разумности данного решения, а не пытаться заговорить зубы?
V>Тут правильно подметили, что даже при наличии готового XML-парсера, разбор конфигурационных файлов — не самая простая задача. Особенно если есть уровни вложенности. Вряд ли будет экономнее, чем то, что приведено в самописном парсере.
Будет железно значительно проще. Особенно если есть схема по которой делаются проверки. Дальше остаетя написать довольно простой код вынимающий данные.
Однако лучшие сабакоеды в данной ситуации обычно советуют применять маппинг на классы. В дотнете это делается элементарно. В С++ прийдется попотеть, но все же потеть придется намного меньше чем с ручной реализацией полноценного парсера. Работа же по интерпретации данных вообще будет идентичной.
Ну, и если уж делается парсер, то куда проще воспользоваться генераторами, особенно когда язык поддается LL(1)-разбору.
V>Для сравнения можно посмотреть в рефлекторе ту гору кода, которая пляшет вокруг довольно-таки строго размеченного app.config в .Net. И это при том, что формат app.config с его секциями и именами классов — далеко не user-friendly, скорее наоборот. На "человеческий" config вся эта белиберда мало похожа.
Не все умею решать задачи просто. Это тоже требует определенного таланта.
V>(Хотя я, как программист, вижу здесь весьма гибкое решение, но опять же — с т.з. программиста)
Вот и ты о том же.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Не, ну я надеюсь, что после всех слов про ускорение разработки на порядок и пр. бла-бла у Влада просто нет другого выхода, кроме как блеснуть мастерством и заткнуть за пояс Scintillу.
Ну, затыкать кого-то за пояс желания нет. Но покая я возился над этим проектом я стал значительно хуже относиться к Сентиле и начал уважать авторов писавших редактор для VS.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
AP>>?
ПК>Гм... Это пример исходников из R#. Не думаю, что исходники обсуждаемого редактора будут сильно отличаться по исполнению...
По-моему тебя попросили обяснить что тебе не нравится в приведенном коде.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Я сначала хотел выкинуть реализацию, оставив от методов и свойств только сигнатуры, но оставил ради того, чтоб более наглядно было, что именно делает та или иная функция.
Твою любовь к микро-классам я не разделяю. Если на разбиение нет причины и интерфес широкий, то нефига этим заниматься. Искуство ради искуства я любить не хочу.
ПК>Особенно позабавило "Открываем диалог выбора фйла проекта" в классе с названием Compiler.
Если посмотреть на код по внимательнее, то не трудно понять, что это просто случайно забытый комментарий. Раньше этот код был в визуальной утилите где действительно было открытие диалога. В общем, халтурный рефакторинг. Код поменял, а на коментарий внимания не обратил.
ПК> В данном случае для меня было существенно качество проектирования на уровне классов, а не качество реализации.
>> И вообще, можно прочитать пару книжек а ля Гамма или Фаулер и писать на каждом столбе что классы обязаны быть маленькими.
ПК>Здесь "прокол" не в объеме класса, а в неоднородности его обязанностей и в нарушении множества самых базовых принципов OOP
Ну, на счет их понимания мы с тобой к общему мнению не пришли. Вкусы есть вкусы.
ПК>: класс и диалоги открывает,
Как я уже сказал выше, это всего лишь забытый при рефакторинге комментарий. А ты лучше бы читал код чем говорить что попало.
ПК> и в "потроха" ассоциированных классов "лазит",
Это ты про что?
ПК> и знания о формате файлов Visual Studio содержит, и т.п.
Дык это его основная задача. Этот класс всего лишь грузит проекты VS и скармливает их парсеру и другим фишкам. Знания о формате конечно можно было вынести в отдельный файл но смысла в этом особого не было.
>> А можно творить и попадаться на том, что не всегда это верно.
ПК>Правильно, по коду сразу виден подход: "что тут думать, тут прыгать надо".
"что тут думать, тут прыгать надо" — это сильное преувеличение, но кое в чем ты прав. В исследовательском проекте очень часто приходится действовать методом тыка. Проблемы сначало нужно решить хоть как-то, а потом уже орефакторить, чтобы было еще красиво и грамотно.
Ну, и наезжать на других намного проще чем сделать что-то самому. С моим подходом есть видимая отдача. А с твоим море теоритических рассуждений. Видимо твой несколько сложнее... настолько что ты можешь написать кучу слов на форуме, но не можешь пары строк кода для сайта или открытого проекта.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А почему такой упор на размер класса? Само по себе это мало что означает, может служить только косвенным признаком. Как уже говорилось
Здравствуйте, VladD2, Вы писали:
VD>Нет, Паша, про ини-файлы только ты пыташся речь завести. Если их формат устраивает, то это тоже вполне стандартное и общепринятое решение. Так что завязывать по всюду кивать на ини-файлы.
Под Unix-ом ini-файлы совершенно не стандартное и, исторически, не решение. И функциональность по работе с ini-файлами в Unix-ах реализуется сторонними библиотеками.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Ну например, вместо m_file_name удобнее бывает использовать pixmap-file-name или .pixmap.
VD>Для этого досточно сделать примитивную операцию замены "-" на "_".
В конфигах? А зачем? Если я что-то заменил внутри программы и это может не влиять на внешнее окружение, то это и не должно влиять. А так вздумается мне заменить в коде m_pixmap_file_name на m_image_file_name и что, править после этого все конфиги? Править документацию, в которой эти конфиги описаны? Переобучать администраторов, которые эти конфиги правят? Не забывать исправлять конфиги при обновлении версий софта на серверах. И при этом помнить, какие сервера еще не подверглись обновлению?
Нет уж, увольте.
E>>Кроме того бывают случаи, когда после рефакторинга структура класса с конфигурацией не совпадает со структурой тегов в конфигурационном файле.
VD>Синклер тебе говорит об автоматической генерации С++-класса по описанию из схемы. Несовпадать структура не может. После перегенерации они будут идентичны. Метапрограммирование однако рулит.
А можно ссылки на примеры подобных генераторов С++ классов по DTD или XSD?
E>>Кроме того, это синтаксис не CSS, а Curl.
VD>А это не важно.
Это не так.
Например, XML определяет формат записи целых чисел (в десятичном формате, в шестнадцатиричном, в восмеричном, в двоичном)? А вещественных?
Или мне нужно будет обучать пользователей, что если вы хотите записать шестнадцатиричное значение в XML-конфиге, то нужно использовать 0xXXXX. А если восьмеричное, то 0OOOO. А если кому-то придет в голову записывать шестнадцатиричное представление в виде 0XXXXh?
А вот в Curl-е кроме фигурных скобочек такие нюансы так же определены.
E>>Если говорить про XML, то я так и не могу понять, зачем мне использовать его для ведения конфигов, особенно в системах, которые вообще в XML не нуждаются. Просто, чтоб был XML?
VD>Просто чтобы не создавать велосипед на ровном месте. Чтобы не городить горы кода и не застовлять пользователей изучать синтаксис твоего чуда.
Конечно, лучше заставлять пользователей изучать XML. Поставлять вместе со своим продуктом продвинутый IDE, который может править XML с учетом DTD. А еще лучше писать такой продвинутый редактор для конфигов. Сопровождать его, документировать и т.д. и т.п.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mbergal, Вы писали:
AVK>>>Выглядит как отмазка ИМХО.
M>>Извините, слово "отмазка" отсутствует в лексиконе который я использую для ведения технической дискуссии (да и любой другой). Так что это Ваше утверждение я просто не понял.
AVK>Давай воздержимся от мелких подколок, не на корову спорим. Я имел ввиду что то, что ты написал, не выглядит как серьезный технический аргумент.
IMHO, для дискуссии было-бы полезно если-бы Вы так в дальнейшем и писали.
AVK>>>Ерунда это все — удобно, неудобно.
M>>В моем случае "неудобство" — это потеря времени и денег. Не XML-ные config файлы позволяют мне в некоторых моих случаях maximize value/cost ratio.
AVK>Остается только верить тебе на слово, бо доказательств и аргументов никаких.
Так чтобы написать чтобы Вы поняли — надо достаточно много времени приложить и много чего написать. С пол-оборота
Вам непонятно — (use cases подобные моим Вы наверное не встречали) — поработать надо и изложить все в какой-то более проясняющей форме.
AVK>>> Самое главное — не выдавать свою привычку за технический аргумент.
[...]
А, мысль такая — "если кто-то привык в Фаре редактировать ХМЛ файлы — то это не значит что его пользователям это тоже это удобно". Хорошая мысль.
[...]
M>>Как насчет редактирования ASP.NET web.config? Поможет проиллюстрировать Вашу мысль? Или лучше что-то другое?
AVK>web.config не очень хороший пример, там динамически подключаются потребители, поэтому описать это схемой сложно.
OK. Так и запишем — современные IDE "не очень хорошо" помогают редактировать некоторые часто встречаюшиеся XML config files. Или это не то что Вы хотели сказать. Так что они помогают редактировать то? (хочется просто конкретный всеми понимаемый use case для обзора, я не говорю что нет такого в природе — просто я не встречал — следовательно вопрос к знатокам).
А то придется для примера взять NHibernate mapping file (хотя в общем то это не config file), потому как ничего лучше не знаю.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали: VD>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п. S>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда. S>Т.е. у нас есть ASP приложение. Все заинтересованные в конфигурации странички включают config.asp с примерно следующим содержанием: S>
S>Здорово, правда? Кстати, тут есть еще и такое преимущество, что в качестве значений настроек могут выступать не только константы, но и выражения. Что и не снилось ни ини файлам, ни XML .
Точно. BTW, такое же используется в Mozilla/Firefox (из всем известных програм).
Здравствуйте, mbergal, Вы писали:
M>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, VladD2, Вы писали: VD>>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п. S>>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда. S>>Т.е. у нас есть ASP приложение. Все заинтересованные в конфигурации странички включают config.asp с примерно следующим содержанием: S>>
S>>Здорово, правда? Кстати, тут есть еще и такое преимущество, что в качестве значений настроек могут выступать не только константы, но и выражения. Что и не снилось ни ини файлам, ни XML .
M>Точно. BTW, такое же используется в Mozilla/Firefox (из всем известных програм).
Здравствуйте, eao197, Вы писали:
E>Например, XML определяет формат записи целых чисел (в десятичном формате, в шестнадцатиричном, в восмеричном, в двоичном)? А вещественных?
Здравствуйте, mbergal, Вы писали:
M>>>В моем случае "неудобство" — это потеря времени и денег. Не XML-ные config файлы позволяют мне в некоторых моих случаях maximize value/cost ratio.
AVK>>Остается только верить тебе на слово, бо доказательств и аргументов никаких.
M>Так чтобы написать чтобы Вы поняли — надо достаточно много времени приложить и много чего написать.
Но с меня то ты требуешь.
M>Вам непонятно — (use cases подобные моим Вы наверное не встречали) — поработать надо и изложить все в какой-то более проясняющей форме.
Не то чтобы непонятно, я вобще аргументов не вижу.
AVK>>>> Самое главное — не выдавать свою привычку за технический аргумент.
M>[...] M>А, мысль такая — "если кто-то привык в Фаре редактировать ХМЛ файлы — то это не значит что его пользователям это тоже это удобно". Хорошая мысль.
Ровно так же верна подобная мысль и в отношении вашего формата. На что я собственно инамекнул. Однако вы с Пашей то ли не поняли намека, то ли предпочти непонять.
M>OK. Так и запишем — современные IDE "не очень хорошо" помогают редактировать некоторые часто встречаюшиеся XML config files.
Я, кажется, говорил не о редактировании файлов в существующих системах, а в использовании XML в собственных. Ничто не мешало МС написать для основных хендлеров app.config схемы, и тогда бы все прекрасно работало. И еще, на всякий случай напомню, в этой ветке речь идет о полезности XML Schema для конфигов:
E>Справедливо. Но зачем для конфигурационных файлов XML Schema, XSLT, XPATH и пр. понять не могу.
Ну что ж — тогда могу просоветовать попробовать любой современный IDE, понимающий XML-Schema.
Приводить в качестве аргумента противоположной точки зрения файл без схемы несколько странно, не находишь?
M>Так что они помогают редактировать то?
XML снабженный схемой.
M>А то придется для примера взять NHibernate mapping file (хотя в общем то это не config file), потому как ничего лучше не знаю.
Не знаю, ни разу не сталкивался. У него схема есть?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mbergal, Вы писали:
[...] M>>А, мысль такая — "если кто-то привык в Фаре редактировать ХМЛ файлы — то это не значит что его пользователям это тоже это удобно". Хорошая мысль.
AVK>Ровно так же верна подобная мысль и в отношении вашего формата.
Да, надо — "если кто-то привык в Фаре редактировать config файлы — то это не значит что его пользователям это тоже удобно"
AVK> На что я собственно инамекнул. Однако вы с Пашей то ли не поняли намека, то ли предпочти непонять.
Я намеки иногда трудно понимаю, особенно в технических дискуссиях.
Здравствуйте, Шахтер, Вы писали:
Ш>Попробуй объяснить, зачем в классе Compiler такие методы, как
CheckCsFile и MakePathLoverCase результат декомпозиции. Это часть кода класса вынесенная из больших функций при рефакторинге чтобы не загромождать код и упростить восприятие. CheckCsFile и MakePathLoverCase вещи сугобо спефические и тут им самое место.
GetProjectFiles вообще часть интерфейса класса. Класс используется в том числе и для загрузки проектов в визульных утилитах.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Этот формат хорош тем, что он гораздо читабельнее XML и его правка не требует навороченных визуальных редакторов.
Да уж... куда же более читабельнее.
E>Кроме того, я говорю про C++. Ситуация с Янусом совсем другая, т.к. для C# есть мощная поддержка XML-сериализации со стороны framework-а.
Мощьная поддержка ХМЛ сегодня есть почти везде. Но хочу напомнить, что тема была как раз о Шарпе.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках?
Они там не нужны. Это конфиг а не скриптовый файл.
ГВ> И как ты себе представляешь "универсальный ГУИ" для такого языка?
Глянь, например, msbuild и его API. Там как раз и гуи делается на раз и условные операторы есть правда декларативные но это роли не играет.
VD>>откой его настройки и погляди как редактируется ХМЛ в нем. Потом открой исходники януса и погляди как этот "ХМЛ" вглядит в коде. Думаю ты будешь удивлен, что это просто объект.
ГВ>sic! Семантика Янусовых настроек легко аппроксимируется статичной структурой данных. eao197 приводит пример куда как более сложной ситуации.
IT тут правильно сказал, что товарищь слишком усложняет. Ну, да и условия можно приклеить на атрибутах. Вот только редактировать такой конфиг программно уже вряд ли удастся.
ГВ>Ещё можно посмотреть на перерасход сил от использования "готовых стандартов" там, где они не уместны.
И кто бы мог подумать? Ну, ты просто открыл мне глаза.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
Тут в дотнете один орел рассказывал, что просто шарповские файл в качестве конфига использовал. Говорил что ооочень гибко. Вот только изврат все же и с безопасностью могут быть поблемы.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
E>>Следовательно, конфиги лучше писать на C#. S>Ну, в частности именно такой выбор сделан в WinForms. В отличие от, например, Delphi, где форма описывается внешним ресурсом, в .Net форма сериализуется прямо в код.
Вот в Авалоне МС уже забил на эту идею и использует банальный ХМЛ.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>Попробуй объяснить, зачем в классе Compiler такие методы, как
VD>CheckCsFile и MakePathLoverCase результат декомпозиции. Это часть кода класса вынесенная из больших функций при рефакторинге чтобы не загромождать код и упростить восприятие. CheckCsFile и MakePathLoverCase вещи сугобо спефические и тут им самое место.
Им самое место не в классе Compiler, а в коллекции свободных функций-утилит для работы с именами фоайлов.
VD>GetProjectFiles вообще часть интерфейса класса. Класс используется в том числе и для загрузки проектов в визульных утилитах.
То же самое -- свободная функция-утилита для извлечения списка файлов из файла проекта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Например, XML определяет формат записи целых чисел (в десятичном формате, в шестнадцатиричном, в восмеричном, в двоичном)? А вещественных?
AVK>http://www.w3.org/TR/xmlschema-2/
Интересно, а в каком состоянии это было в 2001-2002 годах?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>http://www.w3.org/TR/xmlschema-2/
E>>Интересно, а в каком состоянии это было в 2001-2002 годах?
AVK>Во-первых там есть история, во-вторых какое это имеет значение?
Ну хотя бы то, что я начал использовать Curl-формат с 2001 года. И с тех пор много реально работающего кода построено на этом велосипеде. И у меня нет желания менять работающий код на что-то более модное, но менее удобное для меня.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
TK>>Не, про то, что "из SQL это делается вовсе непросто" VD>В 2005 специльный тип. В более ранних версиях подкключаются КОМ-объекты и ДЛЛ-и.
За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве
параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно.
VD>Это точно проще чем писать парсер собственного конфига на TSQL.
хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT...
Собственный конфиг (например, java properties) можно распарсить без особых проблем.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
TK>>хм. а мне показалось, что ты говорил про использование XML для хранения кофигурационной информации. Или, было что-то еще? VD>Ну, и что рукопашный парсер лучше?
Лучше тот, который выбран на основе конкретных use cases. Говорить же, что XML это серебряная пуля — не верно. Их не бывает.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
VD>Тут в дотнете один орел рассказывал, что просто шарповские файл в качестве конфига использовал. Говорил что ооочень гибко. Вот только изврат все же и с безопасностью могут быть поблемы.
Я тоже это использовал — я писал билиотечку для стохастического анализа и мне нужно было параметризоввывать ее вероятностными функциями распределения, имеющими практически произвольный вид. Ничего юзабильнее конфига на шарпе я не придумал — если кто придумает — поделитесь )
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Здравствуйте, Sinclair, Вы писали:
S>Конечно. Натравливаем на схему соответствующий XSLT и получаем .h + .cpp.
Слишком громоздко.
Когда я решал такую задачу, я достигал результата в два приёма: сначала, используя класс XmlSchema из .Net, преобразовывал схему к промежуточному представлению в XML, а потом уже с помощью XSLT формировал код на Си++.
Здравствуйте, VladD2, Вы писали: ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык? VD>Тут в дотнете один орел рассказывал, что просто шарповские файл в качестве конфига использовал. Говорил что ооочень гибко. Вот только изврат все же и с безопасностью могут быть поблемы.
Здравствуйте, eao197, Вы писали:
E>Ну хотя бы то, что я начал использовать Curl-формат с 2001 года.
Ну и что? Я то говорю о теперешнем состоянии. Более того, в одном из топиков я специально упомянул о том, что все сказаное имеет отношение к вновь создаваемым проектам.
Здравствуйте, Sinclair, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. S>Тут мне буквально позавчера рассказывали про маньяков, которые парсили 60000 килобайт XML (само собой, приезжающего с клиента) в процедуре на MS SQL. И ничего, работает.
Я срашивал про то, как распарсить уже существующий XML. Тот, что лежит уже лежит в табличке (мне показалось, что написано про это было достаточно ясно — на всякий случай выделил жирным). Распарсить XML приезжающий с клиента — ума много не надо и, про это речь не идет.
TK>>Не набросаешь примерный код на T-SQL? S>Гм. А у нас разве статей на эту тему мало?
Гм. А можно точную ссылку? Мне тоже читать лень.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
ГВ>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>Они там не нужны. Это конфиг а не скриптовый файл.
А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
ГВ>>sic! Семантика Янусовых настроек легко аппроксимируется статичной структурой данных. eao197 приводит пример куда как более сложной ситуации. VD>IT тут правильно сказал, что товарищь слишком усложняет. Ну, да и условия можно приклеить на атрибутах. Вот только редактировать такой конфиг программно уже вряд ли удастся.
Вот в том-то и дело. Так что, всё зависит от способа использования. "Слишком" там усложнено или "не слишком" — вопрос второстепенный в данном случае.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinclair, Вы писали:
E>>>Следовательно, конфиги лучше писать на C#. S>>Ну, в частности именно такой выбор сделан в WinForms. В отличие от, например, Delphi, где форма описывается внешним ресурсом, в .Net форма сериализуется прямо в код.
VD>Вот в Авалоне МС уже забил на эту идею и использует банальный ХМЛ.
Тоже не панацея. Если у меня свой контрол, куда мне схему подавать для валидации, и ведь ее еще делать надо.
E>>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть. GZ>У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко.
Здравствуйте, Igor Sukhov, Вы писали:
E>>>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть. GZ>>У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко.
IS>клиенты = пользователи ?
IT отделы. Пользователя не стоит унижать такими подробностями как редактирование конфигурационного файла.
Здравствуйте, TK, Вы писали:
TK>Лучше тот, который выбран на основе конкретных use cases. Говорить же, что XML это серебряная пуля — не верно. Их не бывает.
А кто говорит о панацеях? Это банальность. Думать нужно всегда. Но тут речь о другом. Тут речь о наклепывании своих самопалов и полном забивании на стандартные решения. А прикрывается это особенностями использования. Хотя на поверку оказывается, что все же просто хотелось сделать велосипед.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, TK, Вы писали:
TK>За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно.
И что мешает скормить результат запроса хранимке или функции?
TK>хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT...
У меня на машине уже и MSSQL 2000 нет. Даже попробовать не на чем. Так что это к Мерлу. Думаю он тебе в два счета сбацает.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>CheckCsFile и MakePathLoverCase результат декомпозиции. Это часть кода класса вынесенная из больших функций при рефакторинге чтобы не загромождать код и упростить восприятие. CheckCsFile и MakePathLoverCase вещи сугобо спефические и тут им самое место.
Ш>Им самое место не в классе Compiler, а в коллекции свободных функций-утилит для работы с именами фоайлов.
С одной стороны их конечно можно было вынести в отдельный класс. Но бездумное запихивание всего в такие классы приводит к каши в них. В даном случае CheckCsFile спицифичен и использовать его где-то щее нельзя. Так что пусть он лучше останется скрытым методом в этом классе. В интерфейсе он не присуствует. Код не загромаждает (мелкий слишоком). MakePathLoverCase наверно можно было бы выносить смело. Но опять таки нигде больше он не нужен. А до тех пор заниматься его вынесением нет смысла. Пусть будет деталями реализации. В интерфейсе его опять женет.
VD>>GetProjectFiles вообще часть интерфейса класса. Класс используется в том числе и для загрузки проектов в визульных утилитах.
Ш>То же самое -- свободная функция-утилита для извлечения списка файлов из файла проекта.
А вот тут извини. Если два первых метода в общем-то по барабану где держать, то здесь вопрос уже идеологический. Этот меотод связан с этим классом логически. Человек использующий компилятор будет интуитивно искать этот метод именно в этом классе, а не черти знает где. В данном случае можно говорить только о вынесении реализации вынимания содержимого проектных файлов. Может это и стоит сделать. Но в интерфейсе данный метод просто обязан остаться. Иначе люди будут тратить время на писки или вообще наклпают свой вариант.
К тому же этот метод завязан (косвенно) на свойства компилятора. Венеси его и прийдется транслировать все их в другой класс. Повторно использовать этот код не нужно. Так что получается просто лишняя работа ради чистого искуства. Реальной декомпизиции при этом все равно не будет.
ЗЫ
В общем, конечно можно поспорить на счет того нужно выносить эти методы куда-то или нет. Но если сравнить этот класс с Синтилой, то не думаю, что он проиграет. Тут ПК уж явно пересторался.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, VladD2, Вы писали:
ГВ>>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>>Они там не нужны. Это конфиг а не скриптовый файл.
ГВ>А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
Какое правило? Ты что спросил? " И где там выражения" Где там? В Янвсе?
Вот тебе и ответили "Они там не нужны."
ГВ>Вот в том-то и дело. Так что, всё зависит от способа использования. "Слишком" там усложнено или "не слишком" — вопрос второстепенный в данном случае.
К сожалению не зависит. Просто берется и делается сапопал на каждый чих. Потом нчинается прикрывание способами использования, тем что ХМЛ мордой не вышел, парсеры не находятся, кокос не ростет.
Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, TK, Вы писали:
TK>>Лучше тот, который выбран на основе конкретных use cases. Говорить же, что XML это серебряная пуля — не верно. Их не бывает.
VD>Но тут речь о другом. Тут речь о наклепывании своих самопалов и полном забивании на стандартные решения. А прикрывается это особенностями использования. Хотя на поверку оказывается, что все же просто хотелось сделать велосипед.
Именно, что хотелось, т.к. формат уж больно понравился. И я до сих пор думаю, что для конфигов он удобнее, чем XML.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Нет, вопрос в том, как formatter десериализует объект, класса которого вообще нет в сборке на принимающей стороне? VD>Именно по этому я тебе и говорил, что тебе прийдется потратить год, чтобы изучить дотнет в той мере, чтобы не удивляться таким примитивным вещам.
VD>Если объяснять на пальцах, то все просто... Описание классов в сборках. Если нужно его прочесть, то сборка просто динамически подгружается. Далее форматер читает информацию и можепт поднять или сериализовать любой объект. Сам объект ему по большому барабану. А технология называется рефлекшон. VD>
Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>>>О! Началось. "Открой Янус, да посмотри!" (c) мой. И где там выражения (ну, хотя бы условные секции) в настройках? VD>>>Они там не нужны. Это конфиг а не скриптовый файл. ГВ>>А вот он и пойнт. "Не нужны" на самом деле означает: "Как правило, не нужны", а если ещё точнее, то "мне не не приходилось сталкиваться с...". Идея понятна?
VD>Какое правило? Ты что спросил? " И где там выражения" Где там? В Янвсе? VD>Вот тебе и ответили "Они там не нужны."
Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
VD>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай.
Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот. А то, что IT кажется, что eao197 "всё усложняет" — очень слабый аргумент.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Вся проблема в том, что как правило, закодировать саму сериализацию куда как проще, чем определиться с тем, что именно хранить, зачем хранить и как и когда читать/писать. А закодировано это в три строки или в десять — ну никакой разницы: ни в разработке, ни в сопровождении. VD>Да, я и не подумал, что у людей бывают стль серьезные проблемы.
Это и есть основные проблемы. Просто их принято не замечать.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
ГВ>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
E>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
А зачем тогда отправлять? Только ради того, чтобы отправить назад?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
ГВ>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять?
E>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать.
ГВ>А зачем тогда отправлять? Только ради того, чтобы отправить назад?
это необходимо.
Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
ГВ>>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять? E>>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать. ГВ>>А зачем тогда отправлять? Только ради того, чтобы отправить назад? E>Да, в случае с паттерном Async Completion Token
это необходимо.
Нет, не всё так просто. Сервер в общем случае ACT получает бинарные данные, которые и пуляет назад. Что они конкретно обозначают — знает только клиент. А приём/хранение/передача бинарных данных — это совсем не то же самое, что и структурированная [де-]сериализация.
E>Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте, либо он выполняет лишнюю десериализацию, поскольку ему может оказаться достаточным передать бинарные данные некоей длины, которая задана во входящем пакете.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
ГВ>>>>>Угу. Однако, eao197 задаёт только первую часть вопроса. Вторая часть есть логическое продолжение: "Ну, десериализовали, а дальше-то что Вы с этим намерены делать?" Обратно отправлять? E>>>>А кстати, правильно сериализовать и отправить обратно -- это тоже задача и иногда нужно ее решать. ГВ>>>А зачем тогда отправлять? Только ради того, чтобы отправить назад? E>>Да, в случае с паттерном Async Completion Token
это необходимо.
ГВ>Нет, не всё так просто. Сервер в общем случае ACT получает бинарные данные, которые и пуляет назад. Что они конкретно обозначают — знает только клиент. А приём/хранение/передача бинарных данных — это совсем не то же самое, что и структурированная [де-]сериализация.
Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
E>>Еще один случай, когда нужно сериализовать все обратно, это когда между клиентом и сервером устанавливается еще один компонент, про который ни клиент, ни сервер знать не должны. Такими компонентом может быть маршрутизатор (разные типы запросов на разные сервера), балансировщик нагрузки (выбор наименее загруженного сервера для обработки запроса), сборщик статистики (например, для on-line оценки наиболее популярных в данный момент запросов), файрвол (автоматически блокирует подозрительные запросы, например, платежные запросы с поддельными или украденными номерами карт). Такому компоненту может потребоваться десериализовать запрос, выполнить свою работу, а затем сериализовать и передать дальше.
ГВ>Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте,
Естественно что-то знает. Это только для load-balancer-а можно струтуру не знать. Но фишка в том, что промежуточный компонент может не знать всей структуры, а только то, что ему необходимо. И уж тем более ему можно не знать про расширения протокола, которые непосредственно его не касаются.
ГВ> либо он выполняет лишнюю десериализацию, поскольку ему может оказаться достаточным передать бинарные данные некоей длины, которая задана во входящем пакете.
Генадий, у меня складывается впечатление, что много недопонимания здесь возникает из-за того, что как бы неявно подразумевается, что:
— кто-то читает какой-то комуникационный канал (сокет или пайп);
— извлекает очередную порцию данных;
— тут же десериализует ее (т.е. имея исходный двоичный образ);
— после десериализации выполняет обработку и, если нужно, сериализует что-то в двоичный поток и куда-то пересылает.
И все это один и тот же объект.
Но это достаточно низкоуровневый подход. Можно же разбить эти операции на разные уровни:
— первый уровень контролирует канал и извлекает двоичные пакеты;
— следующий уровень проверяет, можно ли выполнить десериализацию и, если можно, десериализует их в прикладные сообщения;
— следующий уровень получае уже прикладное сообщение и обрабатывает его. В результате может быть сгенерированно другое прикладное сообщение;
— исходящее прикладное сообщение второй уровень сериализует в двоичный пакет;
— полученный исходящий двоичный пакет первый уровень пихает в канал.
(в принципе, это более-менее и есть верхние три уровня 7-ми уровневой модели).
Так вот предположим, что есть прикладное сообщение send_message (или make_payment для разнообразия). В нем должен быть идентификатор транзакции. В каком виде этот идентификатор будет присутствовать в send_message (make_payment)? В виде непрозрачного двоичного блока (читай std::string или std::vector<char>)? Но тогда инициатор сообщения должен сделать следующее:
взять свой исходный идентификатор;
сериализовать его в двоичный образ вручную;
поместить двоичный образ транзакции в send_message;
Аналогичные действия, но уже в обратном порядке инициатору сообщения нужно будет выполнить, чтобы десериализовать свой идентификатор из ответного сообщения.
На первый взгляд, это не сложные действия. Но их нужно делать вручную. Хотя можно сделать автоматически, если произвести все идентификаторы транзакций от общего базового класса и применить хитрую автоматическую схему сериализации. Тогда инициатору сообщения нужно будет всего лишь:
поместить исходный идентификатор транзации в send_message.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, TK, Вы писали:
TK>За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве TK>параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно.
Немного подумал... А что OPENXML, sp_xml_pretpare и переменные типа TEXT/NTEXT уже отменили? Тогда в чем проблема?
VD>>Это точно проще чем писать парсер собственного конфига на TSQL.
TK>хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT...
Почитай хэлп к OPENXML и sp_xml_pretpare. Думаю после этого ты такой пример и сам за пять минут сворганишь.
ЗЫ
Хотя конфиги в БД — это уже полный бред. Чем сама БД то не подходит?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>Но если сравнить этот класс с Синтилой, то не думаю, что он проиграет. Тут ПК уж явно пересторался.
Ш>Наверное. Но образцом проектирования он тоже не является.
ПК то привел его как бы в доказательство, что лучше чем в Синтиле не будет. Нашел в нем даже того чего там никогда не было (асс и диалоги открывает, и в "потроха" ассоциированных классов "лазит"). В общем, банальная попытка дискредитации.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
VD>>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай. ГВ>Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот.
Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее. Так вот я согласен, что может оказаться, что для какого-то частного случая ХМЛ будет хуже полностью уникального решения. Но надо же понимать, что это как раз и есть исключение, а не правило.
ГВ>А то, что IT кажется, что eao197 "всё усложняет" — очень слабый аргумент.
А мене тоже кажется, что усложняет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Да, я и не подумал, что у людей бывают стль серьезные проблемы.
ГВ>Это и есть основные проблемы. Просто их принято не замечать.
Ну, то есть, проблема в людях. Я то в общем, то эронизировал.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
VD>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
Цитату, пожалуйста.
VD>>>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай. ГВ>>Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот.
VD>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
Здравствуйте, eao197, Вы писали:
VD>>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
E>Найдешь время, загляни сюда: The Art of Unix Programming: Data File Metaformats, там таких паттернов 6 штук.
Все же XML несколько отличается остальных в лучшую сторону. Хотя бы потому, что его поддержка есть практически во всех языках и средах разработки. Для него даже специальные утилиты пишут. Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
Здравствуйте, Ракот, Вы писали:
Р>Здравствуйте, eao197, Вы писали:
VD>>>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
E>>Найдешь время, загляни сюда: The Art of Unix Programming: Data File Metaformats, там таких паттернов 6 штук.
Р>Все же XML несколько отличается остальных в лучшую сторону. Хотя бы потому, что его поддержка есть практически во всех языках и средах разработки. Для него даже специальные утилиты пишут.
Про XML здесь уже много чего сказано. Но еще раз проясню свою позицию, из-за которой я не считаю XML подходящим форматом для конфигурационных файлов (особенно небольших):
— конфиги часто правят люди. Часто не особенно подготовленные и сведующие в XML. Поэтому хочется иметь более читабельный формат, чем XML;
— библиотеки для разбора XML (libxml2, expat, xercer, tinyxml, ...) легко позволяют поднять XML в память в виде DOM-дерева. Но дальше из этого дерева значения все равно нужно преобразовать в какое-то внутреннее представление. И чем сложнее иерархическая структура, чем больше данных нужно преобразовывать из строкового представления в какое-то двоичное (числа, IP-адреса и т.д.), тем более сложным и запутаным в исходном тексте получается обход DOM-дерева (по крайней мере на такой Java-код я в свое время насмотрелся и больше не хочу с такими вещами сталкиваться). Поэтому я считаю, что должна быть библиотека, которая прозрачно преобразует значения из текстового представления конфига во внутрипрограммное представление.
Да, такую библиотеку можно, имхо, и на основе XML-я сделать. Но мне еще хотелось и большей читабельности, чем в XML. Поэтому я и взял за основу синтаксис языка Curl, т.к. в нем были специфицированны и комментарии, и строки, и целые (в двоичном, восьмеричном, десятичном и шестнадцатиричном представлении), и вещественные -- собственно, все что нужно.
Р> Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
Здравствуйте, eao197, Вы писали:
E>Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
Да, верно, как раз библиотека [де-]сериализации сможет именно что пропускать неизвестные ей структуры данных. Но это не означает, что мы "десериализуем неизвестный объект", мы просто "относимся к данным неизвестной структуры как к пакету (массиву, списку, ленте, набору...) бинарных данных". Разница тут очевидна: мы не пытаемся создать объект по его описанию, а просто откладываем такие данные и в случае необходимости отправляем их дальше as is.
Возвращаясь к сообщению Влада, замечу, что во-первых, он тебя несколько сбил с толку, а во-вторых, .Net таки да, может создать доселе неизвестный объект по данным, которые приедут по каналу сериализации, но вопрос "А зачем нам десериализовывать неизвестный объект?" остаётся открытым. Кстати, ты на него пусть и не совсем явно, но совершенно верно ответил: "а незачем!", так что, на самом деле, между нами противоречия нет.
Другими словами, техническая возможность для создания типа объекта по его сериализованному описанию есть, но вполне разумно поставить вопросы.
1. Имеет ли смысл выполнять операции по восстановлению внутренней структуры (доселе совершенно не известной получателю!), если единственное, зачем нужен такой объект — это снова упаковать его и отфутболить дальше? Под "восстановлением внутренней структуры" я имею ввиду создание описателя типа, создание экземпляра и т.п., а не размещение пропущенных данных, например, в динамической памяти.
2. Можно ли что-то сделать с восстановленным объектом на сервере, если by design этот объект нужен и известен только клиенту?
Ответы на оба вопроса — "нет".
ГВ>>Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте, E>Естественно что-то знает. Это только для load-balancer-а можно струтуру не знать. Но фишка в том, что промежуточный компонент может не знать всей структуры, а только то, что ему необходимо. И уж тем более ему можно не знать про расширения протокола, которые непосредственно его не касаются.
В точку.
Остальное комментировать не буду, поскольку в принципе со всем согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>- конфиги часто правят люди. Часто не особенно подготовленные и сведующие в XML. Поэтому хочется иметь более читабельный формат, чем XML;
Крайне субъективно. Лично мне XML кажется читабельнее.
E>- библиотеки для разбора XML (libxml2, expat, xercer, tinyxml, ...) легко позволяют поднять XML в память в виде DOM-дерева. Но дальше из этого дерева значения все равно нужно преобразовать в какое-то внутреннее представление. И чем сложнее иерархическая структура, чем больше данных нужно преобразовывать из строкового представления в какое-то двоичное (числа, IP-адреса и т.д.), тем более сложным и запутаным в исходном тексте получается обход DOM-дерева (по крайней мере на такой Java-код я в свое время насмотрелся и больше не хочу с такими вещами сталкиваться). Поэтому я считаю, что должна быть библиотека, которая прозрачно преобразует значения из текстового представления конфига во внутрипрограммное представление.
1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
2) Для дотнета и джавы есть стандартная реализация биндинга xml на классы. В просторечии это означает, что читать XML можно не в универсальный DOM, а в специализированную типизированную структуру.
E>Да, такую библиотеку можно, имхо, и на основе XML-я сделать.
Можно, но лучше воспользоваться готовым.
E> Но мне еще хотелось и большей читабельности, чем в XML.
Т.е. на самом деле это все еще п.1.
Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
А при чем здесь XPath?
AVK>2) Для дотнета и джавы есть стандартная реализация биндинга xml на классы. В просторечии это означает, что читать XML можно не в универсальный DOM, а в специализированную типизированную структуру.
E>>Да, такую библиотеку можно, имхо, и на основе XML-я сделать.
AVK>Можно, но лучше воспользоваться готовым.
E>> Но мне еще хотелось и большей читабельности, чем в XML.
AVK>Т.е. на самом деле это все еще п.1.
AVK>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
А по поводу субъективизма, то это, вероятно, самый главный аргумент. Ну вот не удобно мне XML-конфиги использовать (ни парсить, ни править, ни администраторов заставлять в них разбираться). Ну не удобно и все. Хоть тресни.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
E>>Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
ГВ>Да, верно, как раз библиотека [де-]сериализации сможет именно что пропускать неизвестные ей структуры данных. Но это не означает, что мы "десериализуем неизвестный объект", мы просто "относимся к данным неизвестной структуры как к пакету (массиву, списку, ленте, набору...) бинарных данных". Разница тут очевидна: мы не пытаемся создать объект по его описанию, а просто откладываем такие данные и в случае необходимости отправляем их дальше as is.
Ну не совсем так. Пусть, скажем есть иерархия:
class compression_mode_t { ... };
class zip_compression_t : public compression_mode_t { ... };
class zip_compression_with_desired_level_t : public zip_compression_t { ... };
Сериализуется объект zip_compression_with_desired_level_t, а десериализатор про него не знает. Но знает про zip_compression_t. Поэтому десериализатор может работать с составляющей из zip_compression_t, не зная даже про zip_compression_with_desired_level_t.
ГВ>Другими словами, техническая возможность для создания типа объекта по его сериализованному описанию есть, но вполне разумно поставить вопросы. ГВ>1. Имеет ли смысл выполнять операции по восстановлению внутренней структуры (доселе совершенно не известной получателю!), если единственное, зачем нужен такой объект — это снова упаковать его и отфутболить дальше? Под "восстановлением внутренней структуры" я имею ввиду создание описателя типа, создание экземпляра и т.п., а не размещение пропущенных данных, например, в динамической памяти.
Здесь я не был бы так категоричен. См. пример выше. В таких ситуациях структура объекта zip_compression_with_desired_level_t может быть как угодно большой и сложной, но мы сможем использовать из нее ту часть, которая относится к zip_compression_t. И именно такая иерархия (когда zip_compression_with... производится от zip_compression_t, а не от compression_mode_t) показывает, что идет "неограничивающее" расширение объекта, когда что-то новое, полезное добавляется, но не нарушается совместимость. Если же хочется добавить что-то, про что остальные знать не должны совсем, можно унаследоваться непосредственно от compression_mode_t. И тогда я согласен с тобой, ответ на этот вопрос "нет".
ГВ>Остальное комментировать не буду, поскольку в принципе со всем согласен.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
E>А при чем здесь XPath?
При его помощи можно делать выборки конкретных вещей, не бегая вручную по DOM. Пример тебе уже, кажется, приводили.
AVK>>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
E>Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
http://xml.apache.org/ — одна из наиболее навороченных реализаций приличного количества
XML-технологий. И на С++ в том числе. И xml binding для C++ тоже наверняка существует. Вот, сходу нашел http://tech-know-ware.com/lmx/
E>А по поводу субъективизма, то это, вероятно, самый главный аргумент.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
E>>А при чем здесь XPath?
AVK>При его помощи можно делать выборки конкретных вещей, не бегая вручную по DOM. Пример тебе уже, кажется, приводили.
Т.е. ты предлагаешь хранить в памяти весь DOM и по мере надобности дергать оттуда значения? В таком случае, имхо, просядет производительность.
А если извлекать из DOM все значения сразу, то, имхо, это будет то же самое, что и обход (особенно, если в XML есть списковые структуры), но только с помощью XPath.
AVK>>>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
E>>Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
AVK>http://xml.apache.org/ — одна из наиболее навороченных реализаций приличного количества AVK>XML-технологий. И на С++ в том числе. И xml binding для C++ тоже наверняка существует.
AVK> Вот, сходу нашел http://tech-know-ware.com/lmx/
(еще и платный )
Можно еще и gSOAP применить. Только у него другая идеология, от C++ структуры к XML.
E>>А по поводу субъективизма, то это, вероятно, самый главный аргумент.
AVK>Так и я о том же.
Так я и ни когда не скрывал
Более того, вопрос о том, имеют ли право на жизнь другие форматы конфигурационных файлов, кроме XML для меня остается открытым.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
V>>Тоже не панацея. Если у меня свой контрол, куда мне схему подавать для валидации, и ведь ее еще делать надо.
VD>В Авалоне все контролы "свои". Там ничего встроенного нет. Все живет по одинковой схеме.
Меня интересует момент — как мне проверить валидность моего XAML в отсутствии схемы на "свои" контролы?
Может, я там значения несуществующих св-в выставляю для какого-то контрола.
Здравствуйте, eao197, Вы писали:
VD>>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
E>Цитату, пожалуйста.
Здравствуйте, vdimas, Вы писали:
V>Меня интересует момент — как мне проверить валидность моего XAML в отсутствии схемы на "свои" контролы?
V>Может, я там значения несуществующих св-в выставляю для какого-то контрола.
Я копл не глубоко, но вроде как схемы генерируются. Да и компилятор есть. Так что все проверяется.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
VD>>>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
E>>Цитату, пожалуйста.
VD>Re[20]: Формат конфигов
Во-первых, ты нарушаешь хронологию событий. Пост, на который ты дал ссылку был сделан уже после того, как я попросил тебя дать цитату.
Во-вторых, где там слова "панацея", "универсальность" или даже "принципиально лучше"? Посмотри внимательно:
Но еще раз проясню свою позицию, из-за которой я не считаю XML подходящим форматом для конфигурационных файлов (особенно небольших):
Вот и все. На гегемонию XML я не покушался. Просто я считаю, что в данной конкретной области, на мой взгляд, XML не удобен. И поэтому применяю вместо него свой велосипед (уже четыре года).
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
[...] S>XML Schema позволяет сделать три вещи:
[...] S>2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации
Имеется в виду готовый типа XML Spy? Или в своей программе.
А не могли мы Вы поделиться опытом как Вы XML Schema деплоите (в случае внешнего редактора).
Я тут с этим разбираюсь и это кажется интересным вопросом.
Use case 1 — config file location is under application root:
<app root>/
<app data>/
1.xml
2.xml
schema.xsd
В 1.xml — все в порядке, нужен относительный путь:
...
uri:schemaLocation="urn:... ..\schema.xsd"
Use case 2 — config file location is not under application root:
В 1.xml — что писать в schemaLocation? Полный путь? А если приложение xcopy deployable и было перемещено? Это разрешимо — но интересно как вы делаете. Всегда копируете schema in the root of the data dir?
Здравствуйте, eao197, Вы писали:
E>Т.е. ты предлагаешь хранить в памяти весь DOM и по мере надобности дергать оттуда значения? В таком случае, имхо, просядет производительность.
На конфигах? Не смешите мои тапочки.
E>А если извлекать из DOM все значения сразу, то, имхо, это будет то же самое, что и обход (особенно, если в XML есть списковые структуры), но только с помощью XPath.
Не то же самое. На XPath получается значительно короче, и, что характерно, по большей части декларативно. Опять же на дотнете можно так:
Надеюсь ты уже понимаешь, что реализация Config.LoadData это один, макcимум два экрана кода, причем один раз.
AVK>> Вот, сходу нашел http://tech-know-ware.com/lmx/ E>(еще и платный )
Думается, если поискать, то и бесплатный найти можно. Впрочем платный в любом случае обойдется дешевле, нежели написание и поддержка своего парсера самостоятельно.
E>Более того, вопрос о том, имеют ли право на жизнь другие форматы конфигурационных файлов, кроме XML для меня остается открытым.
Все зависит от того насколько лояльно относится твой работодатель/заказчик к удовлетворению твоих эстетичеких чувств за свой (работодателя) счет.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Sinclair, Вы писали:
TK>>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. S>>Тут мне буквально позавчера рассказывали про маньяков, которые парсили 60000 килобайт XML (само собой, приезжающего с клиента) в процедуре на MS SQL. И ничего, работает.
TK>Я срашивал про то, как распарсить уже существующий XML. Тот, что лежит уже лежит в табличке (мне показалось, что написано про это было достаточно ясно — на всякий случай выделил жирным). Распарсить XML приезжающий с клиента — ума много не надо и, про это речь не идет.
TK>>>Не набросаешь примерный код на T-SQL? S>>Гм. А у нас разве статей на эту тему мало?
TK>Гм. А можно точную ссылку? Мне тоже читать лень.
Just for the record — эдесь. Вообще-то генерация SQL из SQL это экстремальная техника, но иногда помогает.
P.S. Еще из интересных:
1. Генерация SQL процедур/триггеров из бизнес логики при изменении бизнес правил.
2. Использование временной таблицы созданной в вызываемой процедуре в вызывающей.
Здравствуйте, mbergal, Вы писали:
M>Имеется в виду готовый типа XML Spy? Или в своей программе. M>А не могли мы Вы поделиться опытом как Вы XML Schema деплоите (в случае внешнего редактора). M>Я тут с этим разбираюсь и это кажется интересным вопросом.
Классический способ — в качестве xmlns указывается url (уникальный!). Например http://www.w3.org/2001/XMLSchema. А редактор позволяет сопоставить этот url конкретному файлу. Так, по крайней мере, работает и VS и IDEA.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Т.е. ты предлагаешь хранить в памяти весь DOM и по мере надобности дергать оттуда значения? В таком случае, имхо, просядет производительность.
AVK>На конфигах? Не смешите мои тапочки.
Андрей, наверное, дело в разных подходах. Мне, например, проще завести структуру, скажем, cfg_t, в которой хранятся настройки (как правило, это агрегат из других конфигурационных структур, поменьше), а затем использовать эту структуру в прикладном коде. А код парсинга конфигов сосредоточить в одном месте и выдавать наружу cfg_t. Тогда получается, что приложение совершенно не знает, где и как у меня хранятся конфиги. Что позволит, при желании, сменить реализацию конфигов.
Так вот имея чистый cfg_t я могу расчитывать, что извлечение из него параметров не ведет к лишним накладным расходам. В том числе и в участках кода, для которых важно быстродействие. Если же за cfg_t будет скрываться DOM-дерево, из которого XPath-ом что-то будет дергаться, то нужно ли мне будет учитывать быстродействие обращений к cfg_t? Или применять какие-то методики для его увеличения (скажем считывать значение через XPath только один раз)?
Так вот зачем мне об этом всем думать, если мой тупой однократный разбор конфига дает мне готовый cfg_t с минимальными издержками на его дальнейшее использование?
E>>А если извлекать из DOM все значения сразу, то, имхо, это будет то же самое, что и обход (особенно, если в XML есть списковые структуры), но только с помощью XPath.
AVK>
AVK>Надеюсь ты уже понимаешь, что реализация Config.LoadData это один, макcимум два экрана кода, причем один раз.
Да, понимаю.
Только, имхо, здесь есть два недостатка.
Первый касается собственно конфигов. Такая декларативность усложняет копирование кода из одного проекта в другой. Вот буквально перед получением твоего письма я скопировал класс authentification_cfg_t и класс для его парсинга tag_authentification_cfg_t в из одного проекта в другой. И мне ничего не пришлось менять вообще, даже не смотря на то, что в новом проекте тег {authentification} располагается в конфиге совсем в другом месте (имеет другой путь доступа). В твоем же варианте мне придется поменять декларации:
Далее, как будет выглядеть такая декларативность, если в конфиге нужно будет иметь несколько тегов для some-class с разными именами? Скажем /config/main-widget, /config/auth-widget, /config/confirmation-widget? А если эти теги должны будут образовывать списковую структуру (вспомни пример про Shortcat-ы из редактора Влада)? Хорошо ли прописывать фиксированный путь в классе, экземпляров которого в программе будет несколько?
Ну и второй недостаток связан с тем, что, имхо, такое обилие атрибутов сильно смахивает на злоупотребление макросами в C/C++. Там ведь также создается язык над языком. Который не только поддерживать и развивать нужно. Но и в который приходится въезжать новым разработчикам. Но это так, мысли в слух, да и оффтопик.
E>>Более того, вопрос о том, имеют ли право на жизнь другие форматы конфигурационных файлов, кроме XML для меня остается открытым.
AVK>Все зависит от того насколько лояльно относится твой работодатель/заказчик к удовлетворению твоих эстетичеких чувств за свой (работодателя) счет.
Без проблем
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mbergal, Вы писали:
M>>Имеется в виду готовый типа XML Spy? Или в своей программе. M>>А не могли мы Вы поделиться опытом как Вы XML Schema деплоите (в случае внешнего редактора). M>>Я тут с этим разбираюсь и это кажется интересным вопросом.
AVK>Классический способ — в качестве xmlns указывается url (уникальный!). Например http://www.w3.org/2001/XMLSchema.
или просто urn:
AVK>А редактор позволяет сопоставить этот url конкретному файлу. Так, по крайней мере, работает и VS и IDEA.
А можете описать этот процесс в VS2003? Я, честно говоря, простого способа сделать это в VS2003 не знаю. А global register — urn <-> file не всегда удобен (use case: при модификации схемы я не всегда меняю urn, а у QA на машине может стоять несколько build'ов).
[...]
AVK>Не то же самое. На XPath получается значительно короче, и, что характерно, по большей части декларативно. Опять же на дотнете можно так: AVK>
Интересно, но на кучу вопросов в приведенном виде не отвечает . Есть ли что-нибудь поподробнее про чтение/запись конфигов в XML. Или какие-нибудь ссылки на существующий код/библиотеку. Спасибо.
Здравствуйте, mbergal, Вы писали:
M>Интересно, но на кучу вопросов в приведенном виде не отвечает . Есть ли что-нибудь поподробнее про чтение/запись конфигов в XML. Или какие-нибудь ссылки на существующий код/библиотеку. Спасибо.
Здравствуйте, eao197, Вы писали:
E>Андрей, наверное, дело в разных подходах. Мне, например, проще завести структуру, скажем, cfg_t, в которой хранятся настройки (как правило, это агрегат из других конфигурационных структур, поменьше), а затем использовать эту структуру в прикладном коде. А код парсинга конфигов сосредоточить в одном месте и выдавать наружу cfg_t. Тогда получается, что приложение совершенно не знает, где и как у меня хранятся конфиги. Что позволит, при желании, сменить реализацию конфигов.
Подходы могут быть разными. Тот, о котором ты говоришь, прекрасно реализуется xml байндингом. А я тебе продемонстрировал и другой подход с использованием XPath. Другой, потому что реализовывать на XPath первый подход просто глупо. Сам я таким не пользуюсь.
E>Если же за cfg_t будет скрываться DOM-дерево, из которого XPath-ом что-то будет дергаться, то нужно ли мне будет учитывать быстродействие обращений к cfg_t? Или применять какие-то методики для его увеличения (скажем считывать значение через XPath только один раз)?
Если ты внимательно посмотрел на приведенный код, то наверняка заметил что обращение к XPath идет только в конструкторе. Если класс часто создается, то можно перенести в статический конструктор. Если нужно отслеживать изменения конфигов в процессе работы, то там же заводишь файлвотчер и/или проверяющий поток и перечитываешь данные при изменении файла.
E>Так вот зачем мне об этом всем думать, если мой тупой однократный разбор конфига дает мне готовый cfg_t с минимальными издержками на его дальнейшее использование?
Видишь ли — я ведь тебе не приводил готовый код. Это просто пример специально предельно упрощенный. Если ты на него посмотришь с такой стороны, то сам прекрасно расскажешь как сделать так как тебе хочется.
E>Первый касается собственно конфигов. Такая декларативность усложняет копирование кода из одного проекта в другой. Вот буквально перед получением твоего письма я скопировал класс authentification_cfg_t и класс для его парсинга tag_authentification_cfg_t в из одного проекта в другой. И мне ничего не пришлось менять вообще, даже не смотря на то, что в новом проекте тег {authentification} располагается в конфиге совсем в другом месте (имеет другой путь доступа). В твоем же варианте мне придется поменять декларации: E>
Блин, ну опять ты примитивный пример рассматриваешь как готовое решение. Я привел идею использования XPath для конфигов, а не реализацию. Вот тебе сразу навскидку:
[ConfigRoot("/another-root/some-class")]
class SomeClass
{
[FromConfig("/@color")]
private bool _color;
}
E>Далее, как будет выглядеть такая декларативность, если в конфиге нужно будет иметь несколько тегов для some-class с разными именами? Скажем /config/main-widget, /config/auth-widget, /config/confirmation-widget?А если эти теги должны будут образовывать списковую структуру (вспомни пример про Shortcat-ы из редактора Влада)? Хорошо ли прописывать фиксированный путь в классе, экземпляров которого в программе будет несколько?
Все это решаемо при желании.
E>Ну и второй недостаток связан с тем, что, имхо, такое обилие атрибутов сильно смахивает на злоупотребление макросами в C/C++.
Это от непривычки, атрибуты, в отличие от макросов, синтаксические конструкции и проверяются и компилятором и рантаймом. И это еще не обилие . Вот например:
[JanusDisplayName(SR.Config.IconSize.DisplayNameResourceName)]
[JanusDescription(SR.Config.IconSize.DescriptionResourceName)]
[JanusCategory(_categoryNameCommon)]
[ChangeProperty(ChangeActionType.Restart)]
[DefaultValue(ToolbarImageSize.Size24)]
[SortIndex(50)]
public ToolbarImageSize SizeImageToolBar
{
get { return _imgToolBar; }
set { _imgToolBar = value; }
}
И никаких проблем, сходных с макросами это не вызывает.
Здравствуйте, mbergal, Вы писали:
AVK>>Классический способ — в качестве xmlns указывается url (уникальный!). Например http://www.w3.org/2001/XMLSchema. M>или просто urn:
Можно, но тогда сложнее гарантировать уникальность.
AVK>>А редактор позволяет сопоставить этот url конкретному файлу. Так, по крайней мере, работает и VS и IDEA.
M>А можете описать этот процесс в VS2003? Я, честно говоря, простого способа сделать это в VS2003 не знаю.
Он простой, но кривой. Берется xsd-файл и помещается в каталог <VS Root>\Common7\Packages\schemas\xml\.
M> А global register — urn <-> file не всегда удобен (use case: при модификации схемы я не всегда меняю urn, а у QA на машине может стоять несколько build'ов).
Ну так тут тебе вряд ли кто помочь сможет, поскольку твоей кухни никто не знает. Придумывай способ, по которому можно добраться до конкретной схемы и обеспечивай регистрацию с учетом конкретной версии. Например ввиде некоего аналога дотнетовского GAC.
Здравствуйте, eao197, Вы писали:
Р>>Все же XML несколько отличается остальных в лучшую сторону. Хотя бы потому, что его поддержка есть практически во всех языках и средах разработки. Для него даже специальные утилиты пишут.
E>Про XML здесь уже много чего сказано. Но еще раз проясню свою позицию, из-за которой я не считаю XML подходящим форматом для конфигурационных файлов (особенно небольших): E>- конфиги часто правят люди. Часто не особенно подготовленные и сведующие в XML. Поэтому хочется иметь более читабельный формат, чем XML;
Вот это я и считаю не правильным. Если изначально придумали бы единый стандарт (к чему сейчас и идут с помощью Xml), то 100% в поддержку ОС входил некая утилита, позволяющее конфигурировать любое приложение. Но этого не придумали. И мы получили NT сервисы, которые практически не конфигурируются (или нужно ручками подвравлять в реестре). Мы получили оснастки MMC, который разрабатывать сложнее, чем написать свою собственную программу конфигурирования.
Нужна единая программа, с помощью которой можно конфигурировать приложения. Пользователю не очень удобно в новой программе изучать формат конфигурирования, точно как и сам графический интерфейс. Да и разработчику тоже не интересно писать соответсвующую программу (если только он этим не занимается профессионально ).
И еще одно мнение. Xml читается намного лучше, чем INI. Может это я так просто привык, но вложенность настроек в Xml можно увидеть практически сразу, чем это будет представлено в другом формате. Такова уж особенность языков разметки
E>- библиотеки для разбора XML (libxml2, expat, xercer, tinyxml, ...) легко позволяют поднять XML в память в виде DOM-дерева. Но дальше из этого дерева значения все равно нужно преобразовать в какое-то внутреннее представление. И чем сложнее иерархическая структура, чем больше данных нужно преобразовывать из строкового представления в какое-то двоичное (числа, IP-адреса и т.д.), тем более сложным и запутаным в исходном тексте получается обход DOM-дерева (по крайней мере на такой Java-код я в свое время насмотрелся и больше не хочу с такими вещами сталкиваться). Поэтому я считаю, что должна быть библиотека, которая прозрачно преобразует значения из текстового представления конфига во внутрипрограммное представление.
Не уверен насчет других языков, но в .NET это есть и давно. Хотя в данном случае не совсем понятно, чем будет выгоднее использовать, например, INI файл. Разве там сразу создаются объекты языка программирования?
E>Да, такую библиотеку можно, имхо, и на основе XML-я сделать. Но мне еще хотелось и большей читабельности, чем в XML. Поэтому я и взял за основу синтаксис языка Curl, т.к. в нем были специфицированны и комментарии, и строки, и целые (в двоичном, восьмеричном, десятичном и шестнадцатиричном представлении), и вещественные -- собственно, все что нужно.
Я тебя сейчас удивлю, но в Xml это все есть с самого начала. А вот что бывает действительно сложно для конфигурационных форматов, так это представления произвольных данных, который нужно выделять в особые границы. В Xml — это CDATA.
Р>> Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
E>По поводу Record-Jar ты не прав: Re: сохранение настроек в ini файл
Согласен. Только поддержку Xml С++ имеет в гораздо более широком инструментации. Указанный тобою проект умеет читать Xml не ввиде DOM, а через SAX?
E>Да и запись/чтение ini-файлов из C++ врядли представляет сложность даже вручную. Не говоря уже про возможность найти готовую библиотеку для этого.
Можно все сделать самому или найти это со стороны. Вот только при таком подхоже могут возникнуть два простых вопроса: "как все это будет работать?" и "зачем это нужно, если есть стандартное решение?".
Здравствуйте, AndrewVK, Вы писали:
E>>Так вот зачем мне об этом всем думать, если мой тупой однократный разбор конфига дает мне готовый cfg_t с минимальными издержками на его дальнейшее использование?
AVK>Видишь ли — я ведь тебе не приводил готовый код. Это просто пример специально предельно упрощенный. Если ты на него посмотришь с такой стороны, то сам прекрасно расскажешь как сделать так как тебе хочется.
Андрей, похоже, что меня тут пытаются научить тому "как правильней" для случая, когда я уже давно использую свое решение и не о чем не парюсь. Не то, чтобы это меня злило или няпрягало. Мне, наоборот интересно.
Просто для моего случая с C++ я никак не могу найти смысла во всех этих наворотах кроме того, что XML -- это стандарт и т.д и т.п. Ну стандарт. Ктож спорит-то.
Вот в области объектных БД был стандарт ODMG. Был, и разработчики БД пыхтели, чтобы его поддержать. Побыл да и сплыл. А объектные базы как были так и остались. Я это к тому, что конфиги были есть и будут. XML есть. Пока. Будет ли он и дальше в области конфигов? Для Java/C# -- очень вероятно. Для Ruby это уже сейчас не так. Для C++ вопрос открыт.
E>>Первый касается собственно конфигов. Такая декларативность усложняет копирование кода из одного проекта в другой. Вот буквально перед получением твоего письма я скопировал класс authentification_cfg_t и класс для его парсинга tag_authentification_cfg_t в из одного проекта в другой. И мне ничего не пришлось менять вообще, даже не смотря на то, что в новом проекте тег {authentification} располагается в конфиге совсем в другом месте (имеет другой путь доступа). В твоем же варианте мне придется поменять декларации: E>>
E>>Далее, как будет выглядеть такая декларативность, если в конфиге нужно будет иметь несколько тегов для some-class с разными именами? Скажем /config/main-widget, /config/auth-widget, /config/confirmation-widget?А если эти теги должны будут образовывать списковую структуру (вспомни пример про Shortcat-ы из редактора Влада)? Хорошо ли прописывать фиксированный путь в классе, экземпляров которого в программе будет несколько?
AVK>Все это решаемо при желании.
Так ведь нет желания еще раз решать все тоже самое.
E>>Ну и второй недостаток связан с тем, что, имхо, такое обилие атрибутов сильно смахивает на злоупотребление макросами в C/C++.
AVK>Это от непривычки, атрибуты, в отличие от макросов, синтаксические конструкции и проверяются и компилятором и рантаймом. И это еще не обилие . Вот например: AVK>
AVK>И никаких проблем, сходных с макросами это не вызывает.
Имхо, как раз здесь болезнь макросов и проявляется -- тот, кто писал обработчики этих атрибутов, в них прекрасно разбирается. А вот как насчет всех остальных?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
[...]
M>>А можете описать этот процесс в VS2003? Я, честно говоря, простого способа сделать это в VS2003 не знаю.
AVK>Он простой, но кривой. Берется xsd-файл и помещается в каталог <VS Root>\Common7\Packages\schemas\xml\.
Это не кажется мне простым в смысле "простым для меня и наших QA" (по пользователей речи не веду — у них Visual Studio .NET). Для меня лучше работает второй способ с Visual Studio ->включить .xsd в проект, но у него есть свои проблемы.
M>> А global register — urn <-> file не всегда удобен (use case: при модификации схемы я не всегда меняю urn, а у QA на машине может стоять несколько build'ов).
AVK>Ну так тут тебе вряд ли кто помочь сможет, поскольку твоей кухни никто не знает. Придумывай способ, по которому можно добраться до конкретной схемы и обеспечивай регистрацию с учетом конкретной версии. Например ввиде некоего аналога дотнетовского GAC.
Да чего ее придумывать то, придумать то я уже придумал, но все самому-то делать и шишки набивать не очень хочется. Хочется воспользоваться чьим-то опытом. А сейчас — наваливается проблем как-то слишком много для такого простого топика. Везде думать надо. Итак уже достаточно много времени на изучение этого всего. А я еще даже до чтения/записи не дошел.
Здравствуйте, Ракот, Вы писали:
Р>Нужна единая программа, с помощью которой можно конфигурировать приложения. Пользователю не очень удобно в новой программе изучать формат конфигурирования, точно как и сам графический интерфейс. Да и разработчику тоже не интересно писать соответсвующую программу (если только он этим не занимается профессионально ).
А еще нужна одна аппаратная платформа, одна ОС, один язык программирования
Р>И еще одно мнение. Xml читается намного лучше, чем INI. Может это я так просто привык, но вложенность настроек в Xml можно увидеть практически сразу, чем это будет представлено в другом формате. Такова уж особенность языков разметки
А Curl, имхо, читается еще лучше, даже без синтаксической подсветки и навороченных редакторов. И все из-за того, что в закрывающем теге имя тега не дублируется
Р>>> Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
E>>По поводу Record-Jar ты не прав: Re: сохранение настроек в ini файл
Р>Согласен. Только поддержку Xml С++ имеет в гораздо более широком инструментации. Указанный тобою проект умеет читать Xml не ввиде DOM, а через SAX?
Насколько я помню, указанный мной проект вообще не умеет читать XML. Мы вообще про что сейчас?
E>>Да и запись/чтение ini-файлов из C++ врядли представляет сложность даже вручную. Не говоря уже про возможность найти готовую библиотеку для этого.
Р>Можно все сделать самому или найти это со стороны. Вот только при таком подхоже могут возникнуть два простых вопроса: "как все это будет работать?"
Нормально.
Р> и "зачем это нужно, если есть стандартное решение?".
Вот объясни мне, неразумному, такую штуку. Мне нужно схранить в конфигурации значения:
Каким стандартом XML эта конфигурация будет описываться?
Скажешь глупый вопрос? Что XML -- это стандарт языка разметки?
Так вот в этом-то все и дело. XML стандартизирует только синтаксис. А уже все мои выверты внутри XML никак уж стандартами не будут. И если этот конфиг кто-то захочет сам прочитать, то ему придется разбираться в моем нестандартном решении все равно. Просто проблем с синтаксисом не будет. Так что, цель в том, чтобы проблем с синтаксисом не было?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, mbergal, Вы писали:
[...] M>Это не кажется мне простым в смысле "простым для меня и наших QA" (по пользователей речи не веду — у них нет Visual Studio .NET).
Здравствуйте, mbergal, Вы писали:
AVK>>Он простой, но кривой. Берется xsd-файл и помещается в каталог <VS Root>\Common7\Packages\schemas\xml\.
M>Это не кажется мне простым в смысле "простым для меня и наших QA" (по пользователей речи не веду — у них Visual Studio .NET).
Ну это уже косяки студии. В IDEA все намного понятнее и проще.
M>Для меня лучше работает второй способ с Visual Studio ->включить .xsd в проект, но у него есть свои проблемы.
Ага, иногда она его игнорирует. В каталог проще и надежнее, особенно если это делает инсталлятор.
Здравствуйте, eao197, Вы писали:
AVK>>Видишь ли — я ведь тебе не приводил готовый код. Это просто пример специально предельно упрощенный. Если ты на него посмотришь с такой стороны, то сам прекрасно расскажешь как сделать так как тебе хочется.
E>Андрей, похоже, что меня тут пытаются научить тому "как правильней" для случая, когда я уже давно использую свое решение и не о чем не парюсь. Не то, чтобы это меня злило или няпрягало. Мне, наоборот интересно.
Никто тебя персонально научить не пытается. Скорее всего это просто невозможно. Я пытаюсь показать тем, кто пока не имеет собственного мнения то, что использовать в настоящее время для конфига самопальный формат нужно только в очень особых случаев.
E>Просто для моего случая с C++ я никак не могу найти смысла во всех этих наворотах кроме того, что XML -- это стандарт и т.д и т.п. Ну стандарт. Ктож спорит-то.
Я вобще то в поледних топиках даже слово "стандарт" не употреблял. Я указывал лишь на то, что XML сопутствует целый ряд технологий, которые уже реализованы.
AVK>>Все это решаемо при желании.
E>Так ведь нет желания еще раз решать все тоже самое.
Это тебе. А я устал уже напоминать что речь идет о новых проектах.
E>Имхо, как раз здесь болезнь макросов и проявляется -- тот, кто писал обработчики этих атрибутов, в них прекрасно разбирается. А вот как насчет всех остальных?
Тоже на практике никаких проблем не было. Вероятность применить неправильно атрибут точно такая же, как и неправильное применение библиотечного класса.
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, mbergal, Вы писали:
M>>Интересно, но на кучу вопросов в приведенном виде не отвечает . Есть ли что-нибудь поподробнее про чтение/запись конфигов в XML. Или какие-нибудь ссылки на существующий код/библиотеку. Спасибо.
OE>http://gzip.rsdn.ru/?article/dotnet/dnetappcfg.xml
Ну вот, наконец-то, у меня все стало на свои места.
E>>Андрей, похоже, что меня тут пытаются научить тому "как правильней" для случая, когда я уже давно использую свое решение и не о чем не парюсь. Не то, чтобы это меня злило или няпрягало. Мне, наоборот интересно.
AVK>Никто тебя персонально научить не пытается. Скорее всего это просто невозможно.
Здесь ты ошибаешься
Меня трудно убедить в том, что я не прав, особенно, если я действительно не прав Но возможно.
Кстати, про XSLT и XPath я так и остался на своих позициях, а вот XSD -- это уже интереснее.
AVK>Я пытаюсь показать тем, кто пока не имеет собственного мнения то, что использовать в настоящее время для конфига самопальный формат нужно только в очень особых случаев.
Так же им нужно посоветовать не обращать внимания на другие форматы, отличные от XML. И не браться за проекты, в которых эти форматы используются.
Если серьезно, то изобретение велосипедов -- это неблагодарное занятие, за исключением тех случаев, когда велосипеды становятся мейнстримом (как, например, Linux, apache или svn). Поэтому если нет тяги к изобретательству и набиванию шишек, то не нужно изобретать самопальных форматов. Здесь я с Андреем полностью согласен.
А если тяга есть, то разумные доводы нас, велосипедистов, все равно не остановят.
E>>Так ведь нет желания еще раз решать все тоже самое.
AVK>Это тебе. А я устал уже напоминать что речь идет о новых проектах.
И начинаемых не мной проектов. Поскольку я свои новые проекты начинаю с copy&paste больших объемов из старых проектов. Поэтому и продолжаю свой формат использовать.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
ГВ>>Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197? VD>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
А почему нет? Если его решение накрывает наиболее часто встречающиеся use cases для XML-конфигов, плюс даёт дополнительные бенефиты в виде удобочитаемости, то... ну, если и не панацея, то во всяком случае — удачная альтернатива в некоторых случаях.
VD>>>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай. ГВ>>Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот. VD>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн.
Где об этом написано? А во-вторых, ты путаешь понятия "паттерн" и "устоявшееся решение на базе нужное-вписать". Тут уж, скорее, дело в том, что XML является ближайшим аналогом иерархических БД, в которых удобно хранить деревья настроечных параметров. Ну так появится какой-нибудь новый движок, который будет хранить свои данные в иерархической БД и — привет XML-ю.
VD>Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
Правомерность этого обобщения тоже вызывает сомнения. Выгоднее по каким критериям?
Сложность задачи хранения настроечных данных от времени, эпохи и пр. не зависит. Скорее это зависит от того, что именно хочется хранить. Или ты правда думаешь, что аналог Янусовых настроек нельзя на .ini-файле сделать? Собственно, .ini-файл даёт всё необходимое для хранения любых именованных данных. Единственный недостаток — одноуровневая группировка параметров. Зато у XML недостатков — пруд пруди. Начиная с тяжеловесных парсеров и заканчивая его чувствительностью к синтаксической корректности, ergo — усложнением редактирования.
VD>Так вот я согласен, что может оказаться, что для какого-то частного случая ХМЛ будет хуже полностью уникального решения. Но надо же понимать, что это как раз и есть исключение, а не правило.
Для того, чтобы можно было принять тезис о том, что "надо же понимать...", надо бы сначала доказать то, что надо понимать. Я согласен, что хранить настройки в XML может быть удобно в ряде случаев, но вот делать далекоидущие выводы о "правиле"...
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Ракот, Вы писали:
Р>Вот это я и считаю не правильным. Если изначально придумали бы единый стандарт (к чему сейчас и идут с помощью Xml), то 100% в поддержку ОС входил некая утилита, позволяющее конфигурировать любое приложение.
Не выйдет. Не выйдет потому, что кроме самой по себе задачи чтения/изменения/записи параметров есть ещё и задача поддержки согласованности настроек.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
В общем-то, я опять в основном согласен с твоим постингом, за исключением одного момента. Ты подмешиваешь ещё одно действие — интерпретацию бинарных данных, как объект некоторого известного серверу типа. То есть, по сути, никакого "неизвестного" объекта не создаётся — всё известно и детерминировано.
E>
+1
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
TK>>За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве TK>>параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно. VD>Немного подумал... А что OPENXML, sp_xml_pretpare и переменные типа TEXT/NTEXT уже отменили? Тогда в чем проблема?
переменные типа TEXT/NTEXT могут выступать только в качестве аргумента. Объявить ее в теле хранимой процедуры нельзя.
VD>>>Это точно проще чем писать парсер собственного конфига на TSQL.
TK>>хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT... VD>Почитай хэлп к OPENXML и sp_xml_pretpare. Думаю после этого ты такой пример и сам за пять минут сворганишь.
+1. Читал?
VD>ЗЫ
VD>Хотя конфиги в БД — это уже полный бред. Чем сама БД то не подходит?
Я и не призываю к этому. Просто говорить о том, что в MS SQL 2000 есть нормальная поддержка XML не совсем верно. Она там скорее номинальная...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>переменные типа TEXT/NTEXT могут выступать только в качестве аргумента. Объявить ее в теле хранимой процедуры нельзя.
А что они тебе дались? 8 Кб это тоже не мало. Можно и простой строкой воспользоваться. VD>>Почитай хэлп к OPENXML и sp_xml_pretpare. Думаю после этого ты такой пример и сам за пять минут сворганишь.
TK>+1. Читал?
И что не устраивает.
TK>Я и не призываю к этому. Просто говорить о том, что в MS SQL 2000 есть нормальная поддержка XML не совсем верно. Она там скорее номинальная...
Ну, не супер, но все же лучше чем придумывать свои стандарты на Курловсоком синтаксисе.
ЗЫ
Хотя конечно это все извращения. В СУБД для хранения информации лучше использовать БД. А для обработки SQL.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> Хотя конечно это все извращения. В СУБД для хранения информации лучше использовать БД. А для обработки SQL.
Такая точка зрения уже прозвучала в виде предложения элиминировать конфиг в Янусе в пользу хранения соответствующей информации прямо в базе. Контраргументы — там же.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> Хотя конечно это все извращения. В СУБД для хранения информации лучше использовать БД. А для обработки SQL.
ПК>Такая точка зрения уже прозвучала в виде предложения элиминировать конфиг в Янусе в пользу хранения соответствующей информации прямо в базе. Контраргументы — там же.
А с каких пор Янус стал СУБД?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
>>> Хотя конечно это все извращения. В СУБД для хранения информации лучше использовать БД. А для обработки SQL.
> ПК>Такая точка зрения уже прозвучала в виде предложения элиминировать конфиг в Янусе в пользу хранения соответствующей информации прямо в базе. Контраргументы — там же.
> А с каких пор Янус стал СУБД?
Тогда я тебя, пожалуй не понял. В таком случае, что ты имел в виду под "В СУБД для хранения информации лучше использовать БД"? Я тебя так понял, что речь шла о приложениях, построенных вокруг базы данных, к каковым Янус, на мой взгляд, вполне относится. Если речь о самих СУБД, то, имхо, реплика в контексте дискуссии вообще особого смысла не имеет, т.к. о написании СУБД речи не было...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Тогда я тебя, пожалуй не понял.
Да уж. Иначе это уже издевательство.
ПК>В таком случае, что ты имел в виду под "В СУБД для хранения информации лучше использовать БД"? Я тебя так понял, что речь шла о приложениях, построенных вокруг базы данных, к каковым Янус, на мой взгляд, вполне относится.
Речь шала о коде внутри СУБД. Например, триггере или хранимой процедуре в MSSQL. Я говорил о том, что конфиги в таких местах — это не очень разумное решение и что для хранения настроек в таких условиях действительно разумнее использовать саму БД.
ПК>Если речь о самих СУБД,
Вот как раз настройки для СУБД как приложения уже лучше хранить в одтельном файле.
ПК>то, имхо, реплика в контексте дискуссии вообще особого смысла не имеет, т.к. о написании СУБД речи не было...
Я балдю с твоего формализма.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
* thriving in a production environment *
