Welcome, Guest. Please login or register.

Author Topic: C vs C++ ... or whatever language  (Read 20923 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Daytona675x

  • Newbie
  • *
  • Join Date: Oct 2014
  • Posts: 46
    • Show only replies by Daytona675x
    • http://www.goldencode.de
Re: C vs C++ ... or whatever language
« Reply #29 on: February 10, 2018, 11:00:00 AM »
@Einstein
Well, the whole C/C++ syntax is pretty perverted...
Actually I find the &-reference-syntax to be quite consistent with other C syntax madness ;) (e.g. try to explain the * madness to a C (or C++) student :P )
It's just a matter of getting used to it, some practice, nothing else.
AmigaOS 4.1 FE (sam440ep, sam460ex, X5000, Tabor,  R200 / RadeonHD), MorphOS 3.9 (PowerMac G4 733MHz R200), AROS (x86), A1200 (060 80MHz Indivision MK2), A600 Vampire2 / Furia, A500, CDTV
[Dev Videos][Facebook][Old Wings Development Diary]
 

Offline Einstein

  • Sr. Member
  • ****
  • Join Date: Dec 2004
  • Posts: 402
    • Show only replies by Einstein
Re: C vs C++ ... or whatever language
« Reply #30 on: February 10, 2018, 12:21:10 PM »
Quote from: Daytona675x;835989
@Einstein
Well, the whole C/C++ syntax is pretty perverted...
Actually I find the &-reference-syntax to be quite consistent with other C syntax madness ;) (e.g. try to explain the * madness to a C (or C++) student :P )
It's just a matter of getting used to it, some practice, nothing else.


Yes, both '*' and '&' already serve more than 1 usage, references only add yet another usage to '&'.
I have spoken !
 

Offline kamelito

Re: C vs C++ ... or whatever language
« Reply #31 on: February 10, 2018, 02:51:39 PM »
@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?
« Last Edit: February 10, 2018, 02:56:33 PM by kamelito »
 

guest11527

  • Guest
Re: C vs C++ ... or whatever language
« Reply #32 on: February 10, 2018, 03:06:24 PM »
Quote from: kamelito;835995
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

Unfortunately, that seems to be correct and fits my experience. There is the Stroustrup, but even though it is the standard reference, I would not generally recommend the book because it is too big and tries to be too much at the same time. There are certainly very good C++ books around (I liked "Exceptional C++" by Herb Sutter a lot), but not a single one that covers all of C++ and that is "entry level". Probably because there is more than one way how a good C++ program may look like, and there is more than one way how C++ can be ideally used.

Concerning the STL: I also tend to agree, despite people advocating it. I find the STL bulky, and needlessly hard to use, and prefer my own data structures. But this is probably only a "me" thing, and because C++ makes it so easy to come up with your own structures. For example, in Java, I happily use the standard java classes like ArrayList and friends.

My C++ style looks more like "C with classes plus template-enabled super-powers". But that is exactly what I like about the language: Nobody forces me to use the parts of the language that do not quite fit to my application domain (which is, these days, mostly image processing/signal processing related).
 

Offline Daytona675x

  • Newbie
  • *
  • Join Date: Oct 2014
  • Posts: 46
    • Show only replies by Daytona675x
    • http://www.goldencode.de
Re: C vs C++ ... or whatever language
« Reply #33 on: February 10, 2018, 03:31:02 PM »
@kamelito
Quote
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer
You are wrong if you think that the one (shipping successfully) must have any relationship to the other (being a good or bad C++ programmer / the game's code quality (and I know exactly what I'm talking about :P )).
Again: if somebody claims that it's the fault of the programming language XYZ that he didn't get his job done in time, then that's a very very strong indication that this guy simply is no good in language XYZ or that he chose the wrong tool for the job in the first place (which also makes him a non-expert for XYZ automatically) or that the true reasons are others.

Quote
It seems that not a single C++ book did a good job teaching how to program properly in C++
You simply picked the wrong books it seems.
To get you started pretty much any C / C++ for dummies book should do.
After you have practiced and have become more or less familiar with it, then I recommend the following pretty thin and to the point books:
"Effective C++" line of books by Scott Meyers. If you understood those, then go for
"Modern C++ Design" by Alexandrescu and finally
"C++ Templates" by Vandevoorde / Josuttis.
Those guys really know what they are talking about!
Yes, some of those books / chapters are tough stuff, without doubt. But that's how it is with a language that offers such a high amount of features and possibilities to exploit. It's no Kindergarten, and if you think that you can master C++ just like that, then you're mistaken.

Quote
Why big games companies need to wrote their own STL implementation to have good performance?
Most likely most of them don't.
However, the STL is made to be a standard for every day use. Which also means it is made to perform well in the avg. usecase.
It's a shoe that should fit okay, it's not a shoe that you can expect to always fit *perfectly*, especially not in corner cases or your very very specific scenario X.
But actually it's in *no way* different with the C standard library, e.g. the whole 0-terminated-C-string functions: okay for small stuff, but insanely slow and inefficient in other usecases. Or qsort: okay for many cases, but useless as soon as you need a stable sort (yes, yes, before somebody starts nitpicking: it's an example and I asume that you cannot just make the comparison function stable :rolleyes: ).
« Last Edit: February 10, 2018, 03:33:37 PM by Daytona675x »
AmigaOS 4.1 FE (sam440ep, sam460ex, X5000, Tabor,  R200 / RadeonHD), MorphOS 3.9 (PowerMac G4 733MHz R200), AROS (x86), A1200 (060 80MHz Indivision MK2), A600 Vampire2 / Furia, A500, CDTV
[Dev Videos][Facebook][Old Wings Development Diary]
 

Offline Mr_Capehill

  • Full Member
  • ***
  • Join Date: May 2002
  • Posts: 189
    • Show only replies by Mr_Capehill
Re: C vs C++ ... or whatever language
« Reply #34 on: February 10, 2018, 08:19:46 PM »
Quote from: kamelito;835995
@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?


Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...
 

Offline Mr_Capehill

  • Full Member
  • ***
  • Join Date: May 2002
  • Posts: 189
    • Show only replies by Mr_Capehill
Re: C vs C++ ... or whatever language
« Reply #35 on: February 10, 2018, 08:23:04 PM »
Quote from: Daytona675x;835998

"Effective C++" line of books by Scott Meyers. If you understood those, then go for
"Modern C++ Design" by Alexandrescu and finally
"C++ Templates" by Vandevoorde / Josuttis.


Yay for mentioning Scott Meyers! Can't go wrong with his advice.

Check also ETL: https://github.com/ETLCPP/etl
 

Offline Hans_

Re: C vs C++ ... or whatever language
« Reply #36 on: February 10, 2018, 08:57:56 PM »
Quote from: kamelito;835995
@Dayntona, Hand & Thor
I don t think That shipping successfully 2 games like Braid and The Witness make him a bad C++ programmer. Check his YouTube channel or better ask him directly on Twitter.
It seems that not a single C++ book did a good job teaching how to program properly in C++. Who need a phone book size one to just scratch the surface? Why big games companies need to wrote their own STL implementation to have good performance?

In no way was I slagging off any particular developer's skill. I simply disagree with claims that C++ is so horrible that people "suffer from" it.

I'm sure that Jon Blow is a competent programmer, and I like his games (got The Witness). I also wish him well with developing his own programming language. After taking a quick look at his new language, it's pretty clear that he's spent some time tinkering with Haskell...

He may well be able to make some innovative improvements over existing languages, creating one that suits his programming style and game development well. However, like every programming language ever written, it's highly likely that his language will solve the shortcomings that frustrated him with other languages, but end up with a new set of compromises and limitations. Others will get frustrated with how it can't do certain things they want as easily as they'd like, and they'll start dreaming about creating their own programming language...

Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
 

guest11527

  • Guest
Re: C vs C++ ... or whatever language
« Reply #37 on: February 10, 2018, 09:31:14 PM »
Quote from: Mr_Capehill;836009
Something like std::vector is as fast as the C array.

Actually, when I tested, it was not. There is another layer of indirection, and at least the GNU C++ compiler is not good at removing the overhead even in optimized mode. There is also the "valarray", but that is neither any faster. Yes, it almost all cases it does not matter. But if you do raw signal processing, then the best C++ offers you is the raw pointer (well, except if you have compiler intrinsics for vectorized operations, of course), and this particular case, it does matter.

The C++ vector shows also what I do not like about the STL. If I would design a library, then operator[] of the vector would be range-checked by default, there would be no "at" function (which is range-checked). In optimized mode, the range-change would disappear, and it would run into an assert in debug mode if I'm out of bounds, but it would not throw an exception. What is not right here is that the default mode is "unsafe", and that "exceptions" are used to capture "programming defects" for which we have assertions, and that checked/unchecked is a decision of the function, but not of the compilation mode.
 

Offline nicholas

Re: C vs C++ ... or whatever language
« Reply #38 on: February 10, 2018, 09:32:27 PM »
@Kamelito

A good workman never blames his tools is as true today as it was in the bronze age.
“Een rezhim-i eshghalgar-i Quds bayad az sahneh-i ruzgar mahv shaved.” - Imam Ayatollah Sayyed  Ruhollah Khomeini
 

Offline kamelito

Re: C vs C++ ... or whatever language
« Reply #39 on: February 10, 2018, 11:04:05 PM »
Quote from: Mr_Capehill;836009
Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...


Performance was the reason, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
 

Offline kamelito

Re: C vs C++ ... or whatever language
« Reply #40 on: February 10, 2018, 11:06:14 PM »
Quote from: Mr_Capehill;836009
Which game companies rewrite the STL lib in 2015-2018? What exactly was the reason?

Something like std::vector is as fast as the C array.

C++ is a complex topic, that cannot be denied. But C++ today is also quite different to what it used to be. Check constexpr, auto, unique_ptr and ranged-for...


Reasons explained in the link below, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
 

Offline bison

  • Jr. Member
  • **
  • Join Date: Dec 2007
  • Posts: 59
  • Country: 00
    • Show only replies by bison
Re: C vs C++ ... or whatever language
« Reply #41 on: February 10, 2018, 11:59:30 PM »
Quote from: kamelito;835918
https://www.youtube.com/watch?v=rX0ItVEVjHc
https://www.youtube.com/watch?v=443UNeGrFoM

Thanks for that second link; I probably never would have found it otherwise.
"Unix is supposed to fix that." -- Jay Miner
 

Offline Mr_Capehill

  • Full Member
  • ***
  • Join Date: May 2002
  • Posts: 189
    • Show only replies by Mr_Capehill
Re: C vs C++ ... or whatever language
« Reply #42 on: February 11, 2018, 08:16:29 AM »
Quote from: kamelito;836016
Performance was the reason, EA for example their implementation is now open source.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html


Posted in 2007.

But hey, the more the merrier. People can use STL, ETL, EASTL or roll their own. It's just a toolbox, not religion.
 

Offline Mr_Capehill

  • Full Member
  • ***
  • Join Date: May 2002
  • Posts: 189
    • Show only replies by Mr_Capehill
Re: C vs C++ ... or whatever language
« Reply #43 on: February 11, 2018, 08:22:24 AM »
Quote from: Thomas Richter;836014
Actually, when I tested, it was not. There is another layer of indirection, and at least the GNU C++ compiler is not good at removing the overhead even in optimized mode. There is also the "valarray", but that is neither any faster. Yes, it almost all cases it does not matter. But if you do raw signal processing, then the best C++ offers you is the raw pointer (well, except if you have compiler intrinsics for vectorized operations, of course), and this particular case, it does matter.


What sort of test case? I have used std::vector to take care of memory management and just passed the pointer (myVector.data()) to OpenGL, for example.
 

guest11527

  • Guest
Re: C vs C++ ... or whatever language
« Reply #44 from previous page: February 11, 2018, 09:47:57 AM »
Quote from: Mr_Capehill;836024
What sort of test case? I have used std::vector to take care of memory management and just passed the pointer (myVector.data()) to OpenGL, for example.
In that case, of course, the speed is quite the same. No, I'm talking about a wavelet filter, in particular. No "pointer access", but then access to vector elements by operator[]. That is slower than doing it by pointers directly, even though, in principle, the compiler could optimize everything away. In reality, it does not.