My Little Project

[naraku9333]

Albatross wrote:

Say, might I ask what compiler were you using?

Whichever version of GCC installs with build-essential on Ubuntu. I also had the same issue with mingw in windows which has gcc-4.6.1

[Albatross]

@naraku9333
I could not reproduce your problem at all on g++ 4.6.3. Nonetheless, I put the fix in. Hopefully it'll compile now!

@all
I uploaded another bug fix release, if anyone's interested. This one also features a performance enhancement which many of you on lower-end systems might like. Let that be the last of the 0.2.x series. :)
http://sourceforge.net/projects/soundbench/files/0.2.3%20Alpha/

Thank you so much for your help!

-Albatross

EDIT: I didn't even notice. 3500 posts and counting.

[Moschops]

How do I make it make a noise? I have a midi file if that's needed.

Also, any chance of it responding traditionally to --version and --help?

[Albatross]

The sound generation settings are under the Channels tab.

I really should add in those flags. That's definitely a must-do for the next version. :)
EDIT: The git version now has support for those two flags.

-Albatross

[Moschops]

I did eventually make it make a sound with that A4 button.

Where does the git version live?

[Albatross]

The git version lives here:
http://sourceforge.net/p/soundbench/code/

At the moment, I'm the only person who pushes to it.

-Albatross

[Moschops]

At the moment, I'm the only person who pushes to it.

So you've shown us your toys and now you're telling us we can't play with them :(

[chrisname]

Just make patches or diffs or something and send them to her.

[Catfish2]

I think I noticed if (a[i] != nullptr) delete a[i]; somewhere. That's a bit useless.

[chrisname]

No it's not; I use it to allocate more than one object at a time and then free them all in one go:

int dict_create(struct dict* dict, size_t size)
{
	memset(dict, 0, sizeof(*dict));
	if (size) {
		if (!(dict->keys = malloc(sizeof(char*) * size))) {
			fprintf(stderr, "%s: malloc: %s\n", __func__,
							strerror(errno));
			goto error;
		}
		if (!(dict->values = malloc(sizeof(void*) * size))) {
			fprintf(stderr, "%s: malloc: %s\n", __func__,
							strerror(errno));
			goto error;
		}
		dict->capacity = size;
	}
	return 0;
error:
	if (dict->keys)		free(dict->keys);
	if (dict->values)	free(dict->values);
	if (dict->count)	dict->count = 0;
	if (dict->capacity)	dict->capacity = 0;
	return -1;
}

In C you can just check the truth value rather than explicitly comparing them against NULL (or nullptr in C++).

[Catfish2]

http://www.cplusplus.com/reference/clibrary/cstdlib/free/
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.8

In C you can just check the truth value rather than explicitly comparing them against NULL (or nullptr in C++).

Maybe I'm too newschool, but I personally consider that to be bad practice in both C and C++.

[chrisname]

I didn't know free did that. I remember looking it up one day and I thought it was undefined behaviour. Oh well.

Catfish2 wrote:

Maybe I'm too newschool, but I personally consider that to be bad practice in both C and C++.

I don't see why. It's pretty obvious what it means. I am generally in favour of explicitness, but I don't think it matters in this case.

p.s. are you the original Catfish? If so, why the new account?

[Catfish2]

It's pretty obvious what it means. I am generally in favour of explicitness, but I don't think it matters in this case.

... in this case, the check is as useless as it is for delete.
In other cases, without such a rich context, an "explicit" check would at least make it obvious what's a pointer and what isn't.

[Athar]

In other cases, without such a rich context, an "explicit" check would at least make it obvious what's a pointer and what isn't.

If you don't know whether what is being checked is a pointer or a boolean, then you likely named it poorly.
What do you do in the standard case when you have a smart pointer instead of a raw pointer?
Do you seriously advocate writing
if (ptr.get()!=nullptr)
instead of
if (ptr)
?

[Catfish2]

Do you seriously advocate writing
if (ptr.get()!=nullptr)
instead of
if (ptr)
?

Looks like C++03's deprecated auto_ptr? Give me a cookie.

1 2 3 4 5 6 7 8 9 10

#include <iostream> #include <memory> int main() { std::unique_ptr<int> spi(nullptr); if (spi == nullptr) std::cout << "Works." << std::endl; }

Works.

[chrisname]

What's that supposed to show?

[Catfish2]

What's that supposed to show?

1) The code is supposed to show that C++11 provides overloaded operators for smart pointers to be compared to among other things nullptr.

2) The reference to std::auto_ptr being deprecated is supposed to remind Athar that std::auto_ptr is deprecated and probably with good reason as his example hints how limited it is if you need to retrieve a bare pointer but he also compared it to nullptr which is from C++11 and not C++03 so I wanted to remind him that std::auto_ptr is deprecated and in C++11 you also have the overloaded operators which allow you to directly compare a smart pointer to nullptr.

I sense a bit of hostility. All I'm saying is, I personally consider it to be good practice to usually compare things to values from their own domain of values (e.g. 0, NULL, nullptr) so as to get a "real" boolean expression. Bare bool variables should be excepted from this. Comparing to true or false would be silly.

For me, it's the same principle why I don't usually do things like if (!size).

[Albatross]

I am aware that generally the == nullptr is redundant. However, it does make it a lot easier to find bugs and read the code, especially considering how I use null pointers.

I do use null pointers as dummies quite often in my code, a large reason being to avoid using unnecessary memory when a user wishes not to use a certain feature (i.e. a sound generator). I know I could create dummy classes and that it would probably be a bit more kosher, but... it seems like a bit of a waste to me. :/

EDIT @Moschops: You can still clone it. And... what chrisname said. :)

-Albatross

[chrisname]

@Catfish2,
I didn't mean to come off as hostile, it was a genuine question, not rhetorical.

[Albatross]

I'd been thinking about replacing the graphics for most of the UI elements with graphics that are a little bit less... dull. That little bit of shininess does draw attention and makes the program a bit nicer to look at.

Does anyone have any comments/objections?
http://tinypic.com/r/24w9hs1/6

-Albatross