Print

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

[MagmaMcFry]

No, the first loop looks for a non-space character. The second loop looks for EOL or space (well at least it would if it wouldn't have a compile-time error because the "length" variable is undefined).

[Rose]

oh yeah, you're right.

This entire thing is garbage.

[Reelya]

That will compile fine. It's c not c++. For loops that don't have a type:

for(thing; thing < otherThing; thing++)

works fine in c and older c++ I have c++ code that I wrote myself back in 2008 on Visual C++ 6.0 that has typeless for loops. I recompiled it and got tons of errors for not defining for loop types, since that wasn't a thing back then. I also tried updating some c code to c++ recently from someone else, and it compiles fine as c, but the compiler spits the dummy if you tell it to compile as c++. Some of the issues were as so:

functions without types on the parameters, then you have to define them separately in between the function header and block like so:

void function(param)
int param;
{
   // do stuff
}

Before c++, putting the actual types into the header brackets was futuristic sci-fi stuff that didn't exist yet, though C got that as well later.

function prototypes that don't have any param types listed, and they can be specified inside lists of variables like so:

int x, y, z, function();

And then you specify exactly what "function()" is later on. after using it. This actually compiles in c but not c++.

[Bumber]

I think you could use an array of struct pointers that contain a type_info and void pointer.

That will compile fine. It's c not c++. For loops that don't have a type:

for(thing; thing < otherThing; thing++)

The code in question is:
for(something; thing < otherThing; thing++)

Even if you get it to compile, the loop won't terminate because you're incrementing a different variable.

The iterator "length" should be just "l".

[scrdest]

That will compile fine. It's c not c++. For loops that don't have a type:

for(thing; thing < otherThing; thing++)

The code in question is:
for(something; thing < otherThing; thing++)

Even if you get it to compile, the loop won't terminate because you're incrementing a different variable.

The iterator "length" should be just "l".

Will it? Correct me if I'm wrong, I do not use C/C++, but from what I understand it could actually work assuming you declared thing proprly earlier.

I'd expect:

Code: [Select]

int thing = 0
int otherThing
for(;;){
    if(thing < otherThing){break;}
    thing++}
to be functionally identical to the normal for(thing; thing<otherThing, thing++). But I may be misunderstanding what I read.

[McTraveller]

I guess maybe - we were so focused on the details, I've got to ask - why do you want a list (or stack) of arbitrary objects in the first place?  Just curious what the use case is for a heterogenous collection.

[i2amroy]

But the problem is that if you only send a void pointer then the receiving function has in fact no way of knowing what you sent to it. Let's consider the function you'd have to write:

void store(void *myThing) {}

How does "store" know what myThing really was? So you'd have to send it extra information:

void store(void *myThing, enum myType, enum mySize) {}

And that would ensure that you need a full catalogue of all possible types in your enum before you start using this, and you'd have to call it like this:

int whatToStore;

store((void *)whatToStore, typeInt, sizeof(int));

And to get around the need for doing this, you'd have to write a template function, which is exactly what I already did. And if you have a template function, there's no need to cast to void*.

As I noted, my mentioned design would require the calling code to know what you are pushing/retrieving, not the store/retrieve functions themselves (which would literally just care that they are void pointers and storing those in some sort of structure). It becomes the job of the programmer to hardcode those casts to the appropriate types based on the program flow. Of course that would also probably prevent you from doing true arbitrary willy-nilly pushes and pops from your data structure, but as mentioned there really isn't that much use for such a structure in the first place, as opposed to something with a regular order (say always pushing a person, then the object attacking them, then the attacking creature in that order, for example) which then means that on the other end you can just manually cast the first thing to person, the next one to the object, and the third to the creature. As I said, fragile and horribly unsafe, but it would work for the majority of use cases just fine (about which I am indeed interested as McTraveller is).

[milo christiansen]

Nonsense, your code is only "clean" and "elegant" if you use single-letter names for every variable. Words are for scrubs. Abbreviations are acceptable only if you can't tell what the original word was.

I would just like to say that I use single letter names all the time. But I follow a few simple rules:

1. The variable must be a common one used all over, and the same letter must be used with absolute consistency. For example I use "l" for the state in my Lua VM.
2. If rule 1 does not apply then the variable's declaration and the end of its scope must fall on the same "page" (~100 lines or so).
3. The letter must "make sense", eg it needs to be the most important letter in the name that would otherwise be used (for example the first consonant).

[McTraveller]

Single-letter variable names other than loop iterators and mathematical expressions may be useful for you right now - but they are almost never useful six months from now trying to understand old code.

There is perhaps an exceptional case like you described, where there is some canonical single-letter variable like you mentioned.

[Reelya]

I think you could use an array of struct pointers that contain a type_info and void pointer.

That will compile fine. It's c not c++. For loops that don't have a type:

for(thing; thing < otherThing; thing++)

The code in question is:
for(something; thing < otherThing; thing++)

Even if you get it to compile, the loop won't terminate because you're incrementing a different variable.

The iterator "length" should be just "l".

Ah right I was talking about the first loop, which is what someone said "look at the first loop, especially", so I didn't pay attention to the second loop, which was where the error was.

But the problem is that if you only send a void pointer then the receiving function has in fact no way of knowing what you sent to it. Let's consider the function you'd have to write:

void store(void *myThing) {}

How does "store" know what myThing really was? So you'd have to send it extra information:

void store(void *myThing, enum myType, enum mySize) {}

And that would ensure that you need a full catalogue of all possible types in your enum before you start using this, and you'd have to call it like this:

int whatToStore;

store((void *)whatToStore, typeInt, sizeof(int));

And to get around the need for doing this, you'd have to write a template function, which is exactly what I already did. And if you have a template function, there's no need to cast to void*.

As I noted, my mentioned design would require the calling code to know what you are pushing/retrieving, not the store/retrieve functions themselves (which would literally just care that they are void pointers and storing those in some sort of structure). It becomes the job of the programmer to hardcode those casts to the appropriate types based on the program flow. Of course that would also probably prevent you from doing true arbitrary willy-nilly pushes and pops from your data structure, but as mentioned there really isn't that much use for such a structure in the first place, as opposed to something with a regular order (say always pushing a person, then the object attacking them, then the attacking creature in that order, for example) which then means that on the other end you can just manually cast the first thing to person, the next one to the object, and the third to the creature. As I said, fragile and horribly unsafe, but it would work for the majority of use cases just fine (about which I am indeed interested as McTraveller is).

Well the example I gave was if you were making a Unity style game system and you wanted to chuck a whole lot of stuff into the scene, but you don't necessarily want to junk up everything with a strict object heirarchy and virtual function calls in every class. A universal "bucket" for putting things in could be handy, you could put raw level and object data into the same storage system, then write it all out to disk as a project file without them all needing to be known types. sure, any time you're reading types in, it could spit an error if the type you put in is one it hasn't been told about, but that won't necessarily stop you storing the data for later when you want to.

[Strife26]

Single-letter variable names other than loop iterators and mathematical expressions may be useful for you right now - but they are almost never useful six months from now trying to understand old code.

There is perhaps an exceptional case like you described, where there is some canonical single-letter variable like you mentioned.

Yeah, anything that needs to live beyond a single screen of code should be descriptive. The single letter variables are best only for the neon "This thing is being used only for a bit" sign they imply.

[Reelya]

I just decided to read the C++17 new features.

One of the things they're adding is "std::any", a type that can hold anything. I'm assuming it's based on templates. Kinda sounds like what I just made, huh?

http://stackoverflow.com/documentation/c%2b%2b/7894/stdany#t=201703212110185411053

And there's an "any_cast" template operator to try and cast it to something else, which returns an exception if it's the wrong type.

[milo christiansen]

Basically a type-safe void pointer?

[i2amroy]

Basically a type-safe void pointer?

Sounds like it, and it also would have actual object properties rather than you needing to finagle pointer weirdness at times.

[lethosor]

I received the Raspberry Pi for the STEM club's ballooning project, just to play with it and get used to it. Installed Python 3 and a GPIO module named RPi.GPIO and wait why is there a period in the module name

Even if it's technically allowed, why? Why, you madmen? You literally have to import it under an alias that doesn't have a period or else it will be impossible to use.

I'm not quite sure what you're saying. Does the filename (or folder name) of the module itself have a dot in it? If not, it's entirely possible to import and use modules with dots in their names normally - see "os.path", for example.

I think you could use an array of struct pointers that contain a type_info and void pointer.

That's basically what Reelya's original linked list was.