Depends on what you're trying to achieve with that pointer arithmetic? If all you're going to do is solve problems the C way, don't use C++.

I didn't have a specific situation in mind but I'll throw one at you: working with raw image data and converting it to a new data structure. I don't know the C++ way of doing that (this is with OpenCV, if you're familiar with it).

Adam,

There are certain low-level problems that can only be solved by going down to the low-level (don't know if yours is an example of that, but even if it's not, they do exist). I don't think anyone is trying to get around that fact. But for most applications this kind of thing won't come up. The problem arises when you start doing C-style programming to solve a domain problem that could have been solved more elegantly and concisely using higher-level methods that will produce more maintainable, extensible, and readable code.

I don't think anyone will disagree with this.

I am overwhelmed by the responses itt, thank you all so much.

At the moment im burying my head into several books / brushing up my mathematics.

Once again, many thanks to everyone.

I think the problem is that OpenCV is written in C with no C++ wrappers available afaik (I've only used the machine learning part of it but assume the rest is the same).

Juk

maybe not in theory, but in practice many people do it anyway, and often without realizing they are doing it.

This.

well... anything else you might need/want would be totally dependent on what you're trying to write. i.e., you'll want the DirectX SDK if you're going to make a videogame for windows.

that said, zlib seems to creep its way into pretty much every project I've ever worked on, so I guess that could be something you'd grab right away.

okay... actually, now that you prodded a little more I realize I did forget one other tool that I find pretty essential... and thats some kind of source control system. I highly recommend Perforce. And as luck would have it, it too is completely free (for "single seat" installations). Get it, learn to live and breath it and it *will* save your bacon someday.

You might find the GSL useful:

http://www.gnu.org/software/gsl/

Also get yourself a copy of the Numerical Recipes book:

http://www.amazon.co.uk/Numerical-Re.../dp/0521750334

(wow, was gonna say "it's not C++, but oh well..." but lo and behold they do a C++ one now too!)

Juk

You must live in a box.

Artists also need to know when to use watercolors and when to use oil-based paint. In much the same way, in programming any non-trivial system there is often a best way to do something. Sometimes this means getting down and dirty with how the computer actually works, but not usually. In that way, sure you can get by and even write decent code without understanding how your computer works. When comparing C++ and C# for example, is one language "better" than the other? No. There's usually a better language for a particular job, but that is more determined by how much expertise you and your coworkers have in that language than what the language can do.

But if you ask me, I'll tell you that C++ programmers write better programs than some C# programmers, strictly because C# programmers can skate by longer without knowing how the computer really works than C++ programmers can. If you want an analogy, here's one. Learning to program in C#/VB/Java [insert "easy" language here] without learning the underlying mechanics of how programs work is like teaching a car mechanic how to use a plug-in diagnostic tool, but not teaching them how internal combustion works. The mechanic who knows how engines work will often get the job done faster, better and more cheaply than the former simply because he knows more.

Java

Or just works on different kinds of projects from yours?

couple things. first, as i've said already, i am not arguing that knowing low-level mechanics has no value. simply that, for a huge majority of projects, it has far less value than understanding high-level design.

i think your analogy is really misleading. an expert in haskell or high-level design in a language like Java is not using a diagnostic tool. they have a completely different skill set that a low-level programmer often does not have at all.

the analogy would be an architect who couldn't actually do the sawing, hammering, and nailing himself. it's not as if the architect is cheating by using some "easy" tool. he knows how to design an entire building. it's a totally different skill.

This ainec. With many of the modern programming languages one can do so much without having a slightest clue what is really going on. However, this is also possible in C++ with f.ex. high level application frameworks, such as Qt for example. And usually this leads to software design, architecture (if it can even be called that), and programs in general that are buggy as hell and fall apart sooner or later

I wouldn't recommend C/C++ for anyone as one's first language to learn though (this is what I did, fml). Also, C++ is nowhere near being a perfect programming language - but there's no such thing as a perfect programming language anyways. But the power and possibilities of C++ is invaluable in some use cases (cutting edge games, for instance).

Disclaimer: I consider myself a noob programmer. I have mere ~3 years of C/C++ experience, and maybe a year of C#, JavaScript and Python combined.

I feel like it's easier to learn high level languages first, to understand basic programming concepts (loops, conditional statements), before progressing to more complicated techniques of lower level languages. Maybe that's just my experience though.

I started in C++ as a CS major and didn't find it all that confusing. But just because PHP is child's play compared to C++ doesn't mean C++ is "better." It just means there is a higher learning curve. Besides, it's not like the two are used in comparable ways.

so i guess when you are writing all your applications in assembly language, then you'll really be an expert.....

ASM is for noobs. Binary/digital logic/Turing machines FTW.

You'd certainly be a better programmer when you at least understand assembly and what's going on at the CPU level.

Better at what, exactly? Would it change any decisions you make about a system's architecture? There are some very specific applications where it will make difference, but as a general rule I think it's simply not true.

EDIT: in fact, if i were hiring, i would be suspicious of someone who had, say, a lot of assembly experience as someone who was likely bad at high level design.

How do you come to the conclusion that someone who knows assembly is bad at high lvl languages?

I'd wager money that if one goes the C -> C++ -> C# route for lets say 5 years comes out as way better C# coder opposed to someone who did C# for 5 years straight.

Maybe I'm just getting old and don't realize entirely how cheap computing power is nowadays and that you basically don't have to care about memory any longer, but I can't think of any reason why it's a disadvantage to know about e.g. memory allocation or what a medium lvl language does to translate your high lvl code into low lvl output.

i didn't say that, i said i'd be suspicious. in my experience there is a certain breed of programmer who is, say, a really really good C programmer but has never studied high-level design, or at least not as much as they claim to have. they have the attitude that they know the really hard stuff, and a superior kind of scorn for so-called easy languages. they tend to do things the hard way, and dismiss any criticism by saying that it doesn't seem hard to them. i would argue that such people, while they may have a honed specialty skill, are actually really bad programmers and miss the whole point.


depends who taught them, and what kinds of books they've read, and what kinds of applications they'll be building. but, in short, i disagree.

Not necessarily, though I might structure small snippets of code differently to try to be more efficient at a micro level. At a macro level your architecture probably doesn't change much. Doesn't mean it's not helpful to have an idea of what the code you're writing actually does under the hood.

It's also helpful because you might not want to work in C#/Java forever. My first job was in Java, now I work in C/C++, and I don't know assembly but at times I wish that I did because debugging optimized builds that have limited debug symbols available can be a huge pain in the ass if you can't read the disassembly. So even doing all of my work in C, my skills are somewhat lacking due to not having a better grasp of languages that operate at a lower level than the one I use.

Your edit re: being suspicious about hiring someone with a lot of assembly experience is kind of getting away from the point. All the original post on the subject was talking about was learning languages, and now you're like "well if someone's worked in assembly for the last 5 years I'd be weary of hiring them for a high-level design job." Okay, sure, I would too, because that person's been working in a completely different area than what I'm hiring for. I'd still be more impressed if someone who did have more relevant experience came knocking at my door and also happened to have a better grasp of lower-level languages than other candidates.