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

N>А какая тогда разница по сравнению с setFoo(getFoo()+1)? Только то, что не знаешь, просто это переменная или что-то иное? Так для этого документация есть.
Ну, кроме того, что очевидно, что setFoo(getFoo()+1) может быть чем-то небыстрым, мы не можем получить указаель на такую штуку, например.

N>Не знаю, это тебя надо спросить. Я никакого find тут не предлагал.
Ну я вообще не понимаю о чём речь, видимо.
Если свойство не объект, а просто группа методов, как-то синтаксически выделенная, ну типа аналог вложенного namespace, то зачем оно вообще надо?
Может таки классы нормально проектировать и не страдать?

N>"Это Спарта!!!" В смысле, это C++.
Дык зачем усугублять-то?

E>>Ну заводишь пачку интерфейсов и вперёд
N>И что? Не понимаю глубокой мысли.

Ну давай ты какой-то пример напишешь как бы было здорово, если бы то, что ты называешь свойствами, было в С++.
Пример класса с такими свойствами + пример использоваия этого класса.
А потом подумаем, может в С++ уже есть какие-то общепринятые способы написанияи таких классов?

N>А это и не объект. Это свойство. Это совершенно другое понятие, и привлекать к нему хоть какую-то логику объекта бессмысленно.
Ну, то есть, например, на него нельзя взять указатеь, скажем?

N>Удобно для программиста. В язык вводят кучу фишек и значительно менее удобных и важных.

imho, С++ достиг такого уровня развития, что самое удобное, для программиста -- это начать выкидывать

Но ты приведи пример кода, как бы оно было, если бы всё уже было. А то пока что не понятно, за что ты воевать-то хочешь.

N>Это всё потому, что вместо поддержки компилятора ты думаешь об извратах, как это всё сделать с теми средствами, что сейчас. Конечно, ничего хорошего не получится.

Да мне просто кажется, что ты хочешь решить какую-то частную проблему. Я правда пока не понял какую. А суть проблем в другом месте лежит.

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

class Master {
//  bla-bla-bla 
    class { 
        //  тут описание
    } slaver;
}

и в slaver я мог бы как-то просто получить this его Master'а
Тогда много всяких хитрых задач решалось бы без хаков...
И что-то очень похожее на проперти ложилось бы тоже хорошо.

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

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

A>>например, имеем код

A>>

A>>struct Foo
A>>{
A>>    int state;
A>>};
A>>

A>>и пару сотен использований токена "state" в исходниках.
A>>надо понять где, как и зачем state меняется, и например добавить туда новый код (в setter)

E>Просто пишем, что это const int state и по списку ошибок компиляции узнаём места...

при этом будут лишние ошибки изза оператора присваивания

E>А твой подход сильно сломается, если на поле берут указатель и куда-то отдают бродить...

таких мест не должно быть вообще.

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

E>imho, С++ достиг такого уровня развития, что самое удобное, для программиста -- это начать выкидывать

зачем выкидывать? че за бред? не хочешь — не юзай.

вообще этото маразм отцов с++ по сохранению совместимости мне не понятен.
в дотнете мне кажется подход с фреймворками самый адекватный.

выпускаем с++ 2.0, который грубо и пошло вращал на .... совместимость с 1.0

все кому ништяки 2.0 не нужны продолжают сидеть на 1.0 — и это правильно
теже кто посовещавший и решив что 2.0 круче и они хотят его ништяки и готовы переписать какой-то % кода, то взвесив все садятся и переводят проект на 2.0 — и это тоже правильно

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


т.е. программеры сами решают нужно им использовать свежую версию или нет, и я думаю 95% спокойно сможет переходить на новые версии,
только очень древние огромные проекты может оказаться нерентабельно переписывть
а из-за того что стандартизаторы с++ застряли в 80-х, эти 95% проектов вынуждены торчать в 80-х вместе с этими старыми пердунами

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


A>>>

A>>>struct Foo
A>>>{
A>>>    int state;
A>>>};
A>>>

A>при этом будут лишние ошибки изза оператора присваивания
не понял. Ты хочешь найти все места модификации поля структуры или что?

E>>А твой подход сильно сломается, если на поле берут указатель и куда-то отдают бродить...

A>таких мест не должно быть вообще.
Почему? Особенно если ссылка константная?

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

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

A>>>>

A>>>>struct Foo
A>>>>{
A>>>>    int state;
A>>>>};
A>>>>

A>>при этом будут лишние ошибки изза оператора присваивания
E>не понял. Ты хочешь найти все места модификации поля структуры или что?

ок, тут const может помочь, если мест где используется поле немного

E>>>А твой подход сильно сломается, если на поле берут указатель и куда-то отдают бродить...

A>>таких мест не должно быть вообще.
E>Почему? Особенно если ссылка константная?

для
public: trivial_type field;
это нарушает инкапсуляцию и связывает время жизни объектов

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

K>только очень древние огромные проекты может оказаться нерентабельно переписывть
K>а из-за того что стандартизаторы с++ застряли в 80-х, эти 95% проектов вынуждены торчать в 80-х вместе с этими старыми пердунами

И что, например, ты бы выкинул?..

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


A>ок, тут const может помочь, если мест где используется поле немного
А если мнооо, то что?
E>>>>А твой подход сильно сломается, если на поле берут указатель и куда-то отдают бродить...

A>>>таких мест не должно быть вообще.
E>>Почему? Особенно если ссылка константная?

A>для
A>public: trivial_type field;
A>это нарушает инкапсуляцию и связывает время жизни объектов

Почему?
например, я могу где-то считать контрольную сумму, и туда скармливать цепочки интов.
одинокий инт -0 это цепочка из одного инта...

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

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

E>И что, например, ты бы выкинул?..

вообще-то я там написал что я не сторонник выкидываний,
я бы скорее переделал некоторые старые вещи и добавил новые

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

K>Здравствуйте, IROV.., Вы писали:

IRO>>Если по существу, то проектируются всегда от интерфейсов
IRO>>любое изменение таких данных влечет за собой измененние состояния,
IRO>>как минимум выставить флаг инвалидации, и в get она проверяется (так называемая линивый пересчет)

IRO>>например setPosition, getMatrix
IRO>>setPosition выставит флаг инвалидации
IRO>>getMatrix пересчитает матрицу только в том случае если данные изменились, в противном вернет as is

K>ну и я про это, я просто не хочу писать то, что и так очевидно: set, get и эти, мать их, скобочки.

K>так я не против изоляции, но я ее намеренно нарушаю потому что меня раздражает писать гет, сет, скобочку сюда, скобочку туда
K>не тока потому что я не люблю писть то что и так очевидно, а еще потому что этот хлам мешает читать код
Я обратного мнения, вообще много кода, это признак того что вы не знаете что писать.

Это как в том выражени "Извини, много написал, было мало времени"

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

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

K>вообще-то я там написал что я не сторонник выкидываний,
K>я бы скорее переделал некоторые старые вещи и добавил новые

Хорошо, что бы ты переделал, и на что?

Я бы, например, написал бы ещё одну стандартную билиотеку, которая не заготовка для написания библиотек, а просто фреймворк для написания программ...

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

_>

_>struct ModelExample2 : SimpleModel {
_>    ModelField<double> g() DECL_FIELD(double,g,9.81);
_>    ModelExample1 submodel1;
_>    ModelExample1 submodel2;    
_>    void Assign(ModelExample2 &src) {
_>        ModelLocker lock(this);
_>        g()=src.g();
_>        submodel1.Assign(src.submodel1);
_>        submodel2.Assign(src.submodel2);
_>    }
_>    ModelExample2() {
_>        AnyChange()<<submodel1<<submodel2;
_>    }
_>    ~ModelExample2() {
_>        AnyChange()>>submodel1>>submodel2;
_>    }
_>};
_>

_>#define DECL_FIELD(type,name,def_val) \
_>    { return ModelField<type>(ScopeChange(),field_##name.val); } \
_>    private: struct field_##name##_t { \
_>        type val; \
_>        field_##name##_t() : val(def_val) {} \
_>    } field_##name; \
_>    public:

На мой вкус этот код выглядит подозрительно. Зачем lock при публичном методе g()? Почему допускается такая операция:

ModelExample2 a;
ModelExample2 b;
a.g() = b.g();

? А если это легально, то зачем тогда нужен lock?

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


E>Я бы, например, написал бы ещё одну стандартную билиотеку, которая не заготовка для написания библиотек, а просто фреймворк для написания программ...

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

1. категорически согласен про стл
2. убрать инклудинг и разделение на .h и .cpp, заменить всё на юзинг
3. добавить метаданные, полный ртти
4. добавить поддержку ABI
5. позволить опционально использовать сборщик мусора, сборщик мусора должен быть при необходимости заменяем на любой кастомный
6. шаблоны — пусть отсаются, если я их не использую, то я почти не чувствую, что они сущесвуют, в общем мне оно не мешает
7. добавить пропертя
6. сделать синтаксическую поддержку нескольких базовых классов, типа IEnumerable для foreach, может не так как управляемых, а по другому, гибче, в общем главное не перестараться
8. ну еще какие-то мелочи синтаксические

для с++ 2.0 я думаю хватит

K>2. убрать инклудинг и разделение на .h и .cpp, заменить всё на юзинг
K>3. добавить метаданные, полный ртти
K>4. добавить поддержку ABI
K>5. позволить опционально использовать сборщик мусора, сборщик мусора должен быть при необходимости заменяем на любой кастомный
K>6. шаблоны — пусть отсаются, если я их не использую, то я почти не чувствую, что они сущесвуют, в общем мне оно не мешает
K>7. добавить пропертя
K>6. сделать синтаксическую поддержку нескольких базовых классов, типа IEnumerable для foreach, может не так как управляемых, а по другому, гибче, в общем главное не перестараться
K>8. ну еще какие-то мелочи синтаксические

Такие языки уже есть. Называются Java, .NET. Превращать С++ в Джаву никакого смысла нет, да и стремно — можно нарваться на патентный иск со стороны Оракла.
А тебе всерьез следует задуматься о смене языка. Судя по всему, С++ не для тебя.

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

V>Такие языки уже есть. Называются Java, .NET. Превращать С++ в Джаву никакого смысла нет, да и стремно — можно нарваться на патентный иск со стороны Оракла.
V>А тебе всерьез следует задуматься о смене языка. Судя по всему, С++ не для тебя.

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

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

V>Такие языки уже есть. Называются Java, .NET. Превращать С++ в Джаву никакого смысла нет, да и стремно — можно нарваться на патентный иск со стороны Оракла.
V>А тебе всерьез следует задуматься о смене языка. Судя по всему, С++ не для тебя.

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

K>язык программирования это не религия и тем более религиозный подход тут неуместен,
Никакой религии тут нет. Не надо пытаться использовать микроскоп вместо молотка, и наоборот. С++ — это инструмент. У него есть своя область применимости. Не надо пытаться превращать его в другой инструмент, другой инструмент уже есть. Не подходит С++ для твоих целей — используй управляемые языки, а С++ оставь в покое. Не надо прикручивать к микроскопу боек, он все равно будет плохим молотком.

K>и если в управляемых языках что-то сделано реально хорошо и оно применимо к неуправляемым то я не вижу никаких причин не внедрить это не только в с++ а вообще во все языки где это может пригодиться
Потому что для разных целей нужны разные инструменты, пойми.

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

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

K>есть целесообразность и эффективность — и всё, больше ничего не имеет значения и поэтому, для меня внедрить в с++ вещи из шарпа и жабы следует не потому, что это будет няшно, а потому что это целесообразно и всё.
А еще ты неправильно понимаешь целесообразность, что, кстати, проистекает от отсутствия любви к технологии. Любовь вообще краеугольный камень, все, что делаешь, надо делать с любовью, иначе будет получаться хреново.

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

K>>язык программирования это не религия и тем более религиозный подход тут неуместен,
V>Никакой религии тут нет. Не надо пытаться использовать микроскоп вместо молотка, и наоборот. С++ — это инструмент. У него есть своя область применимости. Не надо пытаться превращать его в другой инструмент, другой инструмент уже есть. Не подходит С++ для твоих целей — используй управляемые языки, а С++ оставь в покое. Не надо прикручивать к микроскопу боек, он все равно будет плохим молотком.

K>>и если в управляемых языках что-то сделано реально хорошо и оно применимо к неуправляемым то я не вижу никаких причин не внедрить это не только в с++ а вообще во все языки где это может пригодиться
V>Потому что для разных целей нужны разные инструменты, пойми.

K>>а ваш подход, это даже не дремучий консерватизм, это скорее религиозный фундаментализм и он противен мне как стороннику технологического прогресса
V>Прогресс тут вообще не при чем. Молоток — он может и более старый инструмент, чем микроскоп, но это не значит, что все молотки следует заменить на микроскопы.

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

такого нет,

а мне нужен, потому что меня напрягает старческий маразм с++ и тормоза всего и вся в управляемых языках

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

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

K>>есть целесообразность и эффективность — и всё, больше ничего не имеет значения и поэтому, для меня внедрить в с++ вещи из шарпа и жабы следует не потому, что это будет няшно, а потому что это целесообразно и всё.
V>А еще ты неправильно понимаешь целесообразность, что, кстати, проистекает от отсутствия любви к технологии. Любовь вообще краеугольный камень, все, что делаешь, надо делать с любовью, иначе будет получаться хреново.

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

K>по большому мои пожелания скасаются в меньшей степени синтаксиса, чем в инфрастурктуре, так сказать

K>1. категорически согласен про стл
K>2. убрать инклудинг и разделение на .h и .cpp, заменить всё на юзинг
K>3. добавить метаданные, полный ртти
K>4. добавить поддержку ABI
K>5. позволить опционально использовать сборщик мусора, сборщик мусора должен быть при необходимости заменяем на любой кастомный
K>6. шаблоны — пусть отсаются, если я их не использую, то я почти не чувствую, что они сущесвуют, в общем мне оно не мешает
K>7. добавить пропертя
K>6. сделать синтаксическую поддержку нескольких базовых классов, типа IEnumerable для foreach, может не так как управляемых, а по другому, гибче, в общем главное не перестараться
K>8. ну еще какие-то мелочи синтаксические

Почему не использовать C# ?

---

сообщение выше, для меня прозвучало похожим следующему

было бы замечательно добавить в C++:
— нумерацию statement-ов
— убрать контроль типов (а то только жить мешает)
— ну и возможность интерпретации на виртуальной машине

в результате, хочется спросить "Зачем?"
ведь все это уже есть, пользуйся — пожайлуста, в другом языке