Quote:and are testament to the fact that this community is breeding a generation of scripters.
Whoa there, little buddy...
There are several directions one can take to progress beyond coder or scripter as far as programming goes. These are computer science, software engineering, QA, product management, and similar. They all assume university-grade background.
Many people who ask question here are hobbysts, or approach this from hobbyst perspective, doing things for fun.
Quote:then you're not quite good enough as a programmer to be hired by anyone other than a mobile developer, or possibly a junior position at a semi-decent company.
First, the harsh reality. Knowing to write code, even at guru level, is no longer enough to be hired as anything but intern or junior programmer at any "decent" company. Writing code has become commodity at least 5 years ago.
But the most important issue here is completely missed in this heated "boost is 4 script-kiddies" discussion.
Requirements. Goals.
The process of solving a programming task productively, efficiently and in cost/time-effective manner today looks like this:
- Define the requirements (features) and constraints (hard memory/CPU limits, mostly irrelevant on PC), or define generic functionality if those are not well known.
- Examine existing libraries, language features and available solutions
- Compare each of those, and choose one based on:
-- which one matches all the requirements best with least amount additional features
-- which one is the most supported, and best match for target platform
-- determine the cost of using such a solution (training, installation, deployment, maintenance, support, license cost, documentation, ....)
-- compare the chosen solution to NIH one (design, support, training, deployment, installation, testing, bug-fixing, portability, ...).
It is surprisingly rare for an existing library to cost more than a home invented one. The reason for this is that coders are completely non-critical of how much NIH libraries really cost.
Boost::function problems cliff notes:
- Requires C++. Some projects are still heavily C-based.
- Requires boost. While individual parts can be factored out, that adds extra administration, deployment, testing. Not an issue if project uses boost in entirety
- Double indirection and dynamic memory allocation. Documentation explains why that is needed (obscure corner cases of different compilation units). Both have considerable impact on performance, but it depends solely on the type and number of invocations.
- Maintainability: Both function and bind will be part of new language, but the namespaces will change. (boost, then std::tr1, then ????). Do you account for that, and define their namespace as macros? What if signatures change?
- ::function uses complete run-time polymorphism. This inhibits some optimizations which are possible with less generic implementation. Profiling may indicate this to be a problem in rare situations
- Cost of copying. Non-negligible, needs to be considered when designing a system which relies heavily on b::function as callbacks, such as reactor/actor/pro-actor based concurrency systems.
- Horrible, horrible error messages
Again, before throwing a tantrum over something as trivial, yet in C++ fashion, unfathomably complex and under-defined as function pointers, at least try to focus on actual problems, not just the same old NIH.
The simpler parts of boost, such as function and bind, solve a very common problem. This one is becoming increasingly important as developers migrate from languages such as C#, where delegates are standard feature.
Boost::function defines standard operations and for most represents the concept of least surprise, in much the same way function pointers do for C. In some cases, provided implementation will not be suitable. And *this* is the reason why people still use C++. Because language allows developers to work around such problems, something that is considerably more difficult in managed languages. Just make sure to approach the problem from the right direction. C++ gives the option to redefine, it does not require one to do so. And the need for redefining standard library constructs is increasingly rare.