Will you stop taking your arguments out of context? The OP is obviously not maintaining an existing project, and there's absolutely no reason to start a new project on an old compiler.
Will you stop taking your arguments out of context? The OP is obviously not maintaining an existing project, and there's absolutely no reason to start a new project on an old compiler.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
You don't work in the real world then or, if you do, you work in an environment where you have unfettered control over what products you use. Very few professionals have such control over the projects they work on because the people who pay them do not allow such control. There are plenty of reasons why people start projects with old compilers, including;Originally Posted by CornedBee
1) Organisational policy. If your employer mandates use of a specific compiler, you are putting your job on the line if you use a newer one. A lot of employers (particularly employers with a few thousand employees) do this, in the interests of avoiding a proliferation of different compilers or compiler versions being used in different projects. Such companies do this and do regular but infrequent updates (let's say every 1-2 years). Some very large organisations require that all products (operating systems, compilers, office suites) be tested exhaustively by their IT support offices before being installed on all company machines - because incompatibility between versions is a major issue for organisations with a few thousand employees. Going against organisational policy is a good way to lose ones job.
2) Contractual obligations. If your customer requires compatibility between products produced by different companies, they will often stipulate a specific compiler and compiler version to use in new projects. This is particularly true if you are asked to implement an extension to software that was developed by another company for your customer. It is a waste of a customers time and money to pay you to update the original software so it works with the latest version of your preferred compiler. Instead, they will often (within the contract) provide you with a license to use a compiler that they know the software will build with, and require you to develop new code that works with the old compiler. Importantly, they wil leven do this with some new projects, as one of their end goals is to be able to manage the software configuration after you deliver it, and they use an older compiler in-house .....
You may consider that my arguments are out of context. I consider they are right in context; in the real world, people often have no choice but to use an old compiler when producing a new software product.
Personally, I work in a large organisation that -- as a general rule -- has does not follow the bleeding edge of technology (hardware, compilers, etc) [there are some possible exemptions to that rule, but the arguments required to justify such an exemption require considerable documentary justification and sign-off by very senior management -- so they are rare]. And I regularly place contracts for software development on other organisations, requiring them to honour constraints I operate under.
In practice, at home (when I have complete control over what I am doing) I often use the latest compilers. That includes beta releases, so I regularly submit bug reports to compiler vendors as a result from home. I do not do that at work because it is more practical --- for both myself and my employer --- for me to use slightly older compilers.
Jacqui: the term "100% portable" means different things to different folks.
