Совет пространств имен C++
Вы можете сделать это таким образом.
List<PurchaseInvoice> objPurchaseInvoiceList = new List<PurchaseInvoice>();
foreach (DataTable row in dtPurchaseInvoice)
{
objPurchaseInvoiceList.add(new PurchaseInvoice{ PurchaseInvoiceNo=Convert.ToInt32(row["PurchaseInvoiceNo"])});
}
7 ответов
Пространства имен C++ не были предназначены, чтобы быть механизмом дизайна - они должны там просто предотвратить столкновения имени. Вы действительно не хотите или должны использовать вложенные пространства имен в 99,99% ситуаций.
Хорошим примером корректного использования пространств имен в C++ является Библиотека Стандарта C++. Все в этой довольно крупной библиотеке помещается в единое пространство имен, названное станд. - нет никакой попытки или потребности разбить библиотеку в (например), подпространство имен ввода-вывода, математическое подпространство имен, контейнерное подпространство имен и т.д.
Основной инструмент для моделирования в C++ является классом (и в некоторой степени шаблон), не пространство имен. Если Вы чувствуете потребность во вложении, необходимо рассмотреть использование вложенных классов, которые имеют следующие преимущества перед пространствами имен:
- у них есть методы
- они могут управлять доступом
- они не могут быть вновь открыты
Рассматривание их, если Вы все еще хотите использовать вложенные пространства имен любой ценой, делает так - нет ничего технически неправильно с использованием их таким образом.
Пространства имен C++ были значительным улучшением по сравнению с предыдущим предложением (т.е. никакие пространства имен вообще). Пространства имен C# расширили понятие и работали с ним. Я советовал бы Вам сохранять свои пространства имен в простой плоской структуре.
РЕДАКТИРОВАНИЕ Вы сообщаете, что из-за коротких прибытий я обрисовал в общих чертах здесь?
Просто "Да". Пространства имен C++ не были разработаны, чтобы помочь Вам разделить свою логику и библиотеки путем, они делают в C#.
Цель пространств имен C++ состоит в том, чтобы остановить проблему реального мира, с которой встречаются разработчики C, где они испытывают коллизии имени, когда использование двух третьих лиц освобождает тот экспорт то же имя (имена) функции. C разработчики имел различные обходные решения для него, но это могла быть серьезная боль.
Идея состояла в том, что STL и т.д. имеет std:: пространство имен, освобождает обеспеченный "XYZ Corp.", имел бы xyz:: пространство имен, Вы работающий на "корпорацию ABC" поместили бы весь свой материал в сингл abc:: пространство имен.
По крайней мере как маленькая справка, в некоторых случаях можно сделать это:
namespace foo = A::B::C::D;
И затем ссылка A:: B:: C::D как нечто. Но только в некоторых случаях.
В первую очередь, можно избежать добавления отступа пространства имен, потому что нет никакой причины этого.
Используя пространства имен в примерах не покажет питание пространств имен. И их питание что касается меня делит области Domain один от другого. Разделите служебные классы от бизнес-.
Просто не смешивайте различные иерархии пространства имен в одном.h файле. Пространства имен являются видом дополнительного комментария для Вашего интерфейса объявления функций. Наблюдение пространств имен и имен классов должно объяснить много материала.
namespace product
{
namespace DAO
{
class Entity
{
};
Вы злоупотребляете их (и Вы ничего не получите в ответ).
то, что я делаю при прямом объявлении, выглядит следующим образом:
namespace abc { namespace sub { namespace subsub { class MyClass; }}}
Мои предварительные объявления сворачиваются в одну строку. Читаемость прямого объявления приносится в жертву читабельности остального кода. И для определений я не
Вы можете пропустить отступ. Я часто пишу
namespace myLib { namespace details {
/* source code */
} } /* myLib::details */
Исходный код C ++ в конечном итоге компилируется в двоичный, в отличие от C # / Java, который остается в двоичном формате. Следовательно, пространство имен просто обеспечивает прекрасное решение конфликта именования переменных. Он не предназначен для иерархии классов.
Я часто сохраняю в коде один или два уровня пространства имен.