C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›641 »

RussianManiac: Dec 27, 2005; by Ozmaugh

Chuu posted:

Thanks for the replies. I guess besides the comp-sci 101 examples (tail recursion, loop unrolling, inlining, copy prevention) I don't have a good sense of what's easily optimized and what isn't. Is there some good reference out there that explains modern compiler optimizing techniques?

I am seconding this as well as perhaps recommendations on literature about manual C++ optimization tricks.

# ? Jan 5, 2010 05:26

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 08:45

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

RussianManiac posted:

I am seconding this as well as perhaps recommendations on literature about manual C++ optimization tricks.

There's only one trick: profile.

# ? Jan 5, 2010 05:28

Murodese: Mar 6, 2007; Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

Say I have a vector containing objects with the base class shape, where each derived class of shape has a differing draw() function. How do I call the correct draw()? It's defaulting to Shape's draw(). I'm assuming I have to cast it to the appropriate object type before calling draw, so can anyone tell me an easy way of doing so?

ie.

code:

class Shape
{
public:
  virtual void draw()
  {
    // something random
  }
};

class Circle : public Shape
{
public:
  void draw()
  {
    // something else
  }
};

int main()
{
  std::vector<Shape> objects;
  
  // add some objects to the vector etc

  for (std::vector<Shape>::iterator it = objects.begin(); it != objects.end(); it++)
  {
    it->draw(); // always calls Shape.draw()
  }
}

# ? Jan 5, 2010 05:48

seiken: Feb 7, 2005; hah ha ha

Chuu posted:

Thanks for the replies. I guess besides the comp-sci 101 examples (tail recursion, loop unrolling, inlining, copy prevention) I don't have a good sense of what's easily optimized and what isn't. Is there some good reference out there that explains modern compiler optimizing techniques?

Don't know if you're looking for something on the web but I believe this is pretty much the general compiler bible: http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811 (second half of the book is mostly optimization)

# ? Jan 5, 2010 05:50

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Murodese posted:

Say I have a vector containing objects with the base class shape, where each derived class of shape has a differing draw() function. How do I call the correct draw()? It's defaulting to Shape's draw(). I'm assuming I have to cast it to the appropriate object type before calling draw, so can anyone tell me an easy way of doing so?

Read up on object slicing. You're creating an array of Shapes, not an array of subclasses of Shape. (This would be more apparent if Shape were abstract.)

# ? Jan 5, 2010 05:55

Murodese: Mar 6, 2007; Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

Avenging Dentist posted:

Read up on object slicing. You're creating an array of Shapes, not an array of subclasses of Shape. (This would be more apparent if Shape were abstract.)

Brilliant, thanks. Works perfectly now.

# ? Jan 5, 2010 06:12

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

seiken posted:

Don't know if you're looking for something on the web but I believe this is pretty much the general compiler bible: http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811 (second half of the book is mostly optimization)

Izzat so? I've got red dragon and it doesn't hit optimization very hard at all. Guess it's good they improved it! (Not so good that purple dragon costs 16x as much as a good used copy of red dragon...)

# ? Jan 5, 2010 06:59

csammis: Aug 26, 2003; Mental Institution

Otto Skorzeny posted:

Izzat so? I've got red dragon and it doesn't hit optimization very hard at all. Guess it's good they improved it! (Not so good that purple dragon costs 16x as much as a good used copy of red dragon...)

The added chapters are pretty much all optimization-related. I'm in the same sort of situation as you, I have the first edition and am sad that I can't really afford it now that I'm not in school with a good excuse

# ? Jan 5, 2010 14:06

immakiku: Sep 15, 2003; Smart Newbie

csammis posted:

The added chapters are pretty much all optimization-related. I'm in the same sort of situation as you, I have the first edition and am sad that I can't really afford it now that I'm not in school with a good excuse

Get an international copy from abebooks. I lost my original purple dragon but never finished reading the book so I bought an international edition for like 1/3 the price. It's still in English.

# ? Jan 5, 2010 17:07

tef: May 30, 2004; -> some l-system crap ->

The international version doesn't have a dragon

http://www.amazon.co.uk/Compilers-Principles-Techniques-Alfred-Aho/dp/0321491696/

# ? Jan 5, 2010 17:16

immakiku: Sep 15, 2003; Smart Newbie

tef posted:

The international version doesn't have a dragon

http://www.amazon.co.uk/Compilers-Principles-Techniques-Alfred-Aho/dp/0321491696/

I don't think it's the dragon we'd be buying the book for... but who knows.

EDIT: Actually now that I think about it - someone stole my original dragon book. God drat.

# ? Jan 5, 2010 17:23

ehnus: Apr 16, 2003; Now you're thinking with portals!

Chuu posted:

Thanks for the replies. I guess besides the comp-sci 101 examples (tail recursion, loop unrolling, inlining, copy prevention) I don't have a good sense of what's easily optimized and what isn't. Is there some good reference out there that explains modern compiler optimizing techniques?

http://llvm.org/svn/llvm-project/llvm/trunk/lib/Transforms/

Most of the transforms are at least briefly annotated as to what the optimization pass does in a header block.

# ? Jan 5, 2010 18:00

king_kilr: May 25, 2007

csammis posted:

The added chapters are pretty much all optimization-related. I'm in the same sort of situation as you, I have the first edition and am sad that I can't really afford it now that I'm not in school with a good excuse

I thought they also added chapters on GC?

# ? Jan 5, 2010 19:25

csammis: Aug 26, 2003; Mental Institution

king_kilr posted:

I thought they also added chapters on GC?

That's why I hedged it with "pretty much." I've only had the opportunity to glance over it in a bookstore

immakiku posted:

Get an international copy from abebooks.

Not a bad idea, though how will people know and appreciate that it's the dragon book when they gaze at my bookshelf??

# ? Jan 5, 2010 19:47

immakiku: Sep 15, 2003; Smart Newbie

csammis posted:

Not a bad idea, though how will people know and appreciate that it's the dragon book when they gaze at my bookshelf??

That, sir, is a privilege you pay for. The paper on which the US dragon book is printed is of great quality. The print/typography was very pleasant as well. The whole book just feels (felt) very nice.

When I sold my books back to the university bookstore after I was done with them, this was one of the only books I would've kept. Too bad I couldn't keep it. When I have a bookshelf an original copy of this will be sitting proudly alongside TAOCP.

# ? Jan 5, 2010 19:56

RussianManiac: Dec 27, 2005; by Ozmaugh

Is there a good reason for C++ iso to be forbidding initializing static member variable that are non-const? Also is there a way to initialize them without having to do it from main(), i.e. something like C++ static block?

# ? Jan 5, 2010 21:41

RussianManiac: Dec 27, 2005; by Ozmaugh

Also, can I always depend on uninitialized static int in class to be always initialized to zero for me by compiler?

# ? Jan 5, 2010 21:46

Painless: Jan 9, 2005; Turn ons: frogs, small mammals, piles of compost
Turn offs: large birds, pitchforks
See you at the beach!

RussianManiac posted:

Is there a good reason for C++ iso to be forbidding initializing static member variable that are non-const? Also is there a way to initialize them without having to do it from main(), i.e. something like C++ static block?

A static member declaration just declares that a member exists - you need to initialize it separately in some translation unit. Lack of initialization should result in a linker error.

code:

foo.h:
..
struct foo { static int i; };

foo.cpp:

int foo::i = 10;

Note that the general rules about global variable initialization order apply.

# ? Jan 5, 2010 21:50

That Turkey Story: Mar 30, 2003

RussianManiac posted:

Also, can I always depend on uninitialized static int in class to be always initialized to zero for me by compiler?

No, you can't even use an object static to a class at all if it's undefined because all you've done is declared it -- it's like trying to call a function that was declared but never defined. You can, however, rely on function-level statics to be 0-initialized.

# ? Jan 5, 2010 22:37

RussianManiac: Dec 27, 2005; by Ozmaugh

Here is an interesting possible C optimization that I don't completely understand that may have to do with architecture specific stuff like SSE support.

I made a program that compares the speed of sequential ifs to nested ?

code:

#include <iostream>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/timeb.h>
#include <sys/time.h>

unsigned long long getTimeSpan( timeval & start, timeval & end )
{
	if( start.tv_sec == end.tv_sec )
		return end.tv_usec - start.tv_usec;
	return (end.tv_sec - (start.tv_sec + 1)) * 1e6 + (1e6 - start.tv_usec) + end.tv_usec;
}

using namespace std;

const unsigned int iter=1e9;

int main()
{

	timeval start,mid,end;
	int x,y;
	gettimeofday(&start,NULL);
	x = 0;
	for(unsigned int i = 0; i < iter;++i)
	{
		if( i % 2 )x+=1;
		else x+=2;
			
		if( i % 3 ) x+=3;
		else x+=4;
	
		if( i % 4 ) x+= 5;
		else x+= 6;

		if( i % 5) x+= 7;
		else x+= 8;
	}
	gettimeofday(&mid,NULL);
	y=0;
	for(unsigned int i = 0; i < iter;++i)
	{
		y += (i%2?1:2)+(i%3?3:4)+(i%4?5:6)+(i%5?7:8);	
	}
	gettimeofday(&end,NULL);
	cout<<"x="<<x<<endl<<"y="<<y<<endl;
	cout<<"ifs timing:\t"<<((double)getTimeSpan(start,mid)/1e6)<<endl;
	cout<<"? timinig:\t"<<((double)getTimeSpan(mid,end)/1e6)<<endl;	
}

As you can see logically they are equivalent.

Without -O3 compiler option ? way is clearly much faster, however with -O3 turned on interesting stuff happens.

On my home computer Ifs are clearly faster. My g++ version is 4.4.1 and /proc/cpuinfo can be found here: http://pastebin.com/f219b5d26

and here are some print outs from console:

code:

xxx@zao:~$ ./a.out 
x=103464150
y=103464150
ifs timing:	5.11236
? timinig:	6.80465
xxx@zao:~$ ./a.out 
x=103464150
y=103464150
ifs timing:	5.13008
? timinig:	6.79123

However when I compile with -O3 on my school's computer ?s clearly come out on top. School server's cpuinfo is here: http://pastebin.com/f45f2f197 and the g++ version on that machine is 4.3.3

and here are some timings on that machine:

code:

x@x:~$ ./a.out 
x=103464150
y=103464150
ifs timing:	7.30589
? timinig:	6.70621
x@x:~$ ./a.out 
x=103464150
y=103464150
ifs timing:	7.29803
? timinig:	6.70564
x@x5:~$ ./a.out 
x=103464150
y=103464150
ifs timing:	7.29701
? timinig:	6.71126

Does anybody know why that might be? I have suspicion it could be that compiler on school's machine is actually optimizing for sse, but I am not sure. I could use -S to help with this interesting question right? But I am not sure what I would look for in there.

Also if it is SSE optimization then how come g++ on my ubuntu doesn't do same thing?

EDIT:
Here is -S output from my machine's G++: http://pastebin.com/f53809216
and here is from the school's machine: http://pastebin.com/f1ede88e6

RussianManiac fucked around with this message at 01:21 on Jan 6, 2010

# ? Jan 6, 2010 01:16

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Hey yeah let's talk about micro-optimization and not look at assembler output.

EDIT: Ok you're halfway there. Now use something sane like objdump.

# ? Jan 6, 2010 01:22

RussianManiac: Dec 27, 2005; by Ozmaugh

Avenging Dentist posted:

Hey yeah let's talk about micro-optimization and not look at assembler output.

EDIT: Ok you're halfway there. Now use something sane like objdump.

I just don't know much at all about assembler. Yea I don't know maybe this thread is not right for this, but I thought this was interesting and wanted to see if it was also interesting for more experienced programmers that might be able to discern the assembly output.

# ? Jan 6, 2010 01:27

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

RussianManiac posted:

I just don't know much at all about assembler. Yea I don't know maybe this thread is not right for this, but I thought this was interesting and wanted to see if it was also interesting for more experienced programmers that might be able to discern the assembly output.

It's not that interesting. If you actually look at it via objdump, it should be easy to tell why the 4.3 version is slower when using if statements. Technically, it should be easy to tell anyway, but reading unannotated assembly is bothersome.

# ? Jan 6, 2010 01:35

Fecotourist: Nov 1, 2008

The school's compiler is using conditional moves, yours is using conditional branches. If the CPU's branch predictor can't figure out the branch, cmov will be faster.
Linus is full of poo poo when he says cmovs are worthless.

# ? Jan 6, 2010 06:20

Sarenya: Feb 16, 2006; I'm a Desktop Adapter

Let's talk about class invariants in C++!

I would like to be able have the compiler enforce class invariants in C++, ideally in a way that doesn't in any way interfere with the standard C++ that we all know and... know. "Enforcing" by calling assertions or any block of code that I've provided is fine.

I have two seen approaches that seem to solve this problem somewhat. The first is the Boost "DBC" not-really-a-library, available at http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Correctness%20-%20Testing/Contract . This actually solves the vast majority of the design-by-contract problems that people would want solved, but it does it in a quite that is very invasive to the code the contracts should be enforced on. (Examples are in the archive available from Boost.)

The second approach is described in a paper that I just realized right now is written by Bjarne Stroustrup called "Wrapping C++ Member Functions Calls", available at http://www2.research.att.com/~bs/wrapper.pdf . This is much closer to what I would like to be able to do -- it's invasive only to the extent that any calls through a normal pointer won't be wrapped. This is quite a clever bit of coding that unfortunately can't be applied to, say, postconditions.

Ideally I'd like to able to have a "check invariants" function somewhere and have it run after all (public) member function calls. Am I missing a middle ground somewhere or a very clever solution?

# ? Jan 7, 2010 13:44

immakiku: Sep 15, 2003; Smart Newbie

Hmm what you want is not for the compiler to statically enforce your design contracts, but for it to automatically generate code to dynamically check class invariants, right?

EDIT: I just read through the paper. It looks like it does check post-conditions. You won't be able to use just a pointer like X*, but you can get both pre and post conditions as long as you use a wrapping class. What is it you want that the paper doesn't provide?

EDIT2: This is the test program he provided and output it generates. How isn't this what you wanted?

code:

int main() // simple test code
{
  Wrap<X> xx (new X);
  Wrap<Y> yy (new Y);
  if (xx->f()) cout << "done\n";
  xx->g ();
  yy->h ();
  return 0;
}

Bjarne posted:

Each call of x x and y y is bracketed by a pair of prefix()/suffix() calls, so the program produced:
make an X
make a Y
prefix f() suffix
done
prefix g() suffix
prefix h() suffix

immakiku fucked around with this message at 23:50 on Jan 7, 2010

# ? Jan 7, 2010 23:36

Sarenya: Feb 16, 2006; I'm a Desktop Adapter

immakiku posted:

EDIT2: This is the test program he provided and output it generates. How isn't this what you wanted?

Ah, I should have been more clear. When I said "post-conditions" I meant "per-function post-conditions". This is possibly a failing of my understanding of the terms, but I've always interpreted pre-/post-conditions as per-functional-unit and invariants as per-class/state/whatever.

As for using the wrapping class, this only helps when you're in control of the entirety of the code. If you have external higher-level code calling into your code, you can't guarantee that they're going to use your wrapper class. If you're using someone else's library, you can't guarantee that the calls they're making to their objects or your objects will be wrapped.

(There are ways of solving the first problem but all of them that I'm aware of require doing things that muck with the layout/access privileges of the classes in a way I'd like to avoid.)

That said, I really do like that paper. I'm really sad the DBC stuff that was originally being discussed for C++0x didn't make it in, but as low-impact approximations go I'm really impressed with it.

# ? Jan 8, 2010 04:00

immakiku: Sep 15, 2003; Smart Newbie

Hmm how do you imagine the pre/post conditions would look like in code (if there was support for it)? You would still have to specify the conditions for every function, so it's almost the same as writing it into the function itself, no?

And as for forcing users to check class invariants, can't you just ship the custom wrapper as your code instead of your original class? So instead of Shape, you'd ship a class that was Wrap<Shape> instead.

And... if you're using someone else's library, how do you intend to check their class invariants? A lot of that should be hidden from the library's interface anyway...

immakiku fucked around with this message at 15:25 on Jan 8, 2010

# ? Jan 8, 2010 15:22

ffhighwind: Jan 10, 2010

How do you handle rules that use class inheritance in Boost Spirit/Fusion?

I'm making a parser for a .pov format raytracer file.
http://pastebin.com/m19397bdc

I'm getting the compiler error at the top of the file for the following rule:
rModifier = rTranslate | rRotate;

class Modifier {};
class Translate : Modifier {...};
class Rotate : Modifier {...};
BOOST_FUSION_ADAPT_STRUCT(Translate,...)
BOOST_FUSION_ADAPT_STRUCT(Rotate,...)

rule<Iter, Modifier, ascii::space> rModifier;
rule<Iter, Translate, ascii::space> rTranslate;
rule<Iter, Rotate, ascii::space> rRotate;

# ? Jan 10, 2010 23:44

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

You're not using inheritance right in the first place. Think about what an std::vector<Modifier> is really storing when you try to put a Translate in it.

# ? Jan 11, 2010 00:43

ffhighwind: Jan 10, 2010

rModifier %= rTranslate | rRotate;
The right side of the rule I think is of type variant<Translate, Rotate> which isn't compatible with type Modifier. I'm a newbie at C++ and the Boost library, so I might have to do some more research before giving a better reply. I tried the following but I get a big template error.

struct Translate;
struct Rotate;
class Modifier : boost::variant<Translate, Rotate> {};
//Might have to implement some abstract methods...?

struct Translate {...}

Beginning of error:
1>...\boost\type_traits\is_pod.hpp(34) : error C2139: 'Translate' : an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_pod'
1> ...\basemain.cpp(72) : see declaration of 'Translate'

# ? Jan 11, 2010 01:27

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

ffhighwind posted:

rModifier %= rTranslate | rRotate;
The right side of the rule I think is of type variant<Translate, Rotate> which isn't compatible with type Modifier. I'm a newbie at C++ and the Boost library, so I might have to do some more research before giving a better reply. I tried the following but I get a big template error.

The error tells you exactly why: you haven't defined the classes by the time you reach the point of instantiation of the variant template. Besides that, it'd be a lot easier not to bother with a variant, since it gives you nothing (both classes are identical). Just use

code:

struct Modifier
{
    int type; // or an enum
    Point3f p;
};

Avenging Dentist fucked around with this message at 01:47 on Jan 11, 2010

# ? Jan 11, 2010 01:44

ffhighwind: Jan 10, 2010

quote:

it'd be a lot easier not to bother with a variant, since it gives you nothing (both classes are identical). Just use

quote:

you haven't defined the classes by the time you reach the point of instantiation of the variant template

I'm not sure if this means the class/template definition or actual object instantiation. Modifier and the two subclasses use circular referencing in their definitions so I have to leave an empty definition of them above and fill it out later, though I may be doing something wrong.

# ? Jan 11, 2010 02:51

Sarenya: Feb 16, 2006; I'm a Desktop Adapter

immakiku posted:

Hmm how do you imagine the pre/post conditions would look like in code (if there was support for it)? You would still have to specify the conditions for every function, so it's almost the same as writing it into the function itself, no?

For an (outdated) example of the original C++0x proposal, see http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1866.html#function-pre-and-postconditions . I would settle for something like (this is all terrible):

code:

void func( int intArg, string& stringArg )
{
  precondition( intArg > 0 );
  precondition( stringArg.contains( string( intArg ) );
  postcondition( !stringArg.contains( string( intArg ) );

  // ...
  // regular code
}

As you note, preconditions are exactly identical to "asserts at the start of the function". Generalized postconditions are problematic for a wide variety of reasons, all of which I'm trying to avoid by focusing exclusively on class invariants.

immakiku posted:

And as for forcing users to check class invariants, can't you just ship the custom wrapper as your code instead of your original class? So instead of Shape, you'd ship a class that was Wrap<Shape> instead.

This moves away from the standard "make a new object with new" flexibility, but more importantly I don't believe it works for, for example, a standard would-otherwise-be-on-the-stack 3D vector. Template fun can put the storage in the correct place as long as you can programatically define "the correct place", but operator overloading wouldn't work.

immakiku posted:

And... if you're using someone else's library, how do you intend to check their class invariants? A lot of that should be hidden from the library's interface anyway...

I agree in principal, but I can think of times when bugs in library code would have been much easier to track down if I could have said "this library object will always match this (externally-visible) criteria". For example, "after applying any force/timestep, this physics object will be located within the bounds of the world with a valid velocity".

# ? Jan 11, 2010 08:30

immakiku: Sep 15, 2003; Smart Newbie

Hmm I'm not sure what kind of flexibility is lost with that approach. By the way I don't have an actual answer to your original question; I'm just trying to see if what you wanted has actually already been proposed by Stroustrup.

Sarenya posted:

As you note, preconditions are exactly identical to "asserts at the start of the function". Generalized postconditions are problematic for a wide variety of reasons, all of which I'm trying to avoid by focusing exclusively on class invariants.

I guess the problem you have with instantiating a class at the beginning of the function (and using its destructor as your postcondition checklist) is that it's bulky and you'd have to define lots of extra classes? If so, you can probably get around extra definitions with macros.

Sarenya posted:

I agree in principal, but I can think of times when bugs in library code would have been much easier to track down if I could have said "this library object will always match this (externally-visible) criteria". For example, "after applying any force/timestep, this physics object will be located within the bounds of the world with a valid velocity".

I actually agree with that. Ideally you'd have the luxury of making your library makers do most of that work though.

# ? Jan 11, 2010 17:07

Sarenya: Feb 16, 2006; I'm a Desktop Adapter

immakiku posted:

Hmm I'm not sure what kind of flexibility is lost with that approach. By the way I don't have an actual answer to your original question; I'm just trying to see if what you wanted has actually already been proposed by Stroustrup.

Yeah, I appreciate the conversation. Being put in a position where I have to clearly define what I'm looking for and then evaluate options honestly has always been really useful for me.

immakiku posted:

I guess the problem you have with instantiating a class at the beginning of the function (and using its destructor as your postcondition checklist) is that it's bulky and you'd have to define lots of extra classes? If so, you can probably get around extra definitions with macros.

This is the best approach, but things start to get really messy when you want to verify postconditions against arguments passed in (in which case you have to feed them into the inner class), or even worse against things calculated within the function (in which case you either can't put the postcondition checks at the top, or you have to move your local variable declarations before them). Most annoyingly, you can't run checks against what would otherwise be class-local variables without passing in this.

If you rely on C++0x closures, then the first and third (!) problems are solved, but the second remains.

One nice thing about being forced to manually pass in this is that you can instead pass in const-this and then head off the inevitable "my assertions change state" bugs that would sneak in. I don't know if there's a way to const-capture this easily with C++0x lambdas.

immakiku posted:

I actually agree with that. Ideally you'd have the luxury of making your library makers do most of that work though.

I agree completely. I'm agreeing as hard as I can in hopes that it will become true.

# ? Jan 12, 2010 00:10

a slime: Apr 11, 2005

Is it possible to define member functions of a private nested class as non-inline? How?

# ? Jan 12, 2010 02:32

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

You have to define them out-of-line, but that shouldn't be a problem except in local classes (i.e. classes defined within functions).

code:

class Outer {
  class Inner {
    int member();
  };
};

int Outer::Inner::member() { ... }

# ? Jan 12, 2010 02:52

immakiku: Sep 15, 2003; Smart Newbie

Sarenya posted:

This is the best approach, but things start to get really messy when you want to verify postconditions against arguments passed in (in which case you have to feed them into the inner class), or even worse against things calculated within the function (in which case you either can't put the postcondition checks at the top, or you have to move your local variable declarations before them). Most annoyingly, you can't run checks against what would otherwise be class-local variables without passing in this.

If you rely on C++0x closures, then the first and third (!) problems are solved, but the second remains.

One nice thing about being forced to manually pass in this is that you can instead pass in const-this and then head off the inevitable "my assertions change state" bugs that would sneak in. I don't know if there's a way to const-capture this easily with C++0x lambdas.

Class local variables can (maybe) be solved by automatically friending the post-condition class. I'm not familiar enough with macros and templates to know if this claim is true.

Post-conditions for function locals should be defined after the variable declarations. Otherwise what scope would it take the variables from?

code:

int f(int x)
{
  postcond(a + b > 0);
  int b = 45;
  if( x > 20 )
  {
    int a = 5;
    return a;
  }
  else
  {
    string a = "oh noooooo";
    return x;
  }
}

Function arguments may be passed by reference, but then again that's very bulky.

# ? Jan 12, 2010 15:35

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 08:45

Contero: Mar 28, 2004

After finally getting Boost::Python to build (bjam or build or w/e could not find my python folder no matter how hard I tried. I finally got around to installing windows 7 today and that fixed the problem) I was a little worried that embedding Python wouldn't be as well supported as making modules.

So I was trying to expose my dumb greet function:

code:

void greet()
{
   cout << "hello world!" << endl;
}

And I couldn't for the life of me figure out how to do this. There is plenty of info on wrapping classes and making a module, but how do I expose just this one stupid function? In frustration I tried:

main_namespace["greet"] = greet;

Yeah right like that will just...

0 error(s), 0 warning(s)

Uhh...

>>> greet() hello world! >>>

:aaa:

In conclusion boost owns.

# ? Jan 12, 2010 18:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›641 »