A>Бухгалтерия - это предприятие, но это не производство, это обслуга, которая часто мнит себя важнее самого производства  
А>А ошибка в бухгалтерской программе может раззорить предприятие? Ась? 
Не может. Разорить может тупой глав. бух, но не программа, которая напечатает на бумаге неправильные цифры. Неправильные цифры выискиваются, корректируются, пересчитываются и т.п. Физически такая программа ничем не управляет, соответственно ничего не может разрушить.

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

A>Вот интересно, человек читавший Кнута, но не знающий тонкостей работы виртуального деструктора, сколько будет такой код отлаживать?

A>class A
A>{
A>public:
A>  A(){}
A>  ~A(){}
A>};
A>class B
A>{
A>public:
A>  B(){}
A>  ~B(){}
A>};
A>class C:public A, public B 
A>{
A>public:
A>  C(){}
A>  ~C(){}
A>};

A>...

A>A* p1=(A*) new C();
A>B* p2=(B*) new C();

A>...

A>delete p1;
A>delete p2;

A>

A>Ведь вроде "все верно", а падает

A* p1 = new A();
B* p2 = new B();

Бухгалтерия — это предприятие, но это не производство, это обслуга, которая часто мнит себя важнее самого производства

A>А ошибка в бухгалтерской программе может раззорить предприятие? Ась?

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

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

class A
{
public:
  A(){}
  ~A(){}
};
class B
{
public:
  B(){}
  ~B(){}
};
class C:public A, public B 
{
public:
  C(){}
  ~C(){}
};

...

A* p1=(A*) new C();
B* p2=(B*) new C();

...

delete p1;
delete p2;

Играет вокально-инструментальный ансамбль ... а ничего не играет. << RSDN@Home 1.0 beta 3 >>

As a software developer, fixing bugs is a good thing. Right? Isn't it always a good thing?

No!

Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.

These things are hard, but not impossible, to measure. Let me give you an example. Suppose you operate a peanut-butter-and-jelly sandwich factory. Your factory produces 100,000 sandwiches a day. Recently, due to the introduction of some new flavors (garlic peanut butter with spicy Habanero jam), demand for your product has gone through the roof. The factory is operating full-out at 100,000 sandwiches, but the demand is probably closer to 200,000. You just can't make any more. And each sandwich earns you a profit of 15 cents. So you're losing $15,000 a day in potential earnings because you don't have enough capacity.

Building a new factory would cost way too much. You don't have the capital, and you're afraid that spicy/garlicky sandwiches are just a fad which will pass, anyway. But you're still losing that $15,000 a day.

It's a good thing you hired Jason. Jason is a fourteen year old programmer who hacked into the computers that run the factory, and believes that he has come up with a way to speed up the assembly line by a factor of 2. Something about overclocking that he heard on slashdot. And it seemed to work in a test run.

There's only one thing stopping you from rolling it out. There's a teeny tiny wee little bug that causes a sandwich to be mushed once an hour or so. Jason wants to fix the wee bug. He thinks he can fix it in three days. Do you let him fix it, or do you roll out the software in its bug-addled state?

Rolling out the software three days later will cost you $45,000 in lost profits. And it will save you, um, the cost of raw materials for 72 sandwiches. (In either case Jason will get the bug fixed three days later). Well, I don't know how much sandwiches cost on your planet, but here on Earth, they're a lot less than $625.

А>А ошибка в бухгалтерской программе может раззорить предприятие? Ась?

class A
{
protected:
    char szBuff[10];
public:
    A(){};
    void init(char* szBuffIn){strcpy(szBuff,szBuffIn)};

}

//Вот что будет в этом случае )) ?
A a;
a.init("1234567890123456789");

А>Читается. В серьезных проектах. Каждый день перед глазами вижу Разработке уже 25+ лет, кто ее начинал наверно давно на пенсии, без проблем изменяется расширяется итп.

A>>Должно быть достаточно просто обновить базу.

AVK>Не видел ни одного решения где для введения налога с продаж обошлись только обновлением базы.

Назови мне причины, по которым бизнес-логика не должна быть отдельно?
А изменени последней есть фактически изменени базы. Сложнее, но смысла не меняет.

>Гордость это конечно хорошо, но все же надо реально глядеть на вещь. Самомнение тут плохой помощник.