Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ in Coders at Work

gigamonkeys.com

Post reply on HN
Print view View original

61–70 of 174 posts

Re: C++ in Coders at Work

#61

Post by dkarl »

mbrubeck wrote: post #46
dkarl wrote: post #28

Earlier quoted context omitted.

Is operator overloading in C++ really more complex than it should be, or did you just pay the inevitable price for dabbling in the black art of multiple inheritance? Anytime you say "in combination with multiple inheritance" you can't expect to get much sympathy ;-) C++ is definitely a language where you can get screwed by "clever" programmers who would rather be reading TC++PL than actually coding, but it's not so b…

Operator overloading in C++ is indeed more complex than it should be, thanks in part to the three different ways to pass paremeters (references, pointers, and values). It's definitely more straightforward in languages like C# or Python (or, well, just about anything else) that don't have these explicit distinctions.

The distinction between pointers and values (and the ability to treat pointers as values) is necessary for many applications of C++, so that complexity _should_ indeed be in the language. You may be right that the distinction between pointers and references is gratuitous. Ordinarily, one defines an overloaded operator using reference arguments (never pointers; only values if you're doing performance microoptimizations, i.e., only for a handful of carefully inspected types) and dereferences pointers before applying the operator, so it doesn't really matter unless code in some other module is overloading operators for your types. That's a bizarre circumstance that never happens in practice.

Re: C++ in Coders at Work

#62

Post by jacquesm »

jimbokun wrote: post #49
jacquesm wrote: post #31

Earlier quoted context omitted.

There was a time when I made most of my income debugging other peoples programs, call it 'troubleshooter' or something like that. It gives you an excellent overview of the various ways in which things can go wrong, and C++ figured quite prominently in the 'gotcha' department. C has it's share of issues, double frees, failure to initialize (but most compilers catch that one nowadays), and stale pointers. With a good d…

"The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level." Which totally defeats the purpose of being backward compatible with C.

I think that basing it off C was a quick way to get widespread acceptance though. It succeeded in that respect.

Re: C++ in Coders at Work

#63

Post by slpsys »

jacquesm wrote: post #20
slpsys wrote: post #16

Earlier quoted context omitted.

"with C# pulling the other way" Care to elaborate (I'm legitimately unsure what you mean, not being snarky)?

I think that C# is an attempt at creating an alternative for enterprise level programming to Java, basically .net and C# are an answer to the whole Java ecosystem. They're competing for the same space, so a business that wants to implement some functionality from scratch basically has these two solutions to choose from. In the 'web' domain there are many many more choices, but for places like banks and such that were…

A-ha, yeah. I read that originally as Java and C# pulling in opposite directions in a fundamental way, not as a mind-/market-share sense

Re: C++ in Coders at Work

#64

Post by jacquesm »

monos wrote: post #26
Oxryly wrote: post #5

Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80s, which is all we know how to program well). Lovely languages like lisp, python, haskell may be nicer to work with, but they do not model the underlying machine properly, and for so many problem domains that is just not acceptable. It's not just a performance…

> C accurately models how the computer actually works i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me. so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)

But I can safely say that it is a machine that the C language models fairly precisely and that python, lisp etc will use in ways that will make it harder to predict how their constructs will interact with the machine.

That's exactly the point, if your machine is anywhere near 'standard' (as in not a SIMD or something exotic) then C is as close as you can get to it without going to assembler.

Re: C++ in Coders at Work

#65

Post by citizenparker »

snprbob86 wrote: post #56
dschobel wrote: post #23

Earlier quoted context omitted.

I think C models how the computer works a lot more closely than C++ (and no one would argue that C isn't carrying water out in the engineering world even today). IMO C++'s issue is precisely that it layers all of these leaky abstractions on top of the strict procedural model of C. For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.

The sad part is that there are a few good ideas in C++, so it is hard to throw out the baby with the bathwater. I use C++ like C with destructors, operator overloading, typed constants, and not much else.

Thus proving the author's point.

Re: C++ in Coders at Work

#66

Post by gcheong »

jacquesm wrote: post #37
jrockway wrote: post #34

Earlier quoted context omitted.

PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java. It is kind of weird, actually -- Java for stuff…

> We use a lot of Perl. That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. But then again, is there even an 'enterprise scripting language' ? > All the internal web apps are Java. That's what I would expect. Sun really did some good marketing in that sphere.

>> We use a lot of Perl.

>That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is.

I've seen a lot of Perl used in banking/finance. It really is the "Practical Extraction and Reporting Language" and certainly seemed to have almost completely replaced shell scripting in the last place I worked at. One interesting anecdote about Perl was that a group I worked in originally chose ADA as their language when they were just starting out but eventually gave up and went with Perl just because of it's relative power and simplicity. That company also has a major initiative to replace alot of what was written in Perl (and runs the company to this day) with a system written in Java. That system is still not doing any serious production work and is at least a couple years late. I don't think it has as much to do with the Java language as the "this will be the mother of all systems" approach they tried to take with it in the beginning though.

Re: C++ in Coders at Work

#67

Post by nradov »

jobu wrote: post #55
timr wrote: post #9

This is a disappointingly flamey article: roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days (which were admittedly horrible, but long since past). Most of the rest are from people who just skipped straight to Java, or who are so young that they never had to learn C++ at all. The comments that really drop my jaw are the people who seem to hold up Java as a…

The one point that I see throughout the article is that every programming shop uses it's own subset of C++. Based on coding conventions, library usage, and business domain I have seen how the C++ code used in different companies can look like a different programming language altogether. My professional experience outside C++ is limited, but I had always assumed this was the same for other languages as well. Is C++ re…

In my experience with Java, the core language is small enough that every company pretty much uses the whole thing. Almost everyone has finally upgraded to using at least the Java 5.0 syntax by now. Occasionally you'll run across silly rules that prohibit things like the ternary operator or multiple returns, but those are minor differences.

The big differences come into play with frameworks. Depending on whether you're using Struts/JSF/Hibernate/Spring/etc your code may look completely different.

Re: C++ in Coders at Work

#68

Post by jacquesm »

dkarl wrote: post #52
jacquesm wrote: post #18

Earlier quoted context omitted.

I think the main thrust of that argument has to do with trying to please too many people that were willing to put their support behind C++ if the language would support their pet construct.

It was more the other way around, I think. Implementers had a lot of power to say, "No, this can't be done efficiently," and as a result, the burden was passed to programmers instead. Can you give an example of a "pet construct" (aside from major features like multiple inheritance and exception handling) that could have been left out?

I think operator overloading, which seemed like a 'great idea at the time' with some forethought should have never been part of the language in the way it works right now.

The times that I ran in to examples where it was used properly and elegantly I think it could have been done just as nice with a properly named function call.

I think the way it workd came from the DSL camp arguing that you should be able to make it look as though certain bits where native to the language, even if they weren't, and then the only uses we get are things that have nothing to do with DSLs but everything with children handling power tools (as in: bad idea).

Show me a single example of where operator overloading was necessity to make a function work, and I'll show you a more cleanly coded version using a function call.

The interesting thing is that after the compiler is done with it you'll be calling ::operatorX anyway.

Plenty of times there are naming issues as well, what does it mean to add two items of 'X' together, most times such a statement would be meaningless in the real world, but if you were forced to use a named function instead of an operator that function would have a name that matched what really happens.

Naming stuff is one of the great powers of computer languages, use of operators should be reserved to those situations where the outcome is predictable, and where operator precedence rules are the same as they would be when adding numbers.

So, it's fine to add an instance of a class called 'area' to another instance of that class, but you can't add one instance of 'boat' to another. That one should be done using:

   cargospace = add_carcospace(boat1,boat2);
or something to that effect.

Re: C++ in Coders at Work

#69

Post by alrex021 »

haberman wrote: post #43
alrex021 wrote: post #32

Its really fascinating to me. We had Lisp and then the road for many lead to C/C++, Java, and related and then we needed a way to express data in more human-readable form so some genius came up with XML. XML was to cumbersome (close tags, how attributes are expressed, etc.) and then JSON came into the picture. So all that to just come back to where we were in the first place. Now I clearly understand what some of the…

JSON is not a programming language.

You are absolutely right. My point exactly.

Now you need "two hammers" to get a single job done. Your current programming language of choice and a data expression language.

For example: In C, C++, Java, or related, you "first" have to build you structure to represent a Person with first_name and last_name and then you have to write it to JSON:

Java:

  class Person { String firstName; String lastName; }
JSON with JavaScript evaluation:

  var names = [{"firstName": "John", "lastName": "Smith"}, {"firstName": "Bob", "lastName": "Jones"}]

  eval("(" + names + ")");
Lisp handles both naturally. You don't need intermediary human-readable data expression language. It comes natural to the language itself.

Lisp ver:

  (defvar names '((:firstName "John" :lastName "Smith") (:firstName "Bob" :lastName "Jones")))

  (eval names)

Re: C++ in Coders at Work

#70

Post by jacquesm »

coliveira wrote: post #57
jacquesm wrote: post #37

Earlier quoted context omitted.

> We use a lot of Perl. That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is. But then again, is there even an 'enterprise scripting language' ? > All the internal web apps are Java. That's what I would expect. Sun really did some good marketing in that sphere.

The area of a bank that generate money employs the smartest people, usually coming from academia. So, it doesn't surprise me.

Good point.

Yours and gcheong's comment just above makes me wonder if someone missed the boat in getting an enterprise level scripting language out the door. It looks like there never was a 'natural' successor to stuff like JCL.

Post reply on HN