Я как обычно излагаю Delphi понятия, но вроде на C++ должно быть всё очень похоже. Если не ошибаюсь, в C++ есть динамические классы, которые корректно называть собственно классами, и статические классы, аналогом которых в Delphi являются рекорды?
Часто возникает выбор — оборачивать ли какую-то сущность а класс или рекорд. Я обычно делаю рекорд из всего, что не требует никакого динамического выделения памяти. Например у меня есть рекорд tvector, включающий в себя три числа x, y, z. Для разных операций с векторами вроде вычисления длины вектора, сложения, умножения и т.д. я пишу функции (какие-то в виде собственных функций рекорда, какие в виде просто функций). Делать из векторов класс было бы весьма неудобно, т.к. надо их будет каждый раз инициализировать и финализировать, а с рекордом я могу написать vector2:=vector1.
Но везде, где появляются динамические массивы и строки, обычно мне кажется удобнее создавать класс. У класса есть три базовых функции, которые надо проверять и править каждый раз, когда я что-то в него добавляю: конструктор, деструктор и ассигн. В Delphi нет и видимо в принципе не может быть полностью безглючного присвоения data2:=data1 с такими рекордами, поэтому надо делать data2.assign(data1).
Собственно к рекорду тоже можно прикрутить ассигн, но мне интуитивно кажется что это всё не есть удачные решения. Тут главный момент — передача данных в произвольных функциях. С классами всё понятно и удобно, потому что я всегда знаю что переменная класса — это указатель, соответственно если например класс передаётся как параметр какой-то функции, я точно знаю что перед её вызовом был вызван конструктор класса, а после будет вызван деструктор. С рекордами, если они содержат что-то динамическое, приходится передавать данные в функциях через var, и я плохо осознаю, например, не будет ли лишних проблем, если переменную с var передать как var ещё одной подпрограмме, может быть рекурсивной.
С классами меня естественно раздражает их медленность по сравнению с рекордами, плюс то что классы хранят какую-то дополнительную информацию вроде названия класса или таблицы виртуальных методов, а это ещё тормоза. В Delphi нет быстрых классов без этого? Если нет, может я когда-то дозрею до того, что начну активно использовать указатели к рекордам. Но может быть я слышал что использование указателей в современном программировании считается моветоном, вроде безусловных переходов?
Сишники, вам понятны эти дельфистские заморочки, или у вас как-то по-другому?

Здравствуйте, Khimik, Вы писали:

K> В Delphi нет и видимо в принципе не может быть полностью безглючного присвоения data2:=data1 с такими рекордами, поэтому надо делать data2.assign(data1).

Очередной камингаут: "Я не знаю и не хочу знать язык!"?

Мне тут написали, что недостаток C++ по сравнению с Delphi заключается в том, что в C всё время есть типа свобода или неопределённость — в стеке или в куче создать объект, и это сбивает с толку. В подавляющем случае ООП-нутые объекты надо создавать именно в куче, и в Delphi с классами всегда именно так. Обычно нет особого труда переписать программу, которую начал делать в структурном стиле, чтобы получился ООП-нутый подход.
Во многом написанное верно потому, что ООП-нутые объекты часто полиморфны.

Здравствуйте, Khimik, Вы писали:

K>Я как обычно излагаю Delphi понятия, но вроде на C++ должно быть всё очень похоже. Если не ошибаюсь, в C++ есть динамические классы, которые корректно называть собственно классами, и статические классы, аналогом которых в Delphi являются рекорды?

Либо дельфи — это что-то очень странное, либо ты несешь какую-то пургу.

В C++ нет никаких динамических и статических классов. class и struct — по сути одно и то же, только видимость членов по умолчанию разная, и режим наследования по дефолту отличается.


K>Часто возникает выбор — оборачивать ли какую-то сущность а класс или рекорд. Я обычно делаю рекорд из всего, что не требует никакого динамического выделения памяти. Например у меня есть рекорд tvector, включающий в себя три числа x, y, z. Для разных операций с векторами вроде вычисления длины вектора, сложения, умножения и т.д. я пишу функции (какие-то в виде собственных функций рекорда, какие в виде просто функций). Делать из векторов класс было бы весьма неудобно, т.к. надо их будет каждый раз инициализировать и финализировать, а с рекордом я могу написать vector2:=vector1.
K>Но везде, где появляются динамические массивы и строки, обычно мне кажется удобнее создавать класс. У класса есть три базовых функции, которые надо проверять и править каждый раз, когда я что-то в него добавляю: конструктор, деструктор и ассигн. В Delphi нет и видимо в принципе не может быть полностью безглючного присвоения data2:=data1 с такими рекордами, поэтому надо делать data2.assign(data1).
K>Собственно к рекорду тоже можно прикрутить ассигн, но мне интуитивно кажется что это всё не есть удачные решения. Тут главный момент — передача данных в произвольных функциях. С классами всё понятно и удобно, потому что я всегда знаю что переменная класса — это указатель, соответственно если например класс передаётся как параметр какой-то функции, я точно знаю что перед её вызовом был вызван конструктор класса, а после будет вызван деструктор. С рекордами, если они содержат что-то динамическое, приходится передавать данные в функциях через var, и я плохо осознаю, например, не будет ли лишних проблем, если переменную с var передать как var ещё одной подпрограмме, может быть рекурсивной.

По-моему, ты и дельфи как-то очень хреново знаешь


K>С классами меня естественно раздражает их медленность по сравнению с рекордами, плюс то что классы хранят какую-то дополнительную информацию вроде названия класса или таблицы виртуальных методов, а это ещё тормоза. В Delphi нет быстрых классов без этого? Если нет, может я когда-то дозрею до того, что начну активно использовать указатели к рекордам. Но может быть я слышал что использование указателей в современном программировании считается моветоном, вроде безусловных переходов?

Классы не могут быть медлительными сами по себе. Вся медлительность — это следствие криворукости. Либо объективная реальность, но и с рекордами тогда тоже самое будет.


K>Сишники, вам понятны эти дельфистские заморочки, или у вас как-то по-другому?

Нам прежде всего непонятно, что за бреда ты тут налил

Здравствуйте, Khimik, Вы писали:

K>Мне тут написали, что недостаток C++ по сравнению с Delphi заключается в том, что в C всё время есть типа свобода или неопределённость — в стеке или в куче создать объект, и это сбивает с толку.

Чего тут может сбивать с толку?


K>В подавляющем случае ООП-нутые объекты надо создавать именно в куче,

С чего бы? Куча нужна, когда время жизни объекта не совпадает со скопом функции, в которой он создаётся/используется.


K>и в Delphi с классами всегда именно так.

Если так, то это криво


K>Обычно нет особого труда переписать программу, которую начал делать в структурном стиле, чтобы получился ООП-нутый подход.
K>Во многом написанное верно потому, что ООП-нутые объекты часто полиморфны.

Тут перестал понимать этот поток

Здравствуйте, Marty, Вы писали:

M> K>и в Delphi с классами всегда именно так.

M> Если так, то это криво

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

Здравствуйте, rudzuk, Вы писали:

M>> K>и в Delphi с классами всегда именно так.

M>> Если так, то это криво

R>Не криво. Возможность разместить объект на стеке есть, но... Оно просто нахрен никогда не нужно Напомню, первоначально, еще во времена Турбо Паскаля, объектная модель была совсем другой, аналогом плюсовой. В Delphi она была переосмыслена (взвешена, измерена и признана негодной) и в настоящее время оставлена только для обратной совместимости, а новая модель является ссылочной (т.е. да, без некоторых приседаний объект на стеке не разместить).

Что может быть проще и дешевле размещения объекта на стеке? Если для этого надо приседать, то это криво. А "оно просто нахрен никогда не нужно" — ненужно видимо потому, что надо приседать. В плюсах это первейший способ

Здравствуйте, Marty, Вы писали:

M> R>Не криво. Возможность разместить объект на стеке есть, но... Оно просто нахрен никогда не нужно Напомню, первоначально, еще во времена Турбо Паскаля, объектная модель была совсем другой, аналогом плюсовой. В Delphi она была переосмыслена (взвешена, измерена и признана негодной) и в настоящее время оставлена только для обратной совместимости, а новая модель является ссылочной (т.е. да, без некоторых приседаний объект на стеке не разместить).

M> Что может быть проще и дешевле размещения объекта на стеке? Если для этого надо приседать, то это криво. А "оно просто нахрен никогда не нужно" — ненужно видимо потому, что надо приседать. В плюсах это первейший способ

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

Здравствуйте, rudzuk, Вы писали:

M>> Что может быть проще и дешевле размещения объекта на стеке? Если для этого надо приседать, то это криво. А "оно просто нахрен никогда не нужно" — ненужно видимо потому, что надо приседать. В плюсах это первейший способ

R>Так и в Турбо Паскале это был первейший способ Но оно показало свою ненужность на практике. Сколь нибудь сложные объекты все равно не обходятся без динамического распределения памяти, а что-то мелкое нет смысла оформлять в объект, когда есть другие способы выражения И, как я уже сказал, старая модель доступна, вот только никем не используется (что еще раз подтверждает тезис о ненужности).

Странные у вас дельфячей практики, что тут ещё можно сказать


R>Да и в новой из приседаний только пару методов переопределить

Но тогда его нельзя будет создавать в куче, я правильно понимаю?

Здравствуйте, Marty, Вы писали:

M> R>Да и в новой из приседаний только пару методов переопределить

M> Но тогда его нельзя будет создавать в куче, я правильно понимаю?

Смысл такой: у тебя есть класс TMySuperObject, если ты хочешь разместить его на стеке, то делаешь потомка TMySuperObjectOnStack с парой переопределенных методов. Пользуешься в зависимости от необходимости либо тем, либо другим. Знаешь сколько раз я такое видел? Нисколько. Размещение динамических массивов (!) на стеке видел, а вот объектов — нет. Нет практического смысла

Здравствуйте, rudzuk, Вы писали:

M>> R>Да и в новой из приседаний только пару методов переопределить

M>> Но тогда его нельзя будет создавать в куче, я правильно понимаю?

R>Смысл такой: у тебя есть класс TMySuperObject, если ты хочешь разместить его на стеке, то делаешь потомка TMySuperObjectOnStack с парой переопределенных методов. Пользуешься в зависимости от необходимости либо тем, либо другим.

Пипец у вас там костыли


R>Знаешь сколько раз я такое видел? Нисколько. Размещение динамических массивов (!) на стеке видел, а вот объектов — нет. Нет практического смысла

Потому и не видел, что это головняк на ровном месте, и такой хернёй заниматься в здравом уме никто не будет, проще в куче создать, а то, что это лишнее обращение к менеджеру памяти — а когда дельфисты думали об оптимальности своих программ?

Здравствуйте, Marty, Вы писали:

M> R>Смысл такой: у тебя есть класс TMySuperObject, если ты хочешь разместить его на стеке, то делаешь потомка TMySuperObjectOnStack с парой переопределенных методов. Пользуешься в зависимости от необходимости либо тем, либо другим.

M> Пипец у вас там костыли

Наоборот — идеальная ситуация для ООП. Отнаследовался, модифицировал, получил новую функциональность.

M> R>Знаешь сколько раз я такое видел? Нисколько. Размещение динамических массивов (!) на стеке видел, а вот объектов — нет. Нет практического смысла

M> Потому и не видел, что это головняк на ровном месте, и такой хернёй заниматься в здравом уме никто не будет, проще в куче создать

Да нет там никакого головняка. Можно вообще дженерик написать для этого и все. Просто не нужно

M> а то, что это лишнее обращение к менеджеру памяти — а когда дельфисты думали об оптимальности своих программ?

Был один клоун, рассказывал мне, как неэфективно располагать объект потока в куче. Не учел одного — через этот объект с диска поднимались сотни мегабайт Не уподобляйся.

Здравствуйте, rudzuk, Вы писали:

R>Размещение динамических массивов (!) на стеке видел, а вот объектов — нет. Нет практического смысла

Потому что в Дельфи деструкторы не вызываются автоматически. Всё вручную.
А в плюсах именно гарантированность вызова деструктора при выходе из скоупа -- краеугольный камень.

Здравствуйте, K13, Вы писали:

K13> R>Размещение динамических массивов (!) на стеке видел, а вот объектов — нет. Нет практического смысла

K13> Потому что в Дельфи деструкторы не вызываются автоматически. Всё вручную.
K13> А в плюсах именно гарантированность вызова деструктора при выходе из скоупа -- краеугольный камень.

Это ортогонально месту размещения объекта

Здравствуйте, rudzuk, Вы писали:

R>Был один клоун, рассказывал мне, как неэфективно располагать объект потока в куче. Не учел одного — через этот объект с диска поднимались сотни мегабайт Не уподобляйся.

Подмена тезиса

Здравствуйте, wander, Вы писали:

w> R>Был один клоун, рассказывал мне, как неэфективно располагать объект потока в куче. Не учел одного — через этот объект с диска поднимались сотни мегабайт Не уподобляйся.

w> Подмена тезиса

Нет, ты!