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

А> void* Get(void *Key);

Вот в этом месте мы отказываемся от возможности определять ошибки типов на стадии компилляции. Невозможно проверить, объект какого типа вернёт нам Get(). Имхо, это неудачный пример.

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

А>> void* Get(void *Key);
_>Вот в этом месте мы отказываемся от возможности определять ошибки типов на стадии компилляции. Невозможно проверить, объект какого типа вернёт нам Get().

Объект типа "последовательность байтов". По-моему самый простой тип, поэтому он часто используется в ассемблере.
А как всем известно, C/C++ это кроссплатформенный ассемблер.

_>Имхо, это неудачный пример.

Может быть. Не спорю. Каждому — своё.

P.S. Единственный реально кроссплатформенный тип — это char/unsigned char.
представление целых (int) — уже зависит от процессора ( Little/Big-Endian на SPARC/Intel — отличаются )
представление дробей (float, double) — от процессора/компилятора
Объекты структур и классов — на разных платформах тоже имеют разные бинарные представления (выравнивание).
Так что самый кроссплатформенный "тип" — это байт и поток байтов.

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

А>Объект типа "последовательность байтов". По-моему самый простой тип, поэтому он часто используется в ассемблере.

Гораздо чаще используются "сложные" типы — классы, структуры, потоки.

А>P.S. Единственный реально кроссплатформенный тип — это char/unsigned char.

Разве? А как на счёт 7-битных артихектур? В embedded-железках или какой-нибудь самопальной экзотике попадается, AFAIK.
Или любых прочих архитектур, где размер байта != 8?

А>представление дробей (float, double) — от процессора/компилятора

Разве представление float/double зависит от _компилятора_? o_O

А>Объекты структур и классов — на разных платформах тоже имеют разные бинарные представления (выравнивание).

И что теперь? Зачем полагаться на внутреннее представление объектов в памяти? Нужно хранение/передача объектов между разными архитектурами? Тогда копаем в сторону сериализации. А если нужно просто создавать/использовать объекты — то какая нам разница, как они там внутри записываются?

А>Так что самый кроссплатформенный "тип" — это байт и поток байтов.

Угу.. а самый кроссплатформенный язык — brainf*ck (а'ля "машина Тьюринга").
Нет уж, извините. Я обычно стараюсь максимально использовать проверку типов на этапе компилляции, а всевозможные void* этому лишь препятствуют.

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

_>Разве представление float/double зависит от _компилятора_? o_O

Насколько я помню, float и double — это не стандартизированные типы. То есть, существуют только некоторые минимальные требования на счёт реализации.

Нашёл интересный кроссплатформенный набор бесплатных контролов под лицензией BSD: http://www.ultimatepp.org/src$CtrlLib$index$en-us.html

ArrayCtrl — Complex tabular widget.




RichEdit




ColorPopUp




OptionTree




MenuBar

Очень похоже, что всё рисовано "с нуля", с возможностью менять скины:

Windows XP, standard theme




Windows XP, "Tiger" theme




Linux Ubuntu 6.10, Mist theme

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

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

A>Указатели — простой способ передачи объекта любого типа.

Что есть такое "способ передачи" и "объект"?

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

CS>Что есть такое "способ передачи" и "объект"?

Большинство объектно-ориентированных языков основаны на двух базовых понятиях: классы объектов и экземпляры (instances) объектов.
Здесь подрозумевается конкретный экземпляр объекта.

Способы передачи экземпляров объектов бывают следующие: по значению, по указателю, по ссылке.
Здесь экземпляр объекта передаётся по указателю.

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

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

CS>>Что есть такое "способ передачи" и "объект"?

А>Большинство объектно-ориентированных языков основаны на двух базовых понятиях: классы объектов и экземпляры (instances) объектов.
А>Здесь подрозумевается конкретный экземпляр объекта.

А>Способы передачи экземпляров объектов бывают следующие: по значению, по указателю, по ссылке.
А>Здесь экземпляр объекта передаётся по указателю.

То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х. У них там была доступная для покупки удобная ООП библиотека контейнеров и алгоритмов и многого другого.
Угадайте с 1й попытки когда они перестали ее продавать ? Правильно как только реализации stl стали доступны под все платформы.
Здесь не передается никакой экземпляр — только адрес неопознанного места в памяти (даже без указания на а)занятый размер б)выделенный размер в)что с ним можно делать). С таким же успехом это может быть адрес тела malloc (это если забыть скобочки ненароком) и пишите туда что хотите — часть платформ даже не ругнется в рантайме до следующего вызова
это только по алгоритмам и контейнерам — а про то как вы собрались абстрагировать файловую систему вы еще примеров не показывали — давайте, народу будет интересно.

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

SD>То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х.

Никаких претензий на новизну Наоборот. Это качественный пересмотр старого подхода, уровня даже не 90x, а 80x годов. Не спорю, так сейчас не модно.

А связываться с местными сторонниками С++ мейнстрима затрагивая больную тему неудобства STL — особого желания нет. Хотя очень кратко развернуть этот вопрос можно:

STL always seems to destroy your friendly development environment that helps you to do things quickly and efficiently if the original programmer had used straight-forward C++.

STL API Syntax is Unclear, the Designers Had No Taste There are APIs that are clear and the designers "get it", and there are APIs that are totally unclear, ambiguous, and the designers seem like they have never programmed before. STL falls into the latter camp, the designers had bad taste and little or no experience at defining APIs.

I've seen just too much code, typically written as university projects, that uses STL and totally kills an algorithm's performance. Here's an example: an algorithm to computer a Steiner Tree. The original coding was in C, and was pretty efficient using native C arrays. But a certain university group thought it would be cool to reimplement it in C++.
The resulting code, when profiled showed that a high proportion of the runtime was in the STL map code, specifically operator[]. Rewriting it with a simple array class gave a ~5x speedup.

STL Encourages (Lures?) Programmers to Use Very Complex Data Structures — STL gets beginner programmers in trouble VERY fast. In stead of figuring out how to solve a problem with a simple data structure, or without any data structures at all, STL offers full-tilt-grandiose psychotically complex data structures at the mere typing of one line.

Here is an example from code that another engineer stumbled across:

If you look at the example above, it is a case of STL gone nuts. In one line "forceUpates" is a very complex data structure, but it turns out this data structure was totally unnecessary, all the code needed to do was loop over a few files and set a flag. This example also shows how subtle and incomprehensible STL compiler problems are, can you see the error in the syntax? Hint: it is one space that needs to be added or the code will not build.

Как говорится, на вкус и цвет товарищей нет.


SD>У них там была доступная для покупки удобная ООП библиотека контейнеров и алгоритмов и многого другого.
SD>Угадайте с 1й попытки когда они перестали ее продавать ? Правильно как только реализации stl стали доступны под все платформы.

А если быть ещё точнее, то они перестали её продавать когда появилось большое количество бесплатных альтернативных реализаций удобных ООП библиотек контейнеров и алгоритмов (и не только STL), доступных под все платформы: искать здесь.

SD>Здесь не передается никакой экземпляр — только адрес неопознанного места в памяти (даже без указания на а)занятый размер б)выделенный размер в)что с ним можно делать).

Если очень нужно — первые 8 байт можно специально резервировать под размер.
Вопрос что делать — не возникал. Обычно всегда понятно что делать.

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

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

SD>>То что вы нам тут с претензией на новизну продаете Буч сотоварищи продавал в начале 90х.

А>Никаких претензий на новизну Наоборот. Это качественный пересмотр старого подхода, уровня даже не 90x, а 80x годов. Не спорю, так сейчас не модно.

А>А связываться с местными сторонниками С++ мейнстрима затрагивая больную тему неудобства STL — особого желания нет. Хотя очень кратко развернуть этот вопрос можно:
...
А>Как говорится, на вкус и цвет товарищей нет.

ох, постыдились бы ...
Я еще могу понять слезы тех, у кого весь codebase вынужденно написан в Invented-Here-Portable-Runtime и им физически неприятно что гдето есть код, который смогут понять люди без "специального посвящения", но анонимам это непростительно.

хотите бесплатный совет — разместите свое видение ("Это качественный пересмотр" итп) в виде кода на opensource хостинге с багтрекером и контролем версий и скидывайте сюда объявы "[ANN]" о релизах.
Если что то продавать его вам это не помешает а даже поможет. Вы ведь не думаете что qt — бесплатен ?