Mercury13

1. Что принимает система: PCHAR или PCHAR*?
2. Если версии Delphi достаточно новые, PCHAR — это, скорее всего, wchar_t* и надо просто передавать «широкую» строчку L"usb3000".
3. Постарайся, чтобы reinterpret_cast не было; это признак того, что ты делаешь что-то неверно. Единственное, где он в подобных API допустим — это в callback’ах для передачи замыкания (информации о том, какая подпрограмма и при каких обстоятельствах запустила функцию, вызвавшую callback). P.S. Надумал и второе назначение reinterpret_cast — функция, которая может принимать данные разных типов (вроде SendMessage из Win32).

Что-то типа

максРазмер : целое
началоМаксВетви: узел

проц максВетвь(узел : Узел, началоВетви: Узел, текРазмер: целое)
  в зависимости от степени узла «узел»
    если 0:
      если текРазмер > максРазмер
        максРазмер = текРазмер
        началоМаксВетви = началоВетви
    если 1: максВетвь(единственныйCын, началоВетви, текРазмер + 1)
    если 2+:
      для всех сыновей
        максВетвь(сын, сын, 1)

максВетвь(корень, корень, 1)

Считает макс. ветвь, кончающуюся листом; если может кончаться и развилкой — оставляю как домашнее задание.

Первое. Заводи массив, в простейшем случае (таблица ограниченного размера) — как минимум вдвое больше, чем желаемая ёмкость. В каждом гнезде или пара (ключ, значение), или «ничего». То ли какое-то спец.значение ключа отведи на «ничего», то ли храни указатели на элементы (не забудь наладить управление памятью), то ли сделай два параллельных массива, один Entry[], второй bool[] (можно добавить bool в Entry, так лучше с прогерской точки зрения, но перерасход памяти).

Второе. Вычисляем хэш, берём остаток от деления на n, заглядываем в таблицу. Если там что-то есть, но у этого «чего-то» другой ключ, перескакиваем на 1 вперёд. Если снова неправильный ключ — то ещё на два, если снова — то ещё на три… Надеюсь, поймёшь, как делать цикл…

Третье. Зачем тебе map, если задача — сделать свою хэш-таблицу, а не пользоваться чужим самобалансирующимся деревом.

Такая таблица может только расширяться, удаление если и можно наладить, то тяжело. Википедия рекомендует второе спец.значение (кроме «ничего») — «тут когда-то что-то было». При поиске «тут когда-то что-то было» считаются занятыми, а при добавлении — свободными. Дурость в общем — удаление не упрощает поиск.

cURL?
Кроссплатформенная, кстати.

Попытайтесь выяснить, кто не терпит тупого поэлементного копирования, и изолировать их. Либо в один маленький объектик, либо в один маленький уровень наследования.

Вариант 1. Сделать промежуточный уровень наследования, в который вносим некопируемые части.

class LevelObject
{
private:
   Level& level;  // Сцылка на уровень, по определению неизменная
   int x, y;           // Присваивать.
}

Разбиваем на две части (внимание! — конструктор копирования для простоты не прописан, вероятно, потребуется и он):

#include <iostream>

class Level
{
public:
    int value;
    Level(int aValue) : value(aValue) {}
};

class LevelChild
{
protected:
    Level& level;  // не присваивать
public:
    LevelChild(Level& aLevel) : level(aLevel) {}
    LevelChild operator=(LevelChild&) { return *this; }   // ничего не делающая операция «присвоить»
};

class LevelObject: public LevelChild
{
protected:
    int x, y;
public:
    LevelObject(Level& aLevel, int aX, int aY) : LevelChild(aLevel), x(aX), y(aY) {}
    void print();
};

void LevelObject::print()
{
    std::cout << "(" << x << ", " << y << ") at level " << level.value << std::endl;
}

int main()
{
    Level l1(1);  LevelObject o1(l1, 1, 2);
    Level l2(2);  LevelObject o2(l2, 3, 4);
    o1.print();
    o2.print();
    o2 = o1;
    o2.print();
}

Вариант 2. Сделать маленькие объекты-функции со своими операциями присваивания.

class LevelObject
{
private:
   Level* level;  // На сей раз уже копируется
   Array3 pos;    // Какой-то инкапсулированный объект-массив
   std::wstring name;   // тоже инкапсулированный объект
}

И всё, когда для std::wstring и Array3 корректно прописаны операции присваивания, для LevelObject всё будет работать корректно без единой строчки.

P. S. А точно ваш объект страдает от поэлементного копирования и нужна своя операция?

Вот, допустим, подсказка по XE2.

Data.Win.ADODB.TADOQuery

Type  | Visibility | Source             | Unit           | Parent 
class | public     | Data.Win.ADODB.pas | Data.Win.ADODB | Data.Win.ADODB 
                   | Data.Win.ADODB.hpp |

Вот и подключаешь <Data.Win.ADODB.hpp>. В более ранних версиях Builder придётся подключать просто <ADODB.hpp>.

Исходник, конечно, дай — посмотрим, что там можно сделать. Как вариант, можно сделать так.

Node nullNode = { NULL, NULL, NULL, BLACK };
class NodeHandle {
private:
  Node* data;
  Node* getData() const { return data ?data : &nullNode; }
public:
  NodeHandle() : data(&nullNode) {}
  NodeHandle(Node* x) : data(x) {}
  NodeHandle& operator=(Node* x) { data = x; return *this; }
  bool operator == (const Node* x) const { return (data == x); }
  bool operator != (const Node* x) const { return (data != x); }
  bool operator == (const NodeHandle& x) const { return (data == x.data); }
  bool operator != (const NodeHandle& x) const { return (data != x.data); }
  Node* operator ->() const { return getData(); }
  Node& operator *() const { return *getData(); }
  operator Node*() const { return getData(); }
}

Но, думаю, всё же где-то вкралась ошибка.

Дело в том, что static-член в теле класса — это только заголовок, говорящий, что такое есть, но не создающий ни кода, ни данных. Эквивалент extern. Где-то в CPP (т.е. в одной и только в одной единице компиляции — не в .h!) нужны…

std::vector LogVoting::RegisteredDeputy;

И так далее.

Если этим полям нужен нестандартный конструктор — пожалуйста…
std::vector LogVoting::RegisteredDeputy(42);

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

Инверсия абстракции. Простые вещи, которые, вероятно, понадобятся потомкам, недоступны даже через protected.

Нарушение принципа Лисков (ломаная абстракция). Для отца вы сделали некое предположение, которое неверно для сыновей. Классический пример — прямоугольник и квадрат — предполагается, что отец может произвольно масштабироваться, что неверно для сына.

Класс вместо интерфейса. Если можно, родителя делайте классом без данных с двумя видами функций: public virtual = 0, и protected/public не-virtual (т.н. интерфейс с утилитами). Наследоваться от нескольких классов с данными очень некузяво (а во многих языках вообще невозможно).

Всемогущий родитель. Слишком много функциональности придумали родительскому классу.

В общем, покажите интерфейсы (protected/public, без точных реализаций) ваших классов, и погоняем, что там неверного.

pthread_mutex_locker locker(&mutex);

Назови его как-нибудь, и всё будет окей.

Я хотел спросить: вы что, студент? Потом посмотрел: нет, вебист. Вебистам действительно ООП нужно крайне редко; если не связывался с хитрой поддержкой сложных протоколов или со сложными моделями данных — в памяти, не в БД — можно писать без ООП и быть успешным вебистом.

Я и сам долгое время не понимал, на что нужны эти объекты. Главный вопрос: ДЛЯ ЧЕГО?

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

Предлагаю начать с простого.

1. Объектный синтаксис. Было…

iDog : integer;
iDog := SpawnMonster(world, mtDog, x, y);
ChargeAtPlayer(iDog);

Стало…

dog : TMonster;
dog := world.SpawnMonster(mtDog, x, y);
dog.ChargeAtPlayer;

Уже стало красивее. Да и номер собаки можно случайно передать, например, вместо номера оружия; с типом TMonster такой фокус не пройдёт.

2. Инкапсуляция.
Это мы уже думаем над тем, чтобы вызовы функций не могли привести объект в «ненадлежащее» состояние, а всё, что может объект подпортить,— засунуто в private.

3. Абстракция и наследование. Это уже «сложный пилотаж». Не высший — это неотъемлемая часть навыков хорошего программиста, да и для 80% задач это не нужно, зато в остальных 20-и очень улучшает жизнь. Самый простой пример. В какой-нибудь 2D-игре есть некий TGameObject, у которого виртуальные функции Live и Render. Первая прокручивает такт «жизни» объекта, вторая рисует его на экране. TGameObject можно разбить на TPlayer, TProjectile, TEnemy и TBonus, и т.д.

Ах да. Для ООП не нужен объектно-ориентированный язык и объектный синтаксис, нужно объектно-ориентированное мышление. Например, Doom был написан на Си, но в очень-очень объектном стиле.

C++ — язык со статической типизацией, и если x объявлено как string, то он всегда string. А если как int, то он никогда не string. Поэтому функция is_string в C++ просто не имеет смысла.

Правда, существуют островки динамической типизации наподобие VARIANT из OLE — это уже смотрите по месту (msdn.microsoft.com/en-us/library/cc237865.aspx) и, скорее всего, это не ваш вопрос.

Да, вы хотели проверять корректность ввода. Например, для проверки, будет ли строка числом, можно использовать www.cplusplus.com/reference/cstdlib/strtod (не забудьте потом проверить endptr!)

Всё, что я знаю: GCC — самый «въедливый» компилятор. После Intel и Embarcadero (про M$ не знаю) на «зашаблоненном» коде GCC найдёт ещё два десятка ошибок.

Это к Sony или StarForce. И те, и другие делали заSHITу и прокалывались на подобном.

Разрешите вставить и свои 5e−2 Р…

Известно ли что-то о том, какой тип будет иметь наш auto? Если известно, то может, сработает просто

dynamic_cast<Type>(object).field1.field2 = NULL;