Здравствуйте, vladrsdn, Вы писали:

V>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.

я сам себе потихоньку, по-мере надобности, в стиле описанном здесь

Автор: Vamp
Дата: 26.11.08

,
пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

Здравствуйте, 8bit, Вы писали:

8>Здравствуйте, vladrsdn, Вы писали:
V>>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.
8>я сам себе потихоньку, по-мере надобности пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, 8bit, Вы писали:

8>>Здравствуйте, vladrsdn, Вы писали:
V>>>Так и надо делать кросс-платформенные проги. При правильном проектировании и реализации, 95% кода будут собираться и одинаково работать на винде-юниксе-макоси. Оставшиеся 5% кода пишем под каждую платформу на ее родных тулкитах или пользуем кросс-платформенное WxWidgets/Qt. Не надо, как 95% программистов-подоконников, открывать и читать файлы через CreateFile/ReadFile или MFC классы, есть кросс-платформенные fopen/fread или их С++ аналоги.
8>>я сам себе потихоньку, по-мере надобности пишу platform abstraction layer, и через него все и делаю. Вот видимо скоро под *nix дополню её...

А>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

Здравствуйте, vladrsdn, Вы писали:

А>>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

V>не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

А>>>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

А>>>Может уже пора объединяться в этом направлении и кое-что выкладывать на RSDN ?

V>>не изобретайте глючный велосипед — возьмите nspr от мозиллы — она под lgpl (то есть ее можно линковать динамически к коммерческому коду) — там файлы — сеть и сокеты — процессы -треды и еще дохрена всего.

А>Так я ничего не изобретаю. Обёртки, это всего лишь свой собственный набор удобных названий функций и классов + чистые алгоритмы. А библиотеку можно прикрутить любую.

Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

Здравствуйте, vladrsdn, Вы писали:

V>Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

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

Посмотрите на PHP — он выигрывает за счёт удобства обёрток. Ими очень легко, удобно пользоваться. Всё интуитивно понятно. А ведь почти все PHP библиотеки сишные! Почему бы не сделать то же самое на C++ ?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

V>>Тогда нечего выкладывать на rsdn — у каждого свои предпочтения к названиям классов и ф-ий. Тем более никто не будет писать нормальные доки ко своим оберткам. Нефига плодить энтропию.

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

А>Посмотрите на PHP — он выигрывает за счёт удобства обёрток. Ими очень легко, удобно пользоваться. Всё интуитивно понятно. А ведь почти все PHP библиотеки сишные! Почему бы не сделать то же самое на C++ ?

Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом! Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

Здравствуйте, Аноним, Вы писали:

А>Угу. Я тоже вдохновился этой идеей с подачи одного шароварщика с USENET, и с 2008 года начал писать набор простых C++ классов-обёрток для platform abstraction layer. Хорошие рекомендации по этому поводу собраны здесь: https://developer.mozilla.org/En/C___Portability_Guide

Прежде, чем писать что-то свое, есть смысл посмотреть на уже готовое. Например, Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE.

Последние две — это больше, чем pirtable runtime, но он туда включен.

Здравствуйте, Pzz, Вы писали:

Еще можно poco добавить.
Но своя рубаха ближе

Здравствуйте, vladrsdn, Вы писали:

V>Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом!

Тем не менее, в PHP есть интересные процедуры, которых не хватает в стандартных библиотеках C++.

V>Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

Имена функций мне вообще больше нравятся с заглавных букв -- в стиле Microsoft. Например, MessageBox читать намного удобнее чем message_box.

V>Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

Поэтому этот вопрос необходимо решать коллективно — через ресурсы и форумы RSDN, чтобы не было как вы говорите "на скорую руку" и "каждым под себя". Возможно кое-что следует позаимствовать из обёрток запроектированных в .NET, хотя и там далеко не всё идеально.

Если заняться этим серьёзно — очень многое можно реально упростить.

Здравствуйте, Pzz, Вы писали:

Pzz>Прежде, чем писать что-то свое, есть смысл посмотреть на уже готовое. Например, Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE.
Pzz>Последние две — это больше, чем pirtable runtime, но он туда включен.

Речь идёт о создании унифицированного качественного набора удобных классов-обёрток, которые можно постоянно использовать при написании программ на C++. Можете назвать это общим знаменателем, если хотите. А реализация функциональности может быть разная, в том числе и на базе кроссплатформенных библиотек которые вы предложили: Apache Portable Runtime, Netscape Portable Runtime, Qt, ACE. Хотя нативные тоже не стоит исключать.

Для того чтобы было понятнее, приведу простой пример:

Обёртка для хэш-таблицы.

Файл HashTable.h :

#include "Integers.h"

class HashTableMembers;

class HashTable
{
public:
 void  Insert(void *Key, void *Data);
 void  Delete(void *Key);
 void  Set(void *Key, void *Data);
 void* Get(void *Key);

 HashTableMembers *M;

 HashTable();
 ~HashTable();
};

В .cpp такой класс можно реализовать на базе любой уже готовой библиотеки. Сторонние заголовки включаются только в модуле, а вся потенциальная специфика прячется в классе HashTableMembers, объект которого создается в конструкторе.

Если Алгоритм Программы базировать только на таких вот общих обёртках, то в случае необходимости, библиотеку можно легко поменять. Достаточно просто переопределить функции класса. А Алгоритм Программы переписывать не надо.

Здравствуйте, Аноним, Вы писали:

А>Если Алгоритм Программы базировать только на таких вот общих обёртках, то в случае необходимости, библиотеку можно легко поменять. Достаточно просто переопределить функции класса. А Алгоритм Программы переписывать не надо.

Таких библиотек существует вагон и маленькая тележка. Чем ваша-то лучше?

Здравствуйте, Pzz, Вы писали:

Pzz>Таких библиотек существует вагон и маленькая тележка.

Не библиотека, а общая надстройка над библиотеками.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vladrsdn, Вы писали:

V>>Как раз PHP — верх кривости из-за неортогональности функций. Одних способов искать подстрочку в строке там примерно 15, и 10 — проматчить строку регекспом!

А>Тем не менее, в PHP есть интересные процедуры, которых не хватает в стандартных библиотеках C++.

и что? В С++ их нет не из-за того что Бьярн Страутструм — тупой и ограниченый, а чтобы функциональность была минимально необходимая.

V>>Имена функций тоже беспредел — где сначала глагол потом сказуемое, где наоборот и тд.

А>Имена функций мне вообще больше нравятся с заглавных букв -- в стиле Microsoft. Например, MessageBox читать намного удобнее чем message_box.

а меня от MessageBox тошнит — надо 2 раза шифт нажимать когда набираешь, а message_box — всего 1 раз, и быстрее читать код можно.

V>>Нафиг надо такие обертки, сделанные каждым под себя на скорую руку!

А>Поэтому этот вопрос необходимо решать коллективно — через ресурсы и форумы RSDN, чтобы не было как вы говорите "на скорую руку" и "каждым под себя". Возможно кое-что следует позаимствовать из обёрток запроектированных в .NET, хотя и там далеко не всё идеально.

А>Если заняться этим серьёзно — очень многое можно реально упростить.

Это называется велосипедостроительство и графомания. В юниксе слава Б-гу все этим уже переболели.

Здравствуйте, vladrsdn, Вы писали:

А>>Если заняться этим серьёзно — очень многое можно реально упростить.

V>Это называется велосипедостроительство и графомания.

Устал повторять. Ладно. Повторю ещё в 3-тий раз. Велосипедостроительство это когда библиотеки сам делаешь. А про то что я говорил — это система интуитивно простых обёрток, оптимизация в использовании языка.

V>В юниксе слава Б-гу все этим уже переболели.

Ну и к чему пришли в результате? Даже нет элементарного понимания что такое обёртка и что такое библиотека. А большинство просто смотрят друг на друга, и дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.

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

Здравствуйте, Anonim12, Вы писали:

A>Ну и к чему пришли в результате? Даже нет элементарного понимания что такое обёртка и что такое библиотека. А большинство просто смотрят друг на друга, и дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.

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

A>Большинство программистов к сожалению идёт стадом, бездумно, совершенно не занимаясь фундаментальными вопросами упрощения, улучшения удобства использования С++, эволюции удобочитаемости кода...

На C++ по-моему невозможно писать удобочитаемый код. Тут язык надо менять, а не обертки писать.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Anonim12, Вы писали:

A>>...дёшево ведутся на так называемые "стандарты", в результате чего клепают жуткий код на углоскобном STL'е, который для зрительного восприятия невероятно ужасен.
Pzz>Следование стандарту хорошо тем, что в отличии от самодельной библиотеки его специально изучать не надо. Что при прочьих равных является заметным достоинством.

Проблема только в том, что эти "стандарты" очень далеки от идеала.

A>>Большинство программистов к сожалению идёт стадом, бездумно, совершенно не занимаясь фундаментальными вопросами упрощения, улучшения удобства использования С++, эволюции удобочитаемости кода...
Pzz>На C++ по-моему невозможно писать удобочитаемый код. Тут язык надо менять, а не обертки писать.

Если есть желание — то можно. Правда, ценой отказа от "стандартов".

Я серьёзно говорю, сам язык тут совершенно не при чём. Реально не хватает удобного, рационального, сильно оптимизированного с точки зрения удобочитаемости, общепринятого набора классов с функциями и операторами.

А то что сейчас принято — STL, как раз и создаёт иллюзию сложности языка.

Здравствуйте, Anonim12, Вы писали:

A>Проблема только в том, что эти "стандарты" очень далеки от идеала.

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

A>Я серьёзно говорю, сам язык тут совершенно не при чём. Реально не хватает удобного, рационального, сильно оптимизированного с точки зрения удобочитаемости, общепринятого набора классов с функциями и операторами.

Ну я видел ваш пример. В мире C++ считается небонтонным делать хеш-таблицы, которые возвращают void* в обмен на ключ. А если вы попытаетесь сделать что-то типобезопасное, у вас как раз STL и получится. Язык такой, увы.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну я видел ваш пример. В мире C++ считается небонтонным делать хеш-таблицы, которые возвращают void* в обмен на ключ.

Указатели — простой способ передачи объекта любого типа. Наверное это не модно, но я модой не интересуюсь.

Pzz>Язык такой, увы.

Здесь всё зависит от того кому вы верите (дешёвым журнальным статьям или независимым исследованиям). На самом деле язык C++ простой. Хотя очевидно невыгодный разным богатым организациям и корпорациям типа Sun (Java) и Microsoft (VB C#.NET). Корпорации навешали ярлыков, создали иллюзию сложности — стадо поверило. Язык С++ им явно мешает привязывать программиста к конкретной среде и выбивать деньги из пирамиды.

Здравствуйте, Anonim12, Вы писали:

A>Здесь всё зависит от того кому вы верите (дешёвым журнальным статьям или независимым исследованиям). На самом деле язык C++ простой. Хотя очевидно невыгодный разным богатым организациям и корпорациям типа Sun (Java) и Microsoft (VB C#.NET). Корпорации навешали ярлыков, создали иллюзию сложности — стадо поверило. Язык С++ им явно мешает привязывать программиста к конкретной среде и выбивать деньги из пирамиды.

Я как-то все больше предпочитаю верить себе.