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

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

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

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

Я бы в репозиторий не регистрировал.

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

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

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

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

В случае, если ваша 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. разработчик получает сообщение о том, что не реализовано, если и только если он столкнется с вашим кодом во время своего тестирования, чтобы он не был перегружен ненужной информацией
3. , сообщение указывает на связанный код (не на блок исключения исключения или что-то еще). Стек вызовов доступен, поэтому можно отследить место, где он вызывает незавершенный фрагмент кода.
4. разработчик после получения сообщения может продолжить тестовый прогон без перезапуска программы.

Недостатки:

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

P.S. Кредиты на первоначальную реализацию DEBUG_ASSERT принадлежат моему коллеге Э. Г.

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

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

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

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