mracer posted:

Ok, more of a Visual Studio question. Whats the best way to step thru code with many macros. you know #define functions.

for example:

code:

#define COPY_PMV(adst,asrc) {                      \
  Ipp32s nn;                                       \
  for(nn=0; nn<sizeof(adst)/sizeof(Ipp32s); nn++)  \
    ((Ipp32s*)adst)[nn] = ((Ipp32s*)asrc)[nn];     \
}

is there an option for the debugger to show that instead of COPY_PMV(pointer,pointer) ?

Entheogen posted:

when i do a left shift, does the left most bit get sent to some carry register? on x86 machines, what would be the name of it?
I guess same would go for the right shift and right most digit.

I know how this works in PIC Micro controller, but I have no idea of how i would go about using it in C or assembler for x86.

Lexical Unit posted:

Let's say that now I want to make my container exception safe. I'm not sure where I can find information on what parts of the STL are exception safe (and at what level). If anyone can recommend a book or website that would help in this area please do. I have Sutter's Exceptional C++, just not on hand at the moment, so if that's good enough just let me know. I can go re-read it now that most of it isn't over my head.

In the mean time my immediate quandary involves conceptually reassuring myself that the following is no-throw guarantee exception safe:

code:

template< /* ... */ >
class trie
{
/* ... */
	private:
		typedef trie* trie_node;

		struct trie_node_delete
		{
			void operator()(trie_node const &node) throw()
			{
				delete node;
			}
		};

		struct trie_node_less { /* ... */ };
		typedef std::set<trie_node, trie_node_less> subtrie;

		subtrie children;
};

template< /* ... */ >
trie< /* ... */ >::~trie() throw()
{
	for_each (this->children.begin (), this->children.end (), trie_node_delete ());
}

What I'm unsure of is what exception guarantees does for_each(), begin(), end(), and other functions that those functions entail give me? Is this exception safe or not? If it is, do I have the no-throw guarantee?

Space Duck posted:

I haven't touched C++ in a couple of years, so maybe I'm just missing something obvious, but this has me stymied.

I have a class I'm using to log events from my app, imaginatively named Log.

What I'm trying to do is have a container class (QueueRunner) that monitors and trigger events from a queue, and log those events, failures, etc.

I have a constructor in QueueRunner that takes a Log object, and from there, I can write whatever I want to the log:

code:

QueueRunner::QueueRunner (const Log &logTarget){
	eventLog = logTarget;
	eventLog << "Queue runner started.";
 
}

eventLog is a private data member of type Log. That code produces the expected entry in the logfile.

Any subsequent member of the QueueRunner class seems unable to write to the log, however. This code segment doesn't do what I'd expect:

code:

void QueueRunner::StartListening (char *address, int port){
	
	eventLog << "Opening Listen socket...";

It's not writing to the log file, but I'm not getting errors or segfaults, either. I know that the copy constructor for Log works, but I still think there's something I've overlooked.

Edit: the Log object and the QueueRunner objects are both instantiated in main().

Itaipava posted:

I thought the same thing, but I don't think it can be Log&. If it were the case, wouldn't eventLog -have- to be assigned to log in the constructor's initialization list?

I'm leaning towards Log's assignment operator copying the file stream because of that signature (const Log &).

Ari posted:

The question comes up pretty often as to the de facto library of books for learning various programming languages and concepts. In my experience reading threads discussing them and reading several of the books named, I think the general goon consensus is that Eckel's Thinking in C++ is the best one to pick up C++. But why are you learning both C and C++ at once?

Red Oktober posted:

I'm currently getting started in C, by using it to write a compiler of sorts (its for an assignment).

Much of the code is generated already by BNFC (from the grammar I've written) , but I need to edit it to traverse my tree and do stuff.

My question is what is a good development environment to start off in C?

I've been using eclipse for java, but the C version doesn't seem to be as usable.

What would you all recommend?

I'm using Mac OS X, if it matters.

HB posted:

What about a project with 40 source files and multiple targets?

At some point you just want to let the computer take care of it.

tef posted:

Also,

[code]
str = (char *)calloc(strlen(visitIdent(_p_->u.stm_.ident_))+2, sizeof(char));

Should be:
str = malloc(strlen(visitIdent(_p_->u.stm_.ident_))+2);
[code]

As sizeof(char) is always 1.

GT_Onizuka posted:

Oh wow, that certainly helped out quite a bit. I'm getting some errors, but they seemed to be related to the libraries. Considering how old things are, I suppose I shouldn't be too surprised. Thanks again, I'm almost on my way!

EDIT: I know this is a long shot, as it's some random library, but I figure it's worth a shot. Here's the error I get:

code:

plotview.o: In function `Min_circle_2<Point*>':
/usr/include/CGAL/Min_circle_2.h:326: undefined reference to `CGAL::default_random'
plotview.o: In function `void CGAL::circumcenter_translateC2<float>(float const&, float const&, float const&, float const&, float&, float&)':
/usr/include/CGAL/constructions/kernel_ftC2.h:60: undefined reference to `CGAL::assertion_fail(char const*, char const*, int, char const*)'
plotview.o: In function `CGAL::Min_circle_2<CGAL::Min_circle_2_traits_2<CGAL::Cartesian<float> > >::compute_circle()':
/usr/include/CGAL/Min_circle_2.h:263: undefined reference to `CGAL::assertion_fail(char const*, char const*, int, char const*)'
collect2: ld returned 1 exit status
make[3]: *** [wcurve] Error 1
make[3]: Leaving directory `/home/ynadji/wcurve/wcurve'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ynadji/wcurve/wcurve'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ynadji/wcurve'
make: *** [all] Error 2

All the errors seem to be within CGAL, so I haven't the slightest clue what's going on. Any ideas?

Incoherence posted:

erase takes an iterator parameter. You probably want alphabet.erase(alphabet.begin()+j). Why is it this hard? Because the STL is weird.

Thug Bonnet posted:

No, that's what I'm asking! I'm just kind of curious, honestly. But how would the program know "where it is" in memory, how large it is, etc. Also, I assume it's not necessarily contiguous..

xobofni posted:

Really stupid question here about pointers in C.

This code runs just fine.

code:

int main ()
{
    char a[] = "hello world";
    a[0] = 'b';
    return 0;
}

This code crashes.

code:

int main ()
{
    char *a = "hello world";
    a[0] = 'b';
    return 0;
}

I thought those declarations were exaclty the same, but apparently they are not. What am I missing here?

Mr VacBob posted:

If you're debugging an optimized program, the debug info is probably wrong and giving you nonsense answers.

Hyphen-ated posted:

I am using VC++ 2005 express. I have sections of code that are #if'ed out sometimes. When editing this code, VC++ decides to gray it out and disable "go to definition" and friends in the context menu. This makes it more difficult to edit this code, which does actually get compiled sometimes. I would like it to treat all code as live code regardless of whether it looks like it will be compiled.

I can't find anything relevant in any of the config screens. How do I do this?

e: I can make the code not be grayed out from tools>options>text editor>c/c++>formatting, but that doesn't enable "go to definition"

Drx Capio posted:

It can't. The compiler MUST know the size of One in order to compile Two. It can be done with a level of indirection, though:

code:

class One;

class Two
{
  One* one;
};

This works because pointers to any type are always the same size, and the compiler just needs reassurance that 'One' isn't a typo.

floWenoL posted:

Honestly that's not a very large project; have you tried building one of Firefox, KDE, or OpenOffice lately? Anyway, the issue is not the from-scratch build time, but the one-line-header change build time and from making sure that that isn't approximately equal to the from-scratch build time.

6174 posted:

I've got a template function in which I'm doing a comparison like:

code:

if (number < 0) {
    number *= -1;
}

number is of type T. When T is an unsigned type the compiler gives me a warning:

../shared/number_stuff.h:102: warning: comparison of unsigned expression < 0 is always false

Is there anyway I can reasonably make these warnings go away? I tried enclosing it in an if (numeric_limits<T>::is_signed) block, but the compiler still complains.

That Turkey Story posted:

Oh my lord... I hope that isn't what he was using std::vector for!

SintaxError posted:

I could be wrong, but I don't think your remove function should be declared/defined as const.

Avenging Dentist posted:

It is an issue. I'm assuming the "converting NULL to double" error occurs at return NULL; in your code. That's bad because NULL isn't a valid value for non-pointer, non-integral types. It's performing an implicit conversion from a pointer (integer) type to the type of the elements in your list. Think about what would happen if there is no such conversion...

KaeseEs posted:

If it's an option, replace cout with cerr while debugging (STDERR is unbuffered). Otherwise, look up setbuf(3).

vanjalolz posted:

Pointer and int are usually the same size though...

Smackbilly posted:

I could certainly consolidate timeout handling into one thread, but that would make the code messier and more complicated, so I'm inclined to avoid that unless there is a good reason to do it.

Zombywuf posted:

Why are you emulating TCP?

HB posted:

Lots of games using UDP with a very thin reliable layer on top of it. It can be tweaked to better match their traffic patterns (small packets, no bulk transfers, compensation for loss at the application layer) than TCP.

floWenoL posted:

On the other hand, it introduces an invalid value (kNumWhatever) that is treated like a valid value.

chutwig posted:

Okay, I understand my first mistake; forgetting that the pointer is its own type with a different size from what it points to.

That being said, I guess I need to issue a malloc for bs_tm and then have it write to that, and probably also malloc the other pointers before I write to them.

I know I don't completely understand pointers yet; that's why I'm undertaking this now, so that I become more aware of manual memory management rather than simply letting the computer always do it for me. Just telling somebody to read K&R again doesn't help much when dealing with something like pointers that is very complex.

slovach posted:

It's pretty simple actually.

code:

#include <windows.h>

char target[] = "\\test.exe";
char path[MAX_PATH];
STARTUPINFO         si = { 0 };
PROCESS_INFORMATION pi;

int main(){
	si.cb = sizeof(STARTUPINFO);
	GetCurrentDirectory((MAX_PATH - sizeof(target)), (LPSTR)&path);
	lstrcat((LPSTR)&path, (LPSTR)&target);
	CreateProcess((LPSTR)&path, NULL, NULL, NULL, FALSE, 
				  NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi);
}

edit: I like how my pi turned into an actual PI... at least that's what I think it did? wtf.

floWenoL posted:

What do you guys think of this?

Avenging Dentist posted:

Also the "no using in .cc files" rule is laffo. That's pretty much the only place you should have using declarations.

That Turkey Story posted:

ZorbaTHut posted:

Real-world numbers tend to follow a power distribution, and in power-distribution-land, that extra bit increases your number's range by a piddling 3%. That's usually not anything worth mentioning.

ZorbaTHut posted:

It would be hard for me to disagree with more points here

First, the only thing I agree with: Yes, using iterators bypasses the issue of sign nicely. Sometimes, however, that's just not practical - I'm giving a small example of a situation where it breaks in an unexpected and subtle way, not a fullfledged example of a case where it's an inevitable bug (since I don't believe those exist.)

ZorbaTHut posted:

It's just not something that ever comes up - I consider this to be well within the bounds of "this never happens".

ZorbaTHut posted:

And even if it does, I'd say a better solution would be to use a longer signed type, like "long" (which will be 64-bit on virtually any sane system where .size() can be 1<<31)

"ZorbaTHut posted:

or "long long" (which will be 64-bit and which is nearly part of C++), not an unsigned type, for the same power-distribution reasons I mentioned beforehand.

ZorbaTHut posted:

Also, saying "if you write it correctly, it always works! " is kind of meaningless, because obviously it'll work if you write it correctly. What I'm getting at here is that unsigned variables make it much easier to introduce subtle unexpected bugs, thereby either reducing the chance that you'll write it correctly or increasing the amount of effort and time it takes to write it correctly (take your pick) while signed variables avoid a small but significant class of errors.

Entheogen posted:

oh ok, i see what you are saying. even though macro is replaced by pre-compiler with whatever it is defined to, if data is a function call it will be evaluated 15 times.

Entheogen posted:

how exactly does one link statically instead of dynamically in c++?

the only way to link dynamically would be against a DLL or SO file?

when I include .h files in my C++ program and it is linked against a .lib file is that static linking by default?

Avenging Dentist posted:

Pointers are very important, since they allow objects to have other-than-lexical scope. If you make an object on the stack in a function and return a reference to it, that object will get destructed when the function returns. It's also necessary for dynamically-sized data.

quote:

I don't use "design patterns" as such for any of my projects. Granted, a design-pattern nerd will probably look at my code and say "oh well this is a clear example of design pattern X", but I just write code in whatever way I find to be most elegant.

quote:

God yes. This isn't Java, and it makes no sense to have a class that can't actually be instantiated. Use a namespace if you need to encapsulate all the functions, or just leave them global if you don't care.

quote:

They do add overhead, in that a function that may throw needs to be compiled such that it can "return" at arbitrary points in its execution. Additionally, exceptions require some form of RTTI (run-time type identification) in order to inspect the exception's type when caught.

That said, if you have to ask, it's not important for what you're doing.

Centipeed posted:

I've checked out Bjarne's book on C++. It seems comprehensive. I've also taken a look at Thinking in C++.

Is there a book I can get hold of that takes C++ programming and explains each and every detail in layman's terms? Or gives metaphors to help understanding. I find myself reading some sentences or paragraphs in "The C++ Programming Language" several times in an effort to digest them.

A book which can be used as sort of a reference for explaining concepts in plain English rather than relying on other programming concepts would definitely be helpful.

Like, is the C++ For Dummies book any good? I'd imagine that would break things down well enough.

Entheogen posted:

code:

#define FOREACH(_it,_l) for(__typeof((_l).begin()) _it=((_l).begin());(_it)!=(_l).end();(_it)++)