Способы показать вашим со-программистам, что некоторые методы еще не реализованы в классе при программировании на C ++

Question

Какие подходы вы можете использовать, когда:

• вы работаете с несколькими (например, 1-3) другими программистами над небольшим проектом C ++, вы используете один репозиторий
• вы создаете класс,объявите его методы
• у вас нет времени для реализации всех методов
• вы не хотите, чтобы другие программисты использовали ваш код (потому что он еще не реализован);или вы не хотите использовать еще не реализованные части кода
• у вас нет времени / возможности рассказать обо всех таких еще не реализованных вещах своим коллегам
• , когда ваш сотрудник-работники используют ваш еще не реализованный код, который вы хотите, чтобы они сразу поняли, что им еще не следует его использовать - если они получают ошибку, вы не хотите, чтобы они задавались вопросом, что не так, искали потенциальные ошибки и т. д.

Answer 1

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

Более надежный (и, вероятно, лучший) вариант - создать собственную ветку для разработки новой функции и объединить ее только после завершения.

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

Answer 2

Мне действительно нравится понятие из .Net о NotImplementedException.Вы можете легко определить свой собственный, исходя из std::exception, переопределяя what как "не реализованный".

Он имеет следующие преимущества:

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

Answer 3

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

Это то, что я делаю на работе с моим git-репо. В конце дня я перенесу свою работу на удаленный репозиторий (а не на главную ветку). Мой коллега знает, что эти ветви очень пышные и неустойчивые, и их нельзя трогать с помощью десятифутового шеста, если он действительно не любит ломать ветви.

Git очень удобен для этой ситуации, как и другие dvcs с дешевым ветвлением. Делать это в SVN или еще хуже, но CVS означало бы боль и страдание.

Answer 4

Я бы не проверял это в хранилище.

Answer 5

Объявите это.Не реализовано .Когда программист использует для вызова неосуществленную часть кода, компоновщик жалуется, что является явным ударом для программиста.

class myClass
{
    int i;
public:
    void print(); //NOt yet implemented
    void display()
    {
        cout<<"I am implemented"<<endl;
    }
};

int main()
{
    myClass var;
    var.display();
    var.print(); // **This line gives the linking error and hints user at early stage.**
    return 0;
}

Answer 6

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

В случае, если этоВаша IDE не поддерживает интеллектуальные утверждения или постоянные точки останова. Вот простая реализация (c ++):

#ifdef _DEBUG
    // 0xCC - int 3 - breakpoint
    // 0x90 - nop? 
    #define DebugInt3 __emit__(0x90CC)
    #define DEBUG_ASSERT(expr) ((expr)? ((void)0): (DebugInt3) )
#else
    #define DebugInt3
    #define DEBUG_ASSERT(expr) assert(expr)
#endif

    //usage
    void doStuff()
    {
        //here the debugger will stop if the function is called 
        //and your coworker will read your message
        DEBUG_ASSERT(0); //TODO: will be implemented on the next week; 
                         //postcondition number 2 of the doStuff is not satisfied;
                         //proceed with care /Johny J.
    }

Преимущества:

1. код компилируется и запускается
2. aРазработчик получит сообщение о том, что не реализовано, если и только если он столкнется с вашим кодом во время тестирования, поэтому он не будет перегружен ненужной информацией
3. сообщение указывает на связанный код (не на блок перехвата исключений)или что угодно).Стек вызовов доступен, поэтому можно отследить место, где он вызывает незавершенный кусок кода.
4. разработчик после получения сообщения может продолжить свой тестовый прогон без перезапуска программы

Недостатки:

1. Чтобы отключить сообщение, нужно закомментировать строку кода.Такое изменение может проникнуть в коммит.

PS Кредиты для первоначальной реализации DEBUG_ASSERT идут моему коллеге EG

Answer 7

Вы можете использовать чисто виртуальные функции (= 0;) для унаследованных классов или, более часто, объявлять их, но не определять их.Вы не можете вызвать функцию без определения.