Передача ссылки в функцию класса на данный класс

[_Ч_]

В общем да. я там не до конца все понял. вроде переварил.

забудьте про голые массивы. используйте контейнеры из stl.

не именуйте члены класса так же как большинство из программистов именует локальные переменные (я так понял именно поэтому написано this->kolNeuron). Большинсто все таки пишет int m_kolNeuron.

Избавтесь от утечек.

Про всякую безопасность при исключениях я вас парить не стану.

[Impuls1989]

Что будет если два раза позвать ф-ию Create? правильно, будет утечка.

Упс... Уже исправил.

А что будет если я скопирую один обьект CNeuronLayer в другой? Если деструктор написан правильно, то потом может случится трындец.

Ммммда... Действительно проблеемка. Ну тут можно лишь переопределить оператор присваивания...

Ну спасибо и на этом. Будут еще идеи - пишите, я постараюсь быть самокритичным))

[Impuls1989]

используйте контейнеры из stl.

STL - это конечно здорово и красиво, но возникает вопрос с быстродействием. Чем больше проверок, тем медленнее будет работать класс (а в обучение нейронных сетей, к сожалению, - это критично).Так что, по мне, лучше проверить все на фазе создания, чем тысячи раз проверять одно и тоже на фазе обучения...

Я так понял именно поэтому написано this->kolNeuron). Большинсто все таки пишет int m_kolNeuron.

Это да. Но от старых привычек трудно избавиться.

Избавтесь от утечек.

Уже работаю.

[_Ч_]

Вам так кажется. чтобы говорить что стл тратит кучу времени на всякие проверки, надо профилировать программу. Я допускаю, что в том же векторе есть какие-то проверки при его создании, но их вклад в снижение производительности ничножен. Если правильно заюзать вектор, потери будут минимальны в сравнении с голыми массивами. В общем, оптимизация - последнее дело. Хотите разогнать прогу, подумайте над тем, чтобы вместо массива указателей на CNeuron использовать вектор обьектов CNeuron. Избавитесь от одного выделения памяти. CNeuron в таком случае должны уметь копироваться. Копирование CNeuronLayer тоже станет более тяжелым, но скорее всего оно будет таким же, каким вы его напишите вручную. Зато вы избавитесь от геморроя с управлением памятью. Имхо, в таком случае плюшек будет больше.

[Impuls1989]

Сообщение от _Ч_

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

Я полностью с вами согласен, я избавлюсь от большого геморроя с памятью.
Но так ли мал будет вклад проверок? Я конечно не большой знаток stl, но меня все же смущает хотя бы проверка на верные границы.
Допустим у меня будет довольно большая сеть: 100 нейронов во входном слое, 2 слоя по 100..150 нейронов в промежуточных слоях, 20 выходных нейронов. Нейроны соединены каждый с каждым, а значит: 100(входной слой)+100*100(соединение промежуточных слоев)+20(выходной слой)=20020*2 = 40040 (операций чтение/запись за один проход сети). И это если я буду обращаться к каждому элементу лишь один раз. Вот и получается 40000 лишних if-ов прикрутят к моим массивам лишнее время.

[netrino]

Сообщение от Impuls1989

Я полностью с вами согласен, я избавлюсь от большого геморроя с памятью.
Но так ли мал будет вклад проверок? Я конечно не большой знаток stl, но меня все же смущает хотя бы проверка на верные границы.
Допустим у меня будет довольно большая сеть: 100 нейронов во входном слое, 2 слоя по 100..150 нейронов в промежуточных слоях, 20 выходных нейронов. Нейроны соединены каждый с каждым, а значит: 100(входной слой)+100*100(соединение промежуточных слоев)+20(выходной слой)=20020*2 = 40040 (операций чтение/запись за один проход сети). И это если я буду обращаться к каждому элементу лишь один раз. Вот и получается 40000 лишних if-ов прикрутят к моим массивам лишнее время.

Проверка на границы не происходит при обращении через operator[]. Она происходит только при обращении через метод at().
Для начала сделайте рабочую программу, а уже потом занимайтесь оптимизацией, тем более технической

[_Ч_]

operator [] у вектора не проверяет правильность границ. Если вы зададите неверный индекс, то вектор и полезет по этому неверному индексу без всяких проверок. За правильностью границ должена следить вызывающая сторона. А вот для обращения к элементу с проверкой на правильность границы у вектора есть ф-ия at(), которая кидает исключение, если индекс неверный. Так что ваши опасения на счет таких проверок напрасны.

[Impuls1989]

Сообщение от netrino

Проверка на границы не происходит при обращении через operator[]. Она происходит только при обращении через метод at().
Для начала сделайте рабочую программу, а уже потом занимайтесь оптимизацией, тем более технической

Отличное предложение. Так и поступлю)