Перейдите на https://jsfiddle.net/ , чтобы поиграть с html. Он будет предупреждать вас о том, что ваш HTML-файл искажен.
ООП используется в Си так часто, как это необходимо. Вообще я не согласен с мнением, что в Си нельзя сделать ООП, как только вы предоставляете набор функций, которые работают с заданным типом, у вас есть ООП. Например, вы решили создать структуру данных. Если вы предоставляете функции для создания, добавления, удаления и поиска элементов структуры данных, то это ООП. Как правило, другие языки обеспечивают синтаксический сахар, автоматически подразумевая переменную экземпляра и автоматически определяя различные свойства этого экземпляра.
У меня был опыт работы с несколькими продвинутыми проектами на Си, которые хотя бы частично используют ООП. Наиболее известным является ядро Linux.
Ядро полностью C (за исключением отдельных частей платформы в сборке для аппаратных интерфейсов).
Ядро интенсивно использует структуры с указателями на функции во многих местах. Первое, что приходит на ум, это файловые системы. Драйверы заполняют структуру file_operations (как и многие другие) обратными вызовами для своих конкретных реализаций.
Ядро также широко использует операторы goto
, которые в некоторых контекстах могут рассматриваться как элементарные операторы throw, ведущие метку в конце функции для некоторой очистки и выхода. (Хотя они также используют goto
для гораздо большего, чем просто для обработки ошибок, и он также используется только для «исключений» внутри функции, а не для передачи их наружу.)
Это может быть, но без вызовов функций времени уничтожения, предоставляемых другими языками ООП, это не так полезно. Кроме того, если вам нужен ООП, всегда есть C ++, где ваш код практически мгновенно переносим на него.
Реализация ООП на C, действительно ли она используется? Или это просто для умственных упражнений?
Да, он действительно используется, но неудивительно, что он не так распространен, как ООП, в языках, которые для этого были разработаны.
Какие-либо из существующих проектов C используют ООП?
Я помню, как использовал парочку:
Когда использование ООП на C является хорошей идеей?
Некоторые проблемы очень хорошо моделируются ООП. Например, графические интерфейсы пользователя часто разрабатываются с наследованием между типами окон с использованием полиморфизма для переопределения и специализации поведения.
Вы должны использовать ООП всякий раз, когда у вашей проблемы есть красивое ООП-решение. С примечанием, что вы не должны вставлять 100 строк ООП-кода в проект из 15000 строк только потому, что это "kewl"! :)
Стоит ли мне тратить на это свое время?
Это действительно зависит от того, что вы планируете с этим делать. Я бы никогда не выступал за то, чтобы ничего не изучать - здорово узнать, как, почему и когда это использовать. Приятно видеть, что язык, который не был разработан для ООП, поддерживает ООП. Вы читаете книгу, поэтому я предполагаю, что вы имеете некоторую близость к C и интерес к ООП. Попробуйте, может быть, скомпонуйте несколько приложений с графическим интерфейсом в GTK +. С другой стороны, если вы хотите стать следующим веб-разработчиком шаблонов проектирования, это, вероятно, не лучший подход, вы можете рассмотреть другие языки, которые более ориентированы на эту область.
Так что бы вы посоветовали?
Я бы посоветовал вам использовать лучшие инструменты, имеющиеся в вашем распоряжении, которые подходят для задач, которые вы пытаетесь решить. Решите, какую проблему вы собираетесь решать. Настольное приложение с графическим интерфейсом пользователя, веб-сервер, игра, служебная программа cmd line ... как только вы решите свою проблему, вы сможете лучше решить, какая технология подходит для разработки решения. Я обнаружил, что с помощью «игрушек» ничего не освоишь, поэтому нужно делать что-то реальное.
Возможно, посмотрите проект ooc-lang, упомянутый здесь:
http://attractivechaos.wordpress.com/2009/09/20/oop-in-c-dont-go-too -far /
Есть люди, которые говорят, что вы можете писать объектно-ориентированный код на любом языке, а также есть люди, которые говорят, что вы можете писать ужасно неструктурированный код на любом языке.
Настоящий "объектно-ориентированный" язык предоставляет вам с горсткой механизмов для реализации объектно-ориентированного проектирования: языки имеют встроенные концепции для объектов и / или классов, для инкапсуляции кода с данными, для наследования и т. д. В C практически ничего этого нет, но ничто не мешает вам делать Объектно-ориентированное программирование на C, учитывая некоторые техники и самодисциплину (о чем вам наверняка говорит ваша книга).
Но вы бы захотели?
Мое мнение таково: если вы только учитесь программировать объектно-ориентированный подход, это могло бы быть имеет больше смысла изучать это, будучи «за руку» языком, который уже глубоко включает в себя концепции.Для этого подойдет хорошо структурированный, простой и интерактивный язык: при наличии свободного выбора я бы порекомендовал Ruby, Python или Groovy. Учитывая язык со встроенной «магией» объектно-ориентированного программирования, это становится очень очевидным, когда вы делаете объектно-ориентированные вещи и когда вы просто структурированы, дисциплинированы и хорошо организованы. При переходе с C на другой язык можно также кое-что изучить: общие черты, различия.
Некоторые люди рекомендуют изучать C ++ как естественный объектно-ориентированный прогресс от C. Я не полностью поддерживаю это, потому что считаю C ++ довольно уродливым дополнением возможностей объектно-ориентированного программирования на языке, который уже был более «практичным», чем элегантным. . При переходе от "стандартного" программирования на C к объектно-ориентированному программированию я думаю, что программисту следует подумать о том, чтобы, например, отказаться от прямого управления указателями, и, конечно же, мне было бы обременительно управлять памятью для моих данных. Современные объектно-ориентированные языки автоматизируют это, так что у программиста остается больше клеток мозга для задач более высокого уровня. Конечно, привлекательность C ++ - это чистая скорость. Поскольку он может упасть до того же почти металлического уровня, что и C, он обычно является «самым быстрым» из объектно-ориентированных языков.
Все сказанное: если у вас есть большой проект, где требуемый язык - C, и вы хотите использовать и практиковать методы объектно-ориентированного программирования, тогда продолжайте! В противном случае вы можете извлечь выгоду из изучения объектно-ориентированного подхода в среде, которая поощряет и поддерживает это, и, возможно, позже вернетесь к C со своими знаниями объектно-ориентированного программирования.Тогда методы, изложенные в книге, будут иметь для вас смысл, и вы сможете лучше решить, действительно ли вы хотите делать это на C или на «реальном» объектно-ориентированном языке.