C++ должен устранить заголовочные файлы?

In The Design and Evolution of C++, Stroustrup gives out one more reason...

The same header file can have two or more implementation files which can be simultaneously worked-upon by more than one programmer without the need of a source-control system.

This might seem odd these days, but I guess it was an important issue when C++ was invented.

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

Одна из целей C ++ - быть надмножеством C, и ему трудно сделайте это, если он не может поддерживать заголовочные файлы. И, соответственно, если вы хотите удалить заголовочные файлы, вы можете также рассмотреть вопрос об исключении CPP (препроцессор, а не плюс-плюс) в целом; и C #, и Java не определяют препроцессоры макросов со своими стандартами (но следует отметить, что в некоторых случаях они могут использоваться и даже используются даже с этими языками).

Поскольку C ++ разработан прямо сейчас, вам нужны прототипы - - так же, как в C - для статической проверки любого скомпилированного кода, который ссылается на внешние функции и классы. Без заголовочных файлов, Вы должны были бы напечатать эти определения классов и объявления функций перед их использованием. Чтобы С ++ не использовал заголовочные файлы, вам нужно добавить в язык функцию, которая будет поддерживать что-то вроде ключевого слова Java import . Это было бы серьезным дополнением и изменением; ответить на ваш вопрос о том, будет ли это практичным: я так не думаю - совсем нет.

Если вы хотите C ++ без заголовочных файлов, тогда у меня есть хорошие новости для вас

Он уже существует и называется D ( http://www.digitalmars.com/d/index.html )

Технически D выглядит намного лучше, чем C ++, но это просто пока недостаточно для использования во многих приложениях.

C был создан для облегчения написания компилятора. Это делает много вещей, основанных на этом одном принципе. Указатели существуют только для облегчения написания компилятора, как и заголовочные файлы. Многие вещи, перенесенные в C ++, основаны на совместимости с этими функциями, реализованными для облегчения написания компилятора.

На самом деле это хорошая идея. Когда C был создан, C и Unix были своего рода парой. C портировал Unix, Unix запускал C. Таким образом, C и Unix могли быстро распространяться с платформы на платформу, тогда как ОС, основанная на сборке, должна была быть полностью переписана для переноса.

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

Эти элементы, указатели, файлы заголовков и т. Д ... на самом деле не предлагают никаких преимуществ перед другой системой. Прилагая больше усилий к компилятору, вы можете скомпилировать ссылочный объект так же легко, как указатель на точно такой же объектный код. Это то, что сейчас делает C ++.

C - отличный, простой язык. У него был очень ограниченный набор функций, и вы могли написать компилятор без особых усилий. Портирование это вообще тривиально! Я не пытаюсь сказать, что это плохой язык или что-то в этом роде, просто основные цели C при его создании могут оставить остатки на языке, которые сейчас более или менее ненужны, но будут сохраняться для совместимости. на языке ассемблера, но Томпсона Предполагалось, что это будет написано на языке высокого уровня.

Томпсон впервые попытался в 1971 году использовать Фортран на PDP-7, но сдался после первого дня. Затем он написал очень простой язык, который он назвал B, который он получил на PDP-7. Это работал, но были проблемы. Во-первых, потому что реализация была интерпретировать, это всегда будет медленный. Во-вторых, основные понятия B, который был основан на слово-ориентированных BCPL, просто не были подходящими для байт-ориентированная машина как новая PDP-11.

Ричи использовал PDP-11 для добавления типов к B, который некоторое время назывался NB для «нового Б», а затем он начал написать компилятор для него. "Таким образом Первая фаза C была действительно эти два фазы в короткой последовательности, во-первых, некоторые языковые изменения от B, действительно, добавление структуры типа без слишком много изменений в синтаксисе; и делать компилятор, "сказал Ричи.

" Второй этап был медленнее ", сказал он переписать UNIX на C. Thompson началось летом 1972 года, но было две проблемы: выяснить, как бежать основные подпрограммы, то есть, как переключить управление с одного процесса на еще один; и сложность в получении правильная структура данных, так как оригинальной версии C не было структуры.

"Сочетание причин, вызванных Кен сдастся за лето " Ричи сказал. «В течение года я добавил структуры и, вероятно, сделали код компилятора несколько лучше - лучший код - и так далее лето, когда мы сделали согласованные усилия и на самом деле сделали повтор

int i=0;
while(src[++i])
    dest[i]=src[i];

потребуется много усилий (со стороны компиляторов), чтобы отделить явные добавления i + src и i + dest и заставить его создать тот же код, что и это:

while(*(dest++) = *(src++))
    ;

Выделение этой переменной «i "после того, как факт сложен. Новые компиляторы могут это делать, но тогда это было просто невозможно, а ОС, работающей на этом дрянном оборудовании, требовалась небольшая оптимизация, подобная этой.

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

Даже Бьярн Страуструп назвал заголовочные файлы клуджем.

Но без стандартного двоичного файла Формат, который включает необходимые метаданные (например, файлы классов Java или файлы .Net PE). Я не вижу способа реализовать эту функцию. Раздвоенный ELF или двоичный файл a.out не содержит много информации, которую вам нужно извлечь. И я не думаю, что эта информация когда-либо хранится в файлах Windows XCOFF.

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

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

Обратная совместимость - Заголовочные файлы не удаляются, поскольку это нарушит обратную совместимость.

Нет языка без заголовочных файлов. Это миф.

Посмотрите на любой проприетарный дистрибутив библиотеки для Java (у меня нет опыта работы с C #, но я ожидаю, что это то же самое). Они не дают вам полный исходный файл; они просто дают вам файл с пустой реализацией каждого метода ( {} или {return null;} и т. п.) и всем, что можно избежать, скрывая скрытое. Вы не можете называть это чем-либо, кроме заголовка.

Тем не менее, нет технической причины, почему компилятор C или C ++ мог бы считать все в файле с соответствующим обозначением как extern , если этот файл не используется. составлено напрямую. Тем не менее, затраты на компиляцию были бы огромными, потому что ни C, ни C ++ не разбираются быстро, и это ' очень важное соображение. Любой более сложный метод слияния заголовков и источников может быстро столкнуться с техническими проблемами, такими как необходимость для компилятора знать структуру объекта.

If you want the reason why this will never happen: it would break pretty much all existing C++ software. If you look at some of the C++ committee design documentation, they looked at various alternatives to see how much code it would break.

It would be far easier to change the switch statement into something halfway intelligent. That would break only a little code. It's still not going to happen.

EDITED FOR NEW IDEA:

The difference between C++ and Java that makes C++ header files necessary is that C++ objects are not necessarily pointers. In Java, all class instances are referred to by pointer, although it doesn't look that way. C++ has objects allocated on the heap and the stack. This means C++ needs a way of knowing how big an object will be, and where the data members are in memory.

Oh Yes!

After coding in Java and C# it's really annoying to have 2 files for every classes. So I was thinking how can I merge them without breaking existing code.

In fact, it's really easy. Just put the definition (implementation) inside an #ifdef section and add a define on the compiler command line to compile that file. That's it.

Here is an example:

/* File ClassA.cpp */

#ifndef _ClassA_
#define _ClassA_

#include "ClassB.cpp"
#include "InterfaceC.cpp"

class ClassA : public InterfaceC
{
public:
    ClassA(void);
    virtual ~ClassA(void);

    virtual void methodC();

private:
    ClassB b;
};

#endif

#ifdef compiling_ClassA

ClassA::ClassA(void)
{
}

ClassA::~ClassA(void)
{
}

void ClassA::methodC()
{
}

#endif

On the command line, compile that file with

-D compiling_ClassA

The other files that need to include ClassA can just do

#include "ClassA.cpp"

Of course the addition of the define on the command line can easily be added with a macro expansion (Visual Studio compiler) or with an automatic variables (gnu make) and using the same nomenclature for the define name.

There is value in defining the class interface in a separate component to the implementation file.

It can be done with interfaces, but if you go down that road, then you are implicitly saying that classes are deficient in terms of separating implementation from contract.

Modula 2 had the right idea, definition modules and implementation modules. http://www.modula2.org/reference/modules.php

Java/C#'s answer is an implicit implementation of the same (albeit object-oriented.)

Header files are a kludge, because header files express implementation detail (such as private variables.)

In moving over to Java and C#, I find that if a language requires IDE support for development (such that public class interfaces are navigable in class browsers), then this is maybe a statement that the code doesn't stand on its own merits as being particularly readable.

I find the mix of interface with implementation detail quite horrendous.

Crucially, the lack of ability to document the public class signature in a concise well-commented file independent of implementation indicates to me that the language design is written for convenience of authorship, rather convenience of maintenance. Well I'm rambling about Java and C# now.

Many people are aware of shortcomings of header files and there are ideas to introduce more powerful module system to C++. You might want to take a look at Modules in C++ (Revision 5) by Daveed Vandevoorde.

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

Все же я не понимаю смысла некоторых заявлений. Разделение API и реализации - это очень хорошо, но заголовочные файлы - это не API. Там есть приватные поля. Если вы добавляете или удаляете частное поле, вы меняете реализацию, а не API.