Подтвердить что ты не робот

С++ эквивалент С#

Я пытаюсь выполнить резервное копирование некоторого кода с С# на С++, чтобы обойти раздражающую проблему, и как бы спросить, знает ли кто-нибудь, что эквивалент С# 'internal' будет в С++.

Вот пример использования:

internal int InternalArray__ICollection_get_Count ()
        {
            return Length;
        }

Ответ 1

В С++ нет прямого эквивалента internal. Помимо public/protected/private единственным другим механизмом управления доступом является friend, механизм которого позволяет отдельным классам доступ ко всем членам вашего собственного класса.

Поэтому его можно использовать как механизм контроля доступа internal, с большой разницей в том, что:

вам нужно явно объявлять классы friend по очереди
friend классы имеют доступ ко всем членам без исключения; это чрезвычайно высокий уровень доступа и может вводить жесткую связь (что является причиной того, что обычная рефлекторная реакция на friend "вам это действительно нужно?" )

См. также Когда вы должны использовать "друга" на С++?

Ответ 2

Если ваша идея состоит в том, чтобы изолировать целые модули друг от друга, вы можете попробовать сохранить два набора файлов заголовков - один с "общедоступными" методами, другой с "внутренними". Я не уверен, как избежать дублирования на этом этапе; AFAIK класс может быть объявлен только один раз в блоке компиляции, и для общего и внутреннего заголовков требуется полное определение класса. Один, по общему признанию, очень неуклюжий способ состоит в том, чтобы иметь частичные файлы, такие как _Foo.public.h и _Foo.internal.h, которые содержат только объявления методов, а "реальные" файлы заголовков включают один или оба из них в тело объявления класса:

Foo.public.h

class Foo {
    #include "_foo.public.h"
}

Foo.internal.h

class Foo {
    #include "_foo.internal.h"
}

Исходные файлы будут ссылаться на внутренние заголовки собственного модуля, но на публичные из их зависимостей. Должна быть возможность настроить макет проекта и построить скрипты, чтобы сделать это достаточно прозрачным. (Например, настройка путей включения в соответствующие каталоги для каждого модуля.)

Это просто скрывает "внутренние" элементы вместо реализации фактического контроля доступа и, следовательно, предполагает, что модули скомпилированы отдельно и рассматриваются как двоичные зависимости. Если вы обрабатываете зависимости, вставляя их в исходное дерево и компилируя все сразу, вы должны иметь возможность их создавать в любом случае, а объявления внутреннего метода все еще могут присутствовать в сборке.