Quote:
You mean 4KB? That's function.hpp and bind.hpp combined.

Interestingly my boost/bind.hpp is 58 kB. They also include other headers which in turn probably include other headers.

(Not that one shouldn't use boost, especially if these things make into the SC++L.)

Quote:Original post by nullsquared
I'm sorry to break the news to you, but boost::bind is going to be part of the language (std::tr1::bind). I thought you knew a little about the language.

You mean 4KB? That's function.hpp and bind.hpp combined.

That's why you don't have to decipher the code to use it effectively when it comes to the SC++L and boost.

Lol, you obviously have no idea what you're talking about, and i can't be bothered to spell it all out for you. You've missed my point completely, and are testament to the fact that this community is breeding a generation of scripters.

Quote:Original post by nullsquared
You mean 4KB? That's function.hpp and bind.hpp combined.

When you include function.hpp, that includes iterate.hpp, prologue.hpp, workaround.hpp and functionX.hpp.

iterate.hpp includes dec.hpp, inc.hpp, elem.hpp, size.hpp, cat.hpp, slot.hpp and elem.hpp

prologue.hpp includes functional.hpp, throw_exception.hpp, config.hpp, function_base.hpp, mem_fn.hpp, is_integral.hpp, enum.hpp, enum_params.hpp, cat.hpp, repeat.hpp, inc.hpp and is_void.hpp

I'm going to stop there because i don't have all day, but can you see where this is going? So yes, i think you have no clue of what you're talking about.

Quote:Original post by nullsquared
I'm sorry to break the news to you, but boost::bind is going to be part of the language (std::tr1::bind). I thought you knew a little about the language.

That's why you don't have to decipher the code to use it effectively when it comes to the SC++L and boost.

Both of these comments indicate that you have missed my point or just haven't bothered to read the thread properly. If you want me to re-iterate...

Quote:Original post by thefries
Thats absolutely fine. I also think boost can be a great tool if someone wants to make a small game themselves, but thats where it ends for me.

My comments are based on the point of view that people coming here want to someday work as a professional in the industry, and as such, they will need to know the details on how to implement such things.

If they ask a question about how to implement something, i don't think telling them to use a black box is a good response and as useful as boost can be, i don't find it to be a good learning aid. It's written in a way that makes most professional game programmers cringe. So again, i don't think its a good place to start from when trying to figure out or learn implementation details.

My point isn't about what is in the language or not, its how effective YOU as a coder are. If you can use these libraries, good for you buddie. But just because you can use them doesn't mean you have any idea about how they work or how to write them yourself. If you cant write them yourself, 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.

And yes, you do'nt need to decipher the boost code to be able to use it, but again, thats not my point. My point with that comment is that boost isnt a very good place to look if you want to learn how to write such functionality yourself, because its not easy to follow. Not because its too complex for anyone to understand, its because it looks like its the winning entry in an obfuscation contest.

So again, i think you have no clue of what you're talking about. Thanks for making me waste my time.

Well, 3meg might be 27% of my original 11meg estimate, but its about 76800% of nullsquared's estimate of 4k.

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.

Quote:Original post by nullsquared
I hope you understand that boost is indeed used commercially. A lot. I'm sure any "semi-decent" company will prefer that you use whatever is already in place with their system, be it boost or their own solution, rather than you writing your own just because you're elite enough to know how (and even then I guarentee you it still won't even come near to boost in terms of quality).

I totally agree. But again, thats not my point. My point is that you need to understand how these things work if the code they DO want you to write is to be of high quality and error free.

Quote:Original post by nullsquared
In fact, your comment is of the same magnitude as saying "if you don't know how OpenGL or Direct3D is implemented under the hood, there's no chance you're every getting hired by a 3D developer."

I would almost say you shot yourself in the foot with that one. Given enough time, resources and patience, most people with a good understanding of C or C++ would be able to roll their own such libraries. Not knowing whats hidden in a library is not the same as not knowing how to write whats hidden in a library. And if someone asked "how do i implement a good hardware rasterizer and associated software libraries?" I wouldn't tell them they want to use d3d instead. But the answer to that is way out of the scope of this discussion.