[lukeme99]

I started out with Lua, just plain gLua; I tried to design a few addons for GM10/11, and they worked because I did exactly what the tutorials said. I moved on from Lua to C++, and I found it easier, I moved back to Lua for a while and whenever I learn something new in one lang', it helps me understand whats in the other.

Also, header files... Seriously, if you use something that hasn't been declared, VS actually suggests what header file to include! That was really helpful when I was in Sourcemod Programming HELL!

And another thing, according to the VDC, learning C++ through modding source is a BAD idea... The reason I wanted to get more out of C++ was because I worked on ProMod nearly blind!

PS I am currently in cyprus, on holiday, and I continue to work on little programs using my shitty iPad toolset, and the Columbia Beach Resorts S L O W internet!

[Skydiver]

What does VDC stand for? Virginia Department of Corrections?

[Lsn2Mkt]

My own C++ code is incredibly easy for ME to understand. I look at others' code does the same thing as mine and go, "Good grief! What are they doing?"

I've been fortunate to be an independent contributor since the mid-80s. I make my own rules and enforce my own strategies (occasionally in transition). As a member of a team, I wouldn't have that luxury, though I'd probably be a better programmer.

Is C++ hard? I can only say, "I know what I know. And it's easy!" There are C++ constructs and strategies that startle me when I see them for the first time, though. When I ran into 'variants' in sample code for working within an Excel spreadsheet, I did a double- or triple-take. Certainly, it couldn't be THIS convoluted. I limped through. I don't limp very often.

Is C++ hard? It's incredibly powerful and provides relatively easy ways to do very difficult tasks once and forever. Does that make it easy? Yes, until you're dragged out of YOUR OWN comfort zone. Then it simply becomes another little challenge you'll solve, then look back and say, "That was easy!"

[pokiaka]

Very interesting topic.
Before I started to program in C++ I used to not move an inch from C#. I just loved the .NET Framework, that insane rapid-development, not to mention how it can be used not only with as a desktop program, but on in internet with ASP.Net (although I don't like it very much, I find PHP much better, in terms of speed of both development and solution).

So, I have to say, moving to C++ was hard. for 2 reasons:

1) I was spoiled because of C#. C# is managed, with clear names, EVERYTHING was documented inside of the IDE itself. You barely have to read documentations. not to mention the speed and the support of the IDE with visual-designers etc. I'm afraid that Microsoft doesn't care much for C++ as it cares for C#. that would be obvious, but I mean that they really barely care for C++ in terms of IDE (rather then the compiler, I think it's great). IntelliSense is just awful, inaccurate, and a lot of the times you get errors, you don't understand why, you start messing with your code, only to find out that those errors didn't exist and the IDE had to rebuild your code to find it.

2) At first I didn't have much of learning references. that's not the case now and of course I think it's great.

Also C++ is a great language, in every term I can think of (I think if it wasn't an extension of C and so it wouldn't have to carry on its back old code, it was flawless for every need I have. for example the explicit keyword. I think it should be default for each constructor, but it can't be because it will ruin old code). also take in mind that it's a pretty old language even though it's evolving. there are many techniques available in the more modern languages and a lot of people find themselves want to use those languages instead, because doing those certain things in C++ would be harder.

[111027]

Well, no language is hard. Programming in it, however, can get tricky. A lot of the memory going around in actual software is dynamically allocated, an in a tens - of - thousands - of - lines - of - code programs (which in C++ isn't uncommon), it's ridiculously easy to forget to delete[] something. Also, pointers themselves are easy; but you have to realize that a lot of the pointers in C++ code are actually hidden. For an example, what if you did something like : class. property instead class -> property? Most compilers would let it slip, but you'd get a really weird bug that's very difficult to track down.

C++ isn't a bad language, and is in my opinion very suitable for beginners. Over here, we do C/C++/Java in university, and I like the progression. Also, C++ was for years my favourite language. But, somehow, C# got the better of me.

[sepp2k]

111027, on 22 July 2012 - 10:57 AM, said:

For an example, what if you did something like : class. property instead class -> property? Most compilers would let it slip, but you'd get a really weird bug that's very difficult to track down.

I assume that in the above code class is supposed to be the name of an object, not a class - otherwise neither . nor -> would be legal and you'd have to use ::.

That said I don't see how you could possibly write . instead of -> without getting a compilation error. If class is a pointer, using . on it will fail to compile. If it's an instance of a class that overloads ->, it will very likely not have a member called property, so calling .property on it will also be illegal.

The only scenario where you wouldn't get a compilation error would be if class is an instance of a class which overloads -> and has a public member named property. However for it to make sense that you meant to use -> instead of . the target type of class's class (i.e. the type that class "points to") must also have a member called property. This scenario is incredibly unlikely.

[111027]

I didn't literally mean 'class' and 'property'. Class was used as an object, and property as a general name. It is, however, possible to get the same kind of error. And here is why:

The instance name is a pointer to some block of memory. The dot operator operates on the pointer only,by offsetting n bytes from the bottom of the object (that is, the last property) upwards. In this case, n varies on how many properties, and of what sizes, they are.

So, if we have some instance instance and some property var, then instance.var would offset that pointer to some value. On the other hand, the ' -> ' does the same, but it <i> treats </> the value it finds as a pointer, as well. So, if you reference something as a valued instead of a pointer type,and it is actually a pointer, you'd get offset again, and the offset would be whatever address was stored in that pointer.

Some compilers (albeit not very popular ones) do let this slip. Again, it's a really tricky situation here; though, Microsoft compilers do not let it slip. And I'm not sure about the GNU one.

[sepp2k]

Let me be very clear: Using . on a pointer will lead to a compilation error, plain and simple.

If any compiler allows you to use . on a pointer, it's not standard compliant (and while there are many compilers that aren't (fully) standard compliant, I'm not aware of a single one that allows you to use . on a pointer).

Quote

Some compilers (albeit not very popular ones) do let this slip.

Yeah? Which ones? Or put in other words: [citation needed].

Quote

And I'm not sure about the GNU one.

GCC does not let it slip either. Until you actually cite one, I maintain that no compiler that has ever been used by anybody does.

[111027]

Checked GCC, it doesn't.

[ishkabible]

do you mean "doesn't [let it slide]" or "doesn't [raise an error]"?

[111027]

It doesn't let it slide. Kudos for GCC.

[sepp2k]

111027, on 23 July 2012 - 05:58 PM, said:

It doesn't let it slide. Kudos for GCC.

That's not really kudos worthy. As I said already: No compiler let's this pass. Letting this pass would actually require extra work from the compiler (the compiler would have to have a special case for handling . on pointers) compared to not letting pass. There's no reason why a compiler writer would go through the trouble to allow doing something that doesn't make sense (and isn't legal according to the standard) in the first place.

[Skydiver]

As I recall, even the much maligned Turbo C++ compiler doesn't let it pass.

[111027]

Turbo C++ isn't a bad compiler. In fact, it's rather decent.

[jimblumberg]

Turbo-C++ is in no way a good compiler by today's standards. This old, pre-standard compiler should be consigned to a museum or better yet the trash heap. Many of the "standard" classes have major deficiencies when compared with the actual STL classes adopted by the standard.

Jim

This post has been edited by jimblumberg: 24 July 2012 - 02:09 AM