Slashdot Mirror


Knowing C++ Beyond a Beginner Level

Nerval's Lobster writes: C++ is not an easy language to master, but many people are able to work in it just fine without being a 'guru' or anything along those lines. That being said, what separates C++ beginners from those with 'intermediate' skills, or even masters? According to this Dice article, it comes down to knowledge of several things, including copy constructors, virtual functions, how to handle memory leaks, the intricacies of casting, Lambda functions for C++11, (safe) exception handling and much more. All that being said, is there one particular thing or point that separates learners from masters?

3 of 345 comments (clear)

  1. Re:It's not about knowing, it's about understandin by rippeltippel · · Score: 3, Informative

    so, you claim you know:
    ...
    int a = 13;

    In which register a is residing, supposing we are on an ARM? Or suppose we are in an 68k? Or suppose we are on an x86?

    You are just an idiot!

    I don't claim i know, I claim that I understand: something that you're clearly neither willing nor capable of doing, as your question and offensive language suggest.

    Have a nice day!

  2. Re:Masters know their limitations. by UnknownSoldier · · Score: 4, Informative

    This 100%. C++ has become a clusterfuck of over-engineering and I say that as someone who has worked on a C++ compiler.

    * /Oblg. Comedy: Hitler on C++

    When you have even committee members admit they only use a sub-set then you know the language is too big.

    The C++ committee recognizes there are many problems with C++ iostreams but nothing is being done towards performance and type safety.

    The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

    * http://www.stroustrup.com/mult...

    Crap like long long, "long double", etc. should have been deprecated in year X, and removed in year X+5. Are they going to add "long long long" someday?? Having types like "double" in 2015 is just retarded -- replace it with "float64_t", and the fore mentioned long double with the clear "float80_t". Bandaging the problem like int_fast32_t doesn't solve anything. How many fucking integers types does the compiler need to throw at us?? short, long, long long, int, long int, int_fast32_t, int_least32_t, etc. and I'm not even talking about MS's hacks of __int32, __int64, etc. Simplify the dam language already!!! Set year 2020 as the date when these barbaric types are deprecated, and year 2030 when they are removed.

    Modules have been in a constant state of on-again-off-again for over 10 years:

    * First mention N2073 (Sept.2006)
    * Revived N4047 (May 2014)
    * 2nd draft N4214 (Oct. 2014)
    * 3rd draft N4465 (April 2015)
    * Wording N4466 (April 2015)

    The pre-processor is STILL broken. One would expect #define token operation to work for ALL user-defined tokens. i.e. This isn't rocket science, just a basic Search-and-Replace:

    #define @(func) printf("%s\n",func)
     
    void foo()
    {
      @(__func__);
    }
     
    // Hell, even this should work
    #define @ printf("LOL. Your pre-processor is broken. HA-HA!\n" )

    There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

    The C++ committee failed to learn the first lesson about design:

    * "Needlessly complexity is a symptom of bad design."

    Or paraphrased from Einstein:

    * "Things should be as simple as possible, but no simpler"

  3. Re:Masters know their limitations. by serviscope_minor · · Score: 3, Informative

    This 100%. C++ has become a clusterfuck of over-engineering

    Nope. It's mostly hampered by the need to be backwards compatible. The committee know full well if they make serious breaking changes, then the C++ world will split into two distinct languages. Many, many people won't adopt the new one and the vendors will continue to support them because there's money there.

    It's a blessing and a curse. The curse it it's hard to do anything but add features. The blessing is my code I debugged 13 years ago still works.

    The committee would rather argue over the rare case of multi-dispatch / multi-methods then fix core issues.

    You're basically being an arse. You're picking out one rather speculative paper designed to help C++ stay modern a ways in the future (and somehow labelling this as a bad thing) and yet knowingly ignoring the many papers on fixing core issues.

    Modules have been in a constant state of on-again-off-again for over 10 years:

    Yeah they should just slap in some module crap and if it's wrong, just rip it out and replace it. Who cares about getting things right and not breaking working code, eh? They learned their lesson very hard with export templates and are keen to not have to learn the same lesson again.

    There are no standard pre-processor macros for function names as a string. GCC has the excellent __func__ which Microsoft finally got around to implementing C99 N2340 in Visual Studio 2015!

    So you submitted a proposal, right? Or do you expect other people working for free to magically know your personal problems from your whining on slashdot?

    --
    SJW n. One who posts facts.