Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[DrPizza]

Or, for that matter, internal difference. The only difference is syntactic (defaulting to public rather than private).

That is a semantic difference, not a syntactic one.

[Blacken]

Shut up, you, I'm drinking over here.

[eerr]

Cpp. Nice objects. Me loves em.

Of which I have a question. Are the members of an object/class/struct always guaranteed consecutive in memory? So that even a vector of classes, where the classes only hold floats, can be treated as if it were an array of floats (in memory at least)? That would really save me time in copying the entire thing before passing it to the GPU.

Are you sure that you know what you are trying do?

Shut up, you, I'm drinking over here.

with qwerty?

[eerr]

Cpp. Nice objects. Me loves em.

Of which I have a question. Are the members of an object/class/struct always guaranteed consecutive in memory? So that even a vector of classes, where the classes only hold floats, can be treated as if it were an array of floats (in memory at least)? That would really save me time in copying the entire thing before passing it to the GPU.

a vector of classes?
I assume you don't mean vector <*obj>.
Vector<obj> does not exist using objects. This is because array<obj> does not exist.
A vector is an object that automatically reallocates the array contained within, to be exactly the right size.

[Siquo]

std::vectors are guaranteed contiguous, unlike std::maps or other containers, so they can be used as arrays, I knew that . Querty is right, I'm sending the whole thing into OpenGL, which expects C-style arrays. This might mean it's moved when it's running out of contiguous memory, but mine are short lived as they're destroyed after use, which should put them on the end of the stack/heap (implementation dependent). Hopefully that's enough to keep them from jumping all over the place.


@DrPizza: passing as a parameter is not an option, but I've already found a solution within my object hierarchy. Singletons are functional when needed. That's just not very often. Internal padding for structs and classes, platform dependent even, would pose a problem. I'm going to look for the specifications on that.

@eerr: Yep. Sending a size and a pointer to a block of memory of contiguous floats, aka an array. But how does vector<obj> not exist? I presume the vector creates the new objects in a contiguous block of memory, as described here: http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3
Whether the objects are contiguous themselves, or if they have "overhead" or "padding", was the question. They don't contain pointers (as vector uses shallow copies that'd be suicide asking for trouble), and just an x number of floats or float arrays.


Result: Dammit. "Thou shalt not do stuff like that". "fields in a structure are not guaranteed to be contiguous"

I got the idea from a piece of code I found somewhere, that assumed that structs of floats, that were padded with empty floats to nice round sizes, were contiguous. Apparently he was assuming too much, as it's probably-the-case-but-not-guaranteed.

Back to the drawing board!

[qwertyuiopas]

Some googling says that it is likely that it tries to align them to thir size, so consecutive elements of the same type probably don't have padding. Also, if compilers ever changed, it would likely break practically every single bit of code that relies on structure contents, especially networking, so people wouldn't use that compiler.

[Siquo]

If it's not spec, but you still rely on it, your program should break. I really don't want to run the risk.

Also, likely: This program is "likely" not crashing doesn't really cut it... Especially since this might introduce very random crashes, as it usualy lines up but suddenly doesn't, once in a blue moon.

Damn, I start to sound like blacken.

[Blacken]

If it's not spec, but you still rely on it, your program should break. I really don't want to run the risk.

Also, likely: This program is "likely" not crashing doesn't really cut it... Especially since this might introduce very random crashes, as it usualy lines up but suddenly doesn't, once in a blue moon.

Damn, I start to sound like blacken.

Perhaps it's because--gasp--Blacken knows his shit! Whoever would have thought. Maybe, just maybe, it's because Blacken has run into these problems repeatedly and has developed a style of and outlook on development intended to combat them. Holy shit, right? I have to hand it to you though: at least you've figured out that "likely" not crashing isn't good enough and that a little intellectual rigor is required. More than a lot of "programmers" do, and could be (but likely won't be) a learning experience for a number of folks here.

It's been a while since I did much C++, but in my experience, avoiding the STL may make your life a little easier when you're spending a lot of time with C interop code--the internals of STL libraries can be breakably different and yet completely to-spec, unfortunately. Obviously I don't suggest avoiding it entirely, that'd be moronic, but it might be better to marshal it over to C constructs before you go into OpenGL hell and get the hell out of the STL entirely. (This may not be applicable with your code model though.)

[Siquo]

Yeah, I like vector, but I do need to be careful with STL when coming anywhere near the C-boundary...

[DrPizza]

std::vectors are guaranteed contiguous, unlike std::maps or other containers, so they can be used as arrays, I knew that . Querty is right, I'm sending the whole thing into OpenGL, which expects C-style arrays. This might mean it's moved when it's running out of contiguous memory, but mine are short lived as they're destroyed after use, which should put them on the end of the stack/heap (implementation dependent). Hopefully that's enough to keep them from jumping all over the place.

They don't just randomly jump all over the place, and if you reserve() space that's big enough they'll never move.

@DrPizza: passing as a parameter is not an option,

Yes it is. It might not be an option you want, but it's absolutely an option, and almost always the right one.

but I've already found a solution within my object hierarchy. Singletons are functional when needed. That's just not very often.

It's basically "not ever".

Internal padding for structs and classes, platform dependent even, would pose a problem. I'm going to look for the specifications on that.

It's not specified, it's platform-dependent, as different platforms have different alignment requirements. x86, for example, allow "almost all" loads to be unaligned (the exception is some SSE loads).

@eerr: Yep. Sending a size and a pointer to a block of memory of contiguous floats, aka an array. But how does vector<obj> not exist? I presume the vector creates the new objects in a contiguous block of memory, as described here: http://www.parashift.com/c++-faq-lite/containers.html#faq-34.3

Of course it sodding exists.

Whether the objects are contiguous themselves, or if they have "overhead" or "padding", was the question. They don't contain pointers (as vector uses shallow copies that'd be suicide asking for trouble), and just an x number of floats or float arrays.

Vectors don't make shallow copies. They call copy constructors, so can be as shallow or as deep as your write.

Result: Dammit. "Thou shalt not do stuff like that". "fields in a structure are not guaranteed to be contiguous"

I already said that for crying out loud.

I got the idea from a piece of code I found somewhere, that assumed that structs of floats, that were padded with empty floats to nice round sizes, were contiguous. Apparently he was assuming too much, as it's probably-the-case-but-not-guaranteed.

It'll be the case on any platform you ever use. I don't know (or care) about OpenGL, but in Direct3D, you pass arrays of custom structs to D3D, and it figures out the offsets just from a descriptive bitfield you use to say what members the structs have. This means that the padding must be thoroughly predictable and reliable.

[Siquo]

but in Direct3D

Yeah, I thought as much. 

What is it about microsoft products that make the developers that work with them so... what's the word... defeatist? As if the dark hallways of their life are the only way to live it. As if happy coders aren't allowed to exist, or programming isn't allowed to be fun, or making mistakes is the end of the world. Yes, working on a huge project with a big team makes you hate happy-go-lucky programmers whose shit you have to clean up, preferably in overhours just before a deadline, but that is not the case here. Here's people who like goofing off in programming for fun, fail with grace or succeed with ugly shortcuts, and move on to the next project.

Perhaps we need a separate bile-topic, to spout the blackness that coding in corporate environments fills us with.

[eerr]

Ah, my syntax was,

inaccurate.
Apologies.
I meant to say that
vector<object> uses an array of pointers to objects.
not an array of objects.

You cannot make an array of objects, because the size is not constant.

[Blacken]

What is it about microsoft products that make the developers that work with them so... what's the word... defeatist? As if the dark hallways of their life are the only way to live it. As if happy coders aren't allowed to exist, or programming isn't allowed to be fun, or making mistakes is the end of the world. Yes, working on a huge project with a big team makes you hate happy-go-lucky programmers whose shit you have to clean up, preferably in overhours just before a deadline, but that is not the case here. Here's people who like goofing off in programming for fun, fail with grace or succeed with ugly shortcuts, and move on to the next project.

Perhaps we need a separate bile-topic, to spout the blackness that coding in corporate environments fills us with.

Um. What the fuck are you going on about? Have you ever used Microsoft tools? Visual Studio is full-stop the most user-friendly development environment out there--they actually pay a little bit of attention to how people use their tools and adapt them to the user. (Eclipse and NetBeans both try, but they bring with them tons of usability issues and love to clash with every platform they run on because, clearly, HCI is for suckers and conforming to the platform you're building for is just too damn hard to be bothered with.)

In terms of APIs, Direct3D is vastly simpler and less of a pain in the ass than OpenGL; I won't say it was exactly designed to be easy on programmers, but it's far simpler and more developer-friendly.

And then you have .NET, which is an absolute joy to work with--it lets you just wave away the bullshit and concentrate on doing what you want to do, be it corporate business logic or writing a game. There's an obvious and pretty compelling argument that it's less drudgery to use these tools: while you're dicking around with a library that's designed by committee by people who think the standard C library isn't a crime against humanity, I can just pass in objects to a (mostly) well-formed API and it Does The Right Thing and I don't have to fuck about with it. And if I'm just a little--well, more than a little, because I have to use a mess of OpenGL or SDL instead of fairly straightforward DirectX libraries, but not that badly--careful, my code runs on OS X (and would probably run on Linux if I gave a fuck) without changes.

But, clearly, that's just corporate drudgery. Never mind that I'm done and onto doing more interesting things while you're still trying to look up a spec--drudgery, all of it, right right.

Or, you know. It could just be that it's not "drudgery" at all, and you're just magically inventing shit--and I do say "inventing," it's quite clear you're talking out your ass--to make your own pet choice of platform and tools look a little better to you. It's a common fanboy disease: craving validation is a bitch, ain't it?


And what the hell does that have to do with "oh no bugs are the end of the world" or other caricatures of professional development (you've clearly never worked in a professional environment), anyway? There's nothing "defeatist" inherent in Microsoft toolsets; I see dumb bitchy Java and Python and even neckbeard-C programmers quite often and hell, even Stallman The Bearded Fuckwit calls that FWEE. It has nothing to do with the originator of the tools and everything to do with management and corporate culture.

[timmeh]

That could have been said with some degree of civility, Blacken.  The suitability of a tool is largely dependent on the task it is supposed to perform.  I avoided MSVC for quite some time because I didn't need a powerful compiler to learn C++ with, I wanted something with text-entry and a compile/build button.  I love it now, the debugging features are freaking incredible, but I still revert to smaller compilers when all I need to do is test a theory or a couple lines of code.

As far as the Direct3D vs OpenGL, and .NET and STL and so on, again, the tool should be chosen based on the job at hand.  I haven't really used .NET yet, beyond a simple "Hello World" program to see how it works, and I haven't progressed enough in general to have started messing with 3D graphics.  However, I've done several GUI programs, one of which I wrote directly with the Windows API.  I found it substantially easier to work with the QT or wxWidgets platforms, even after having experience with the Windows API, because they were far more compatible with the basic STL containers (like 'string'...).  Not to mention, there is occasionally a need to write a program that works on multiple operating systems, in which case something like Qt/wxWidget would be far simpler and more effective than writing your own multi-platform library to serve the same purpose.  The same goes for OpenGL, when developing a graphical application you would like to work on platforms other than Windows.

Now, I have nothing against the Windows API, .NET or DirectX/3D, but even with what little programming experience I have, next to nothing is absolute in programming, in that there's an exception to almost every "rule", and never a single library that is always better than all the others.

Can we please re-rail this topic now?  There are more productive discussions to be had here, if you want to discuss/debate this, you'd likely get a far better response if you started a separate topic for it.


As far as the challenges, I've seen variences of the "Find the subset of an array with the highest sum of it's values." thing all over the place... may have to try that one later.  Also, if anyone reading this hasn't already, I'd suggest checking out the PiratePad page Alexhans set up for this topic, has an interesting challenge on it.

[alway]

Ah, just remembered a problem which has plagued me constantly with visual studio. Linker error LNK2005. Any C++ project I try to do seems to only be able to build with a single .cpp file; any others added cause that linker error en masse. As such, I have resorted to putting everything except the winMain.cpp in .h header files. I have no school-learning with visual C++(still a senior in HS), and as such don't really know what the cause of said error is, or what any negative effects from everything being in header files might be. Can anyone explain to me how that works?
And yes, I realize I am probably doing it horribly, horribly wrong.