Better at 90's programming than modern programming?

Page 3 of 4 [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next

Ichinin
Veteran
Veteran

User avatar

Joined: 3 Apr 2009
Gender: Male
Posts: 3,653
Location: A cold place with lots of blondes.

28 Feb 2013, 8:46 am

Trencher93 wrote:
The return value after the function arguments in C++ 2011 has got to be when C++ jumped the shark. Surely a compiler would not need the coder to move the function return value? Surely in 2011, compiler technology is advanced enough that the compiler could figure this stuff out?

That's what I'm saying about IDEs - they cloak the real problems - the new IDEs will probably automatically move the function return value to after the arguments for you by next year, but a compiler should be smart enough to figure out the return value - I mean, the days of one-pass C compilers are long over, right? If a compiler can figure out template specifications and functors, surely it could wait for a few tokens before it resolved the return value of a function?


Can you give a more detailed example of this?


_________________
"It is far better to grasp the Universe as it really is than to persist in delusion, however satisfying and reassuring" (Carl Sagan)


AspianCitizen
Tufted Titmouse
Tufted Titmouse

User avatar

Joined: 1 Aug 2011
Gender: Male
Posts: 33

15 Mar 2013, 9:01 pm

MyFutureSelfnMe wrote:
I don't have to fight with my IDE that often, unless it's XCode.

XCode... I know it very well, unfortunatly... My favorite is and remain CW

Hermes9 wrote:
Maybe it is better suited to NT individuals, and we have to work harder to grasp it?

NT are sequential thinker... OOP is everything but sequential, it's easier for a non-sequential thinker to grasp OOP and multithreading. It's more natural for us to break up the problem in component and solve it from local to global, from details to globals (problems).


_________________
A proud citizen of Aspia - A different Nation!
http://aspia.wordpress.com/


Fnord
Veteran
Veteran

User avatar

Joined: 6 May 2008
Age: 66
Gender: Male
Posts: 59,750
Location: Stendec

15 Mar 2013, 9:13 pm

I'm better at assembly-level programming than C, and QBasic 4.5 is what I use most often.


_________________
 
No love for Hamas, Hezbollah, Iranian Leadership, Islamic Jihad, other Islamic terrorist groups, OR their supporters and sympathizers.


marshall
Veteran
Veteran

User avatar

Joined: 14 Apr 2007
Gender: Male
Posts: 10,752
Location: Turkey

17 Mar 2013, 12:33 pm

UnLoser wrote:
I'm almost shocked to hear so many of you calling c++ horrible, considering how popular it is. Is it really so complicated as to interfere with writing programs on a regular basis? I haven't learned any compiled languages yet, and I was considering learning c++ first, but if it's that much worse than other languages like Java, then I won't even bother.


I'm not an expert at c++ yet, but I imagine people don't like it because it's complicated. It's a standard that has evolved over time with each syntax addition designed to be backwards compatible. This means there are a lot of "deprecated" or vestigial features. I personally like the flexibility but it is rather taxing to learn it all. The other problem is the language itself doesn't force you to comply with any particular style so if you are working on a project with multiple developers, all with different preferences, it's possible to end up with obnoxious inconsistent code.

From my experience templates are the worst aspect of c++. They make it possible to create very generalized function libraries but they also add a whole new layer to the compilation process making any code that uses them error prone and hard to debug. Trying to create templates for anything outside of very basic library-type functions ( that are mostly already provided in the standard library anyways ) is horrible and almost never works the way you would expect.

Another obnoxious thing you can do in c++ is operator overloading. Again, they are fine for very basic library-type classes but pointless and confusing anywhere else.