LINUX.ORG.RU

namespaces and function overloading

 , ,


0

2

Господа, подскажите, пункты стандарта которые описывают правила поиска перегрузок в следующей ситуации:

// someone.h
namespace Foo {
void func(int b);
class Test{
  static void test();
}
}

// anotherone.h
namespace Bar {
void func(int b, int a);
}

// someone.cpp
#include "someone.h"
#include "anotherone.h"

using namespace Bar;
using namespace Foo;
namespace Foo {
using Bar::func; // Решение
}
void Test::test()
{
  int a, b;
  func(a, b); // эта функа не находится компилятором...
  Bar::func(a,b);// Так находится
  func(a); // И эта находится
}

Upd: поправил код - не находится функа внутри статического метода класса, как минимум в gcc тоже воспроизводится.

Upd: вспомогательный вопрос:) считается ли перегрузкой функа из неймспейса для функи из другого неймспейса, при условии что оба неймспейса включенны в одну область видимости.

Upd: коллеги помогли найти решение, см сэмпл.

Upd: Печально, что никто так и не дал ссылку на стандарт :)

Upd: спасибо Harald, частично к решению проблеммы можно было прийти прочитав 7.3.3(The using declaration) и 7.3.4(Using directive).

★★★★★

Последнее исправление: pon4ik (всего исправлений: 6)

Ответ на: комментарий от DELIRIUM

А более развернуто?

Мне хотелось бы, обьединить области видимости этих неймспейсов в файле реализации.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Да, походу бага у мелкомягких(c++/CLI конпиль), но всё таки хотелось бы знать что говорит об этом стандарт :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

А немспейсы для того и сделаны, чтобы у тебя конфликтов имен не было.

И да,

voi func(int b, int a);
Похоже на опечатку
void func(int b, int a);

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

У меня там никаким ambigous - не пахнет, есть набор перегруженных функций выполняющий конвертацию native->managed. В одном неймспейсе лежат функи для типов общего назначения, а в другом для типов специфичных для даного неймспейса.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от DELIRIUM

Правда что ли. Так можно было да?

Хочется:

namespace Core{
class CoreEntity;
class CoreEntityRepresentation;
void entityToRepresentation(const CoreEntity& entity, const CoreEntityRepresentation& representation);
}

namespace Feature{
class FeatureEntity;
class FeatureEntityRepresentation;
void entityToRepresentation(const FeatureEntity& entity, const FeatureEntityRepresentation& representation);

struct FeatureImplementationBlaBlaBlaDetails
{
  void  generatedStuff()
  {
     entityToRepresentation(entity1, repr1);
     entityToRepresentation(entity2, repr2);
     entityToRepresentation(entity3, repr3);
  }

private:
CoreEntity entity1;
WtfEntity entity2;
FeatureEntity entity3;
}

}

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от four_str_sam

Кстати да, считается ли перегрузкой функа из неймспейса для функи из другого неймспейса, при условии что оба неймспейса включенны в одну область видимости.

Пожалуй вынесу это в заголовок :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik
namespace Core{
class CoreEntity;
class CoreEntityRepresentation;
}
void entityToRepresentation(const Core::CoreEntity& entity, const Core::CoreEntityRepresentation& representation);

namespace Feature{
class FeatureEntity;
class FeatureEntityRepresentation;

struct FeatureImplementationBlaBlaBlaDetails
{
  void  generatedStuff()
  {
     entityToRepresentation(entity1, repr1);
     entityToRepresentation(entity2, repr2);
     entityToRepresentation(entity3, repr3);
  }

private:
CoreEntity entity1;
WtfEntity entity2;
FeatureEntity entity3;
}

}

void entityToRepresentation(const Feature::FeatureEntity& entity, const Feature::FeatureEntityRepresentation& representation);
four_str_sam
()
Ответ на: комментарий от peregrine

Да, точно, очепятка, спасибо.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Зато работает, код генерируется, а я сижу и кайфую.

А если достопочтимый анонимный мужик таки покажет более изящное решение - то оно, конечно же, будет без промедлений интегрированно.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

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

four_str_sam
()
Ответ на: комментарий от four_str_sam

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

Ради того что бы свои функи были в своих неймспейсах, собственно и затевался сабж.

или вынести наружу одну шаблонную функцию и специализировать с разными параметрами внутрии отдельного спп файла

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

И уж точно оба решения не проще сделать, т.к. десятка 3-4 функций уже имеются, и в найденном решении что бы их заюзать достаточно 3 строк, а во всех остальных случаях надо всё выкинуть и запилить заного.

pon4ik ★★★★★
() автор топика

Спасибо за топик! Наконец-то нашёл пример ситуации, где не обойтись без Inversion of Control и Dependecy Injection.

E ★★★
()
Ответ на: комментарий от pon4ik
abstract class Entity {};
abstract class Representation {};
class Converter {
    void entity_to_representation(const Entity & entity, Representation & representation);
};

namespace Core {
    class CoreEntity : public Entity {};
    class CoreRepresentation : public Representation {};
};

namespace Feature {
    class FeatureEntity : public Entity {};
    class FeatureRepresentation : public Representation {};
};

...

converter.entity_to_representation(core_entity, core_representation);
converter.entity_to_representation(feature_entity, feature_representation);
// Даже можно так:
converter.entity_to_representation(core_entity, feature_representation);
E ★★★
()

Печально, что никто так и не дал ссылку на стандарт

А самому скачать, открыть пдфку и поискать в оглавлении, не?

Harald ★★★★★
()
Ответ на: комментарий от Harald

Ну если это так просто - скажи пункт... а точнее пункты.

Про ADL там, и прочие правильца.

А то умничать, да, все горазды...

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от E

В моём случае именно такой метод не прокатил бы, хотя в сэмпле это не отражено.

Во-первых - есть встроенные типы managed и native соответсвенно.

Во-вторых тут больше буков в итоге будет вроде бы как, хотя это и не существенно.

Вообщем схемы с наследованием подходят в моём случае плохо.

А так, да, если бы предметная область была бы описанна только в терминах самопальных типов от которых можно наследоваться, выглядит здраво.

Возможно тут можно что то придумать с другими формами статического полиморфизма, но, имхо, перегрузки тут за глаза и за уши :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

А в чём проблема сделать на шаблонах? Так даже проще. Тем более, я так понимаю, тебе это нужно только ради красоты записи.

class Core {
    class Entity {};
    class Representation;
    void convert(Entity, Representation);
};

class Feature {
    class Entity {};
    class Representation;
    void convert(Entity, Representation);
};

template<class T>
void entity_to_representation(T::Entity, T::Representation)
{
    T::convert(entity, representation);
}

entity_to_representation(core_entity, core_representation);
entity_to_representation(feature_entity, feature_representation);

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

E ★★★
()
Ответ на: комментарий от E

Неймспейсы тут - побочная весчь, которую нужно было обойти.

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

Шаблоны - просто не понятно зачем они здесь нужны, в плане полиморфизма они дают тоже самое, что и перегрузка. Точнее, там бдует таже самая перегрузка, только к ней ещё добавяться правила вывода аргументов. Опять же - больше буков, а функов ковертящих порядка сотни, и это количество будет расти. Плюс я не уверен - какие подводные камни мне подкинет c++/CLI в варианте с шаблонами, не очень я доверяю мелкомягким :) Обидно было бы переделать 99 функций и напороться на том что 100ая и ещё 300 переделать не выйдет. А решение с перегрузкой - уже проверенное, хм, годами :)

Или я не вижу какого то выигрыша в шаблонном решении, которое перевесило бы риски выше описанные?:)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от E

тебе это нужно только ради красоты записи

Нее, мне хочется этот код начать генерировать.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от Harald

Ну я попробовал в драфте поискать по регуляркам, за 15 минут ничего не нашёл, решил параллельно на лоре запостить.

Параллельно спросил коллег. Коллеги оказались эффективней :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от Harald

Ну 7.3.3 и 7.3.4 могли бы помочь, при условии что знаешь что ищешь. Конечно если бы было бы больше времени я бы туда пришёл наверное, но это явно не отправной пункт :)

Но это точно лучше чем ничего:)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от Harald

как писано было на баше седня:

Клиентов по всем вопросам посылать к администратору. Не нахер, а к администратору.

:D

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от Harald

Прост там надо ориентироваться, а мну пока не осилятор, а вообще да, месье седня в ударе явно в ударе :)

pon4ik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.