Programming Woes

[Melllvar]

For completeness, I did some checking on the double delete thing, and it seems some compilers/systems take care of it in simple cases, which is probably why I couldn't force an error. Not that I need to tell anyone here this, I'm just stating it in case anyone else happens to come along and be reading this conversation.

From the above link: "That second delete p line might do some really bad things to you. It might, depending on the phase of the moon, corrupt your heap, crash your program, make arbitrary and bizarre changes to objects that are already out there on the heap, etc. Unfortunately these symptoms can appear and disappear randomly." .... "Note: some runtime systems will protect you from certain very simple cases of double delete. Depending on the details, you might be okay if you happen to be running on one of those systems and if no one ever deploys your code on another system that handles things differently and if you are deleting something that doesn't have a destructor and if you don't do anything significant between the two deletes and if no one ever changes your code to do something significant between the two deletes and if your thread scheduler (over which you likely have no control!) doesn't happen to swap threads between the two deletes and if, and if, and if."

So, um.. yeah, I'm convinced.

 

[₲uardian]

In the case of overloading by return type, for me it would have been useful to do something like this:

SpanishVerb GetVerb();
EnglishVerb GetVerb();

Then I could just do things like:

mySpanishVerb = GetVerb();
myEnglishVerb = GetVerb();

Why not just say GetSpanishVerb() and GetEnglishVerb() ?

I still have to rewrite the entire actual program to not use pointers.

You're working with a language that uses them, so... that might prove to be difficult if not impossible.

I work with a language that uses them, but i don't need to know about them because it's managed for me. My point is, unless you switch languages, you have to deal with them.

 

[Melllvar]

Why not just say GetSpanishVerb() and GetEnglishVerb() ?

Because then I would have to explicitly specify which one I want when I'm using it. For example, I couldn't do things like:

class Entry {};
class SpanishEntry : public Entry{};
class EnglishEntry : public Entry {};

int Function(vector<Entry> *myVec) {
myVec.push_back(GetVerb());
}

Then I could pass it either a &vector<SpanishEntry *> or a &vector<EnglishEntry *> or whatever else and it would work out which version of GetVerb() to call, without me having to write a whole bunch of different functions, like:

int EnglishFunction(vector<EnglishEntry> myVec) {
myVec.push_back(GetEnglishVerb());
}

int SpanishFunction(vector<SpanishEntry> myVec) {
myVec.push_back(GetSpanishVerb());
}

I'm not entirely sure that that would have worked anyway, I just came up with the example off the top of my head, but you get the point - I don't necessarily know what type of word or language I might be needing somewhere else in the program, and this way it could figure it out for me. Instead I'd have to either use variables to keep track of it and have long switch/if-else statements (and hence really long functions) to decide what to do, or write a whole bunch of different functions, which would probably result in long switch/if-else statements anyway when it came time to call the right one.

You're working with a language that uses them, so... that might prove to be difficult if not impossible.

I work with a language that uses them, but i don't need to know about them because it's managed for me. My point is, unless you switch languages, you have to deal with them.

Well, I'm not planning on abandoning them entirely (at least not with C++), so much as I'm not going to use them in data structures anymore (subject to revision as I learn more about this), and am going to start using iterators while I'm at it.

I think I can leave all the other pointer stuff as is, and probably should, otherwise the program is likely going to end up being hundreds or thousands of times larger if I truly don't use pointers anywhere (depending on how many languages it holds, how many "translations" each word has on average, and whether or not I start getting it to do phrases or just leave it with individual words).

 

[₲uardian]

@Melllvar
In that case, you wouldn't need to overload. You'd just use one function to return the base type Entry. Since both types are of type Entry, you can return either.

 

[Melllvar]

Ah, good point. I don't know what to say, it seemed like I needed it at one point, but I found a way around it anyway. Honestly it's a bit hard to keep all this stuff in my head at once.

Speaking of general confusion...

I'm not actually sure we determined that vectors of pointers were in themselves a bad idea. Calling delete twice on the same object is a bad idea. Calling insert and such when using iterators is a bad idea. Looping through a container without using iterators is a bad idea. But it does seem that the pointers are pointing to the object's address in memory, so calling insert(), etc. on a vector of pointers doesn't screw up all the pointers in the vector.

There seems to be no reason I can't have a single "master vector" of all the object pointers, and set elements of other vectors equal to them, since I can still loop through them with iterators and only call delete on the objects in the original container.

No disrespect to The Journey, I'm grateful for the tips and advice, but I've taken to another C++ specific forum to clarify this issue just for my own peace of mind (a google search was not helpful). I'll post back if/when I figure something out.

 

[Melllvar]

Short answer: The Journey was correct, it is dangerous (hard to keep up with what you've already deleted), but there are ways around it (smart pointers, set things to NULL after deletion and check to see if they're NULL before using or deleting again).

Longer answer.

I only care because each "word" (i.e. class instance) needs to hold its equivalent words in other languages, which either means pointers to or copies of those instances, and having lots of copies of instances that have many, many copies of other instances does seem like it's going to take up a ridiculous amount of space. Also I just want to know for my own edification.

 

[MunkySpanker]

Do you ever try to write a program (as in, on a computer), and then it gets so damn big that you can barely keep up with what you've got?

Or maybe you understand it all in your head, but when you start getting run-time errors it's pretty much impossible to fix it without screwing something somewhere else up? And even if you can fix it this way, it takes hours and hours, maybe even days, since you have to go through and change things around all over the program, and eventually you end up getting lost with all the changes you've made and having to reload a previous version and start over?

Or you just get so fed up with it that you decide to scrap a month's worth of work and like 10,000 lines of code and start over from scratch because it actually seems easier due to all of the above difficulties? Or you take a break from what you're writing for a few months and when you come back you have no idea what the heck is going on in there anymore?

I'm wondering if this is something that goes away with more experience, or if there is simply a limit to how much complexity a person can hold in their head at once, or if I'm possibly just stupid and a really shitty programmer. From having repeated this process of building something, watching it become more and more complex until making any changes requires a Herculean effort, and then eventually just giving up and starting over, I've decided I need to find a new strategy here. So far my best ideas are:


Actually diagram out what I'm trying to build before I start coding it, instead of taking the "I'm smart, I can just start writing and juggle it in my head as I go" approach. Problem: I don't know enough about software engineering to know if what I'm flowcharting or describing will actually work before I type it in and hit the compile button.

Read that damn "Code Complete" book front to back, preferably memorizing every page, until it teaches me all the tricks that people use to overcome these difficulties. Problem: It would take a really long time and I'd likely move on to something else and never actually get anything useful built.

Break everything up into really, really, really small functions (maybe 12-15 lines of code), and use very long, descriptive names for variables and functions, so that when you go back to change things it doesn't just look like a big mass of meaningless gibberish. Problem: I don't know if this will actually make it easier, or just waste more time.

Keep practicing and hope I get smarter/more experienced. Problem: It will also take a really long time and may never happen.

Make a really long post on INTPforum seeing if anyone else can relate to this issue. Problem: This isn't really a programming forum.


So does anyone else have any stories about the aneurism-inducing stressfulness of trying to create software? Or perhaps advice on how real software developers manage to write massively complex programs without driving themselves insane or giving themselves strokes in the process? Needless to say, I can't even imagine how people actually manage to do this stuff in teams, but I'm sure they must be using a vastly different process than whatever I'm doing.

/rant

i keep joking how I should have been a computer programmer -- it fits my personality. a computer program has fixed walls -- that can be changed, rearranged, and actually do whatever the hell we can fancy up or imagine... I seem to have had a natural proclivity to business and real estate, maybe it's because that's what my dad did... I dabbled in computers barely in highschool then never really had a passion for it...

however... i experience the same pains and frustrations, just as if I was a programmer writing a gigantic program, never releasing it, coming back to it, getting confused, re-doing it, not understanding what I wrote... I get all that believe it or not...

My analogy is/are my business plan(s). Potential businesses I never start. Employees mad at me bc I lock myself in the office for days, weeks, months. Marketing plans that never get executed.

I guess the best advice I've seen recently is "good enough is good enough." I'm a perfectionist to where it's detrimental and so are you. Just ship, collect feedback, and ship again, I guess.

We probably have this insecurity that the world will receive an imperfect product... but nobody really cares... except for us.

 

[The Journey]

Short answer: The Journey was correct, it is dangerous (hard to keep up with what you've already deleted), but there are ways around it (smart pointers, set things to NULL after deletion and check to see if they're NULL before using or deleting again).

Longer answer.

I only care because each "word" (i.e. class instance) needs to hold its equivalent words in other languages, which either means pointers to or copies of those instances, and having lots of copies of instances that have many, many copies of other instances does seem like it's going to take up a ridiculous amount of space. Also I just want to know for my own edification.

If you think that memory is going to be a problem, then you need to rethink your approach on the problem.

 

[Latro]

@Melllvar
In that case, you wouldn't need to overload. You'd just use one function to return the base type Entry. Since both types are of type Entry, you can return either.

"Both types are of type Entry." Is that how it works in C++, or is it that both objects are of type Entry, and thus inherit methods from it? Because as I understand it, the typeclasses approach that Haskell uses is unconventional, and yet that's pretty much how the typeclass system gets described. "Int is an instance of Num." "Integer is an instance of Integral." "[Int] is an instance of []". etc.

Short answer: The Journey was correct, it is dangerous (hard to keep up with what you've already deleted), but there are ways around it (smart pointers, set things to NULL after deletion and check to see if they're NULL before using or deleting again).

Longer answer.

I only care because each "word" (i.e. class instance) needs to hold its equivalent words in other languages, which either means pointers to or copies of those instances, and having lots of copies of instances that have many, many copies of other instances does seem like it's going to take up a ridiculous amount of space. Also I just want to know for my own edification.

OK, estimate how many words you need, how many languages you need, and how long each "chunk" is for a given word in a given language (in characters). Figure out how much memory it is. (You know sizeof(char), so that shouldn't be too bad, at least to get an order of magnitude estimate). If it's a lot, then you have an interesting problem on your hands that requires a lot of careful thought. (Alternately it could be file-based; instead of loading everything into memory, you could be reading from a hard drive. It's slower, but probably not unbearably so.) If it's not, and I don't see why it really would be, then you need to refactor your method, as The Journey said.

 

[₲uardian]

"Both types are of type Entry." Is that how it works in C++, or is it that both objects are of type Entry, and thus inherit methods from it? Because as I understand it, the typeclasses approach that Haskell uses is unconventional, and yet that's pretty much how the typeclass system gets described. "Int is an instance of Num." "Integer is an instance of Integral." "[Int] is an instance of []". etc.

Is this a serious question, or are you picking at the way I've described it because you're aware of a different programming language's convention?

Classifications in c++ are just frames that define the data. As far as I know, classes in c++ aren't actual data.

 

[Latro]

Is this a serious question, or are you picking at the way I've described it because you're aware of a different programming language's convention?

Classifications in c++ are just frames that define the data. As far as I know, classes in c++ aren't actual data.

It's the notion of a type having a type. This is different from an object having a type which is a subtype of some other type. This is somewhat subtle, but here's an illustration:
Typeclasses: Int is of type Num.
Inheritance: An Int is of type Num.
I'm asking which one is used by C++. I thought it was the second one, but your description made it sound like the first one.

 

[Melllvar]

Eh, I slacked off on it this week, mainly because I haven't been sleeping well, which makes doing complicated things a bitch. Started to get back to it now (a little), so let me take the time to respond...

Long story short, I'd really need to get further along to do any order of magnitude estimates, since I'm just writing it as I go and the design changes a lot. Plus each language added requires exponentially more space, since it has to deal with all the other pre-existing languages. I'm sure I could come up with an equation to describe it as a function of all that, but there isn't really any point (see next paragraph).

Right now I'm just writing this for me, not for clients or monetization or anything. I can just have a vectors of pointers holding all the words that I need, set other things equal to those pointers as much as I want, and delete the original pointers in the database right before the program terminates. All the other dynamically-allocated pointers in the program are members of the objects those vectors are storing pointers to, so they get deleted by the destructors at the same time. It's really very easy to keep track of, no need to worry about double deletion or anything like that.

That way: no memory issues, no danger from haphazard use of pointers, and it saves me a lot of time and effort. If I ever do decide to do anything "bigger" with it that would require more well-written code, I'd almost certainly be rewriting it anyway.