My son was reading for content (Pokemon game guides) before he was reading for pleasure

Er, how is that not for pleasure?

Besides, my point still stands. No one says you must learn to read so you can understand voter registration forms or whatever.

Apparently "many eyes" were not reading that bit of code.

Will you please actually read the quote rather than quoting an inorrect interpretation. The quote is:

"given enough eyeballs, all bugs are shallow"

It means that once a bug is found, it is shallow, i.e. quick and easy to solve for someone. It doesn't and never did mean that all bugs will be found.

Oh gee, and here I thought it meant merge basic blocks.

Nope. As you pointed out yourself it's only a hint to the compiler whether to actually inline or not. When it is not inlined, the symbol has to be weak, because the function may be exported in may object files: which ever object files have a corresponding source file which includes the function.

Therefore all inline really means is "export as a weak symbol".

Do you know _anything_ how C++ compilers even work??

Yes, which is why I know that thing about weak symbols. You apparently do not.

You love to constantly make incorrect and incomplete assumptions.

Well no.

2. Gee, why do things like _Profiling_ exist. The *compiler* doesn't have access to *run-time* performance. The optimizer is dealing with a _subset_ of data. It doesn't know the "function temperature"

Compiling (under gcc) with -fprofile-arcs, running the program generates that information. Recompiling with -fpbranch-probabilities then tells the optimizer to use the run-time information. That said, I don't think function temperature has much to to with whether to inline or not.

1. I want to write ONE directive not clutter my code up with hacks PER compiler. _Why_ do standards exist ? To make everyone's live _easier_.

And anyway, you still ignored my point. The committee have standardised function attributes, which is 95% of the way towards having what you want. Write a proposal to add force_inline as a standard attribute.

So Verizon accepted a fine of $5,000,000. For Verizon, I call that a success. Given their size nothing at all is going to cost them less than 5 million. There is no way in hell that investigations into rural phone problems would have cost less.

This is just the cost of doing business, and it's certainly more profitable to break the law and pay the fine than it is to do what they are supposed to do.

Until the fines are set to a level to remove all profit and THEN put a punishment on top, large business will continue to flout the law because it's more profitable.

Do you _actually_ use different compiles on different platforms at all ????

Yep.

'inline' is only a hint

Inline specifically means "export this as a weak symbol".

I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.

Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.

Nonetheless you're ignoring the other part of the reply that the C++ committe has in fact standardised a way of specifying attributes. Why don't you submit a paper specifying some always inline attribute?

You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...

You wishing something to be the case dosen't make it happen. Unlike your silly car analogy, there is no government body who will arrest and detain anyone using C++98 after some flag day. As a result it will cause fragmentation just like Python 3.

Gee, why does Microsoft provide a _specific_ number for _each_ warning ???

Uh? Again, there is no language where error messages are standardised. The fact that MS provides numbers for each one is a total red herring. Like I said, complaining that the C++ committee have their heads up their arses because they're not standardising something that no other language spec ever standardised is basically idiotic.

But now you've wandered into bizarro world with warnings. So what would the procedure be? The warnings which a compiler is capable of emitting depend quite strongly on the code analaysis part which is in part dependent on the optimizer. There is no way to get GCC, LLVM, VS and ICC to have exactly the same set of warnings. And then what would the procedure be for new warning?

Seriously, the standards committee cannot make something happen by magic. If they try to do something that no one is going to implement then it's a pointless and destructive waste of time. They learned their lesson very well with exported templates. All sorts of people begged and whined for it, so they did it. They didn't listen to the howls of anguish from the compiler writers. All that happened was a dead stub of a standard which almost no compilers ever supported.

This is a solution in search of a problem.

So you're saying that the C++ commitee shouldn't be reading and considering every proposal that is submitted according to the correct procedures? So how should they filter them? Ask you and see if you give the thumbs up?

1. Completely failing to understand _practical_ matters.

Says the person who believes that by magic the C++ committee can make everyone switch to a new, incompatible language and avoid fragmentation! That's about the biggest practical matter and you claim outright that it doesn't exist. Then you rather hilariously accuse me of not understanding the practicalities.

OK, smart-ass, how would you force everyone to switch to a future non-backwards compatible version?

2. Continue to make excuses for why their tools are crap.

Tools are crap for reasons you haven't mentioned: namely it's sodding hard to parse C++. Because of (1) the committee can't fix that. But again, the OP complained that the "committee have their heads up their asses", which is a foolish and ignorant statement. There hasn't ever been a language standard which specifies the kind of tooling he was asking for.

And tools have nothing to do with the language standard.

3. And then post blatantly false information that gets modded up to Insightful without a clue.

Except nothing I said was false.

Scools and education are mighty bizarre places.

There's weird emphasis on useful things except where there isn't.

No one pretends that literary criticism is a useful skill, or that reading books is anything other than entertainment. Yet it is taught. Likewise, History is only needed if you're going to teach history, but it's taught because knowing history is part of being a well rounded person.

Apparently things that can be technical have to be useful.

Personally I think programming should be taught in schools along with maths, English, history, "building stuff" (DT in the UK), sciences, foreign languages and etc.

Not becauese is useful.

It should be taught, like the other subjects because it is interesting and can teach one to think in new ways that other subjects don't teach---just like all the other subjects[*]. Not everyone will like it and some will and most won't go on to use it. But writing is taught even though most people woll never go on to write a book.

[*] It's arguable that the other subjects do that, but that has more to do with how badly the subjects are taught than anything inherent to them.

Odd. In my experience, the people who insist you need a 'special mind' to code are deeply insecure people with no other skills.

eh. I think one does, but not in the way many people mean. I think "young" or "not already messed up" is the specialness required. An alternative interpretation is that "special" means "attuned to the way most teaching is done". If of course you only do teaching in that way then it tautologically does in fact require a special mind.

At school (age 13), my school rather unusually had programming classes in BBC Basic. Most people were crap but almost everyone was able to get a basic text based adventure up and running. In other words, more or less everyone was able to write some really simple code of their own.

Fast forward too many years to when I was teaching programming to undergrads.

Some of the students, who were orders of magnitude smarter that the people who managed basic programming in my school by almost any way of thinking really, really, REALLY struggled. What seemed to be the problem was that any high level language requires an awful lot on trust. Some of those sutdents responded much better to ASM programming, especially given a databook which documented every aspect of the microcontroller in incredible detail. Once that was sorted, explaining a higher level language in terms of how it would translate into ASM seemed to be very helpful.

Whether the insurance companies should be allowed to do that to you is the real root question which we need to answer.

Sure. Why not? Commercial drivers spend a *lot* more time on the road, so they're much more likely to need to call in the insurance. Non-commercial insurance is substantially cheaper.

Why should taxi drivers need commercial licenses either?

Higher standards? Many jursdictions ensure things like ahigher standard of driving, limited working hours, provision of adequate insurance, background checks for certain criminal activity and so on.

I like being able to buy a random electrical device and be reasonably sure because of regulations that it it nulikely to burst into flames. Likewise I like being able to order random taxis with good liklihood that I won't get a criminal, nuinsured, sleep deprived nutter.

Well that just sounds like mean-spirited carping. This for example is demonstrably not true:

And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed.

The committee process is very open and one can see how it works. and it doesn't work like that. And it certainly doesn't have every feature: most proposals get rejected.

Fortunately most C++ compilers use the EDG front-end to handle all the crap of template parsing.

Except the three most popular: GCC, LLVM and Visual Studio.

Really? I think the GOF should be round-up and shot. No other group has caused more harm to the industry.

Nope. I was trying t othink of an analogy but I'm stumped. The GoF wrote a nic book documenting ang giving standard names to a bunch of stuff people were already doing. It gave us a nice standardised vocabulary to talk about existing things. It was very much a descriptive book.

Then untoled nutcases decided it was *proscriptive* and used every bloody pattern they could remember in every piece of code. Blaming the GoF for that is like blaming wikipedia for someone losing a finger because they have an article on band saws.

What was lacking was the courage to drag programmers away from C rules and conventions enough to create a simple and powerful OO language.

lol

Lacking courage.

Don't foolishly insult the creator of the language with such historically ignorant and ill-thought out comments. There are hundreds of morbiund, obscure and unpopular languages for people who wanted to wean people off C. Nobody lacked the courage: hundreds of people have tried.

I'm sorry but the C++ committee has their head up their @$$es for *practical* matters:

Says the guy who doesn't understand the C++ committee. The C++ committee care very strongly about backwards compatibility, because so does everyon who uses C++. They also care very strongly about compiler adoption because, well, if the compilers don't adopt changes then no matter how much better it is in theory, it's worse than useless in practice.

* Standardized Name Mangling?

Would be nice, but would cause major backwards compatibility breakage because all but one compiler would have to change the magling scheme.

* Standardized ABI so compiler A can call code compiled with compiler B

Well, GCC won't adopt Microsoft's SEH, because they're slower. Microsoft won't adopt the Itanium ABI, because it would slaughter backwards compatibility and the faster exceptions aren't flexible enough to do what Microsft uses their exceptions for.

Secondly, if they'd mandated this, we'd have never got a huge boost in exception speed somehwere when gcc 3 came online.

But basically, it would be worthless because the compiler writers wouldn't adopt it. So why bother?

* Standardized error messages

Easy to ask for, almost impossible to specify. Do the error messages have to be in colour or is that optional? Besides it's foolish to claim they have their heads up their asses for not doing something that noone else has ever done.

* Standardized pragmas to enable/disable warnings for unused variables

What? Why?

* Standardized forced inline, never inilne

Again why?

* A consistent grammar between forward declarations and function definitions to make it easier to copy/paste

Nope. Never going to break backwards compatibility. Because no one would adopt the new standard.

* Multi-column debugging instead of the archaic line debugging

Outside the scope of the standard. Whine at your debugger vendor.

*"A Proposal to Add 2D Graphics Rendering and Display to C++"

The C++ committee have their heads up their asses because they discuss a proposal submitted acording to the correct procedure??

*For high performance games, most of the C++ features are *ignored* "CppCon 2014: Nicolas Fleury "C++ in Huge AAA Games"

So your argument against C++ is that it's used in one of the most competitive industries? You know, you don't have to use every langage feature in every project.

Yes, RAII is nice. But only *some* memory and resource leaks go away, basically the ones which are trivial, because allocation and deallocation simply follow lexical scope. Ofcourse, this is only trivial in languages which do not have exceptions. Exceptions make this simple thing very complicated, and without RAII it is indeed almost impossible to avoid resource leaks in C++. But without exceptions, it is not so much of a deal. In other words, RAII had to be invented after the fact to make exceptions usable in C++ because - again - some feature were introduced without much thought.

That is complete and utter rubbish: you completely misunderstand RAII. shared_ptr escapes lexical scope and is reference counted. Provide you never have cyclic mutable graphs, you are *guaranteed* not to leak resources with RAII.