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

«‹›2 »

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

fret logic posted:

Awesome, this'll be a good place to ask.

Which should I learn, or if both, which first?

I'd say C first because C++ changes very little from C but throws a ton of other things your way as well that can be very overwhelming initially.

fret logic posted:

I'm currently learning Java in school, and I'd like to pick up another language along the way. I'm also a little confused. Is there a difference between C++ and Visual C++? Does the Visual part of it just mean the Microsoft IDE, or is it more to do with libraries and specifically GUI programming?

It's pretty much Microsoft's C++ distribution which includes the compiler, IDE, and some associated libraries. It's a bit of a misnomer, you don't need to do anything 'visual' with it at all, I use it at work and most of my programming just spits output to the console

# ¿ Feb 16, 2008 05:15

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 05:34

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

FigBug posted:

Are there any free or cheap profilers for windows?

AMD's Code Analyst is pretty good and completely free: http://developer.amd.com/tools/codeanalystwindows/Pages/default.aspx

# ¿ Mar 2, 2008 16:22

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

On Windows you can take the address of the __ImageBase symbol which points to the DOS header of the executable. From there you can find the PE header (the offset of which is located at 0x3C + __ImageBase) and parse it according to the PE/COFF format and figure out which sections are there and how large they are. This won't work for dynamically loaded libraries, you'll have to do something similar by finding the modules base address and going from there.

ELF files work similarly, I believe the symbol most commonly used is __executable_start, which you can cast to the ELF header and interpret from there

# ¿ Mar 11, 2008 06:47

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

vanjalolz posted:

edit: both of which mean the same thing! Ok I get it, but I still disagree. Its messy and confusing! the standard is typedef struct x_t { ... } x, *px; so stick with it

Whose standard is that?

# ¿ May 3, 2008 22:20

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

Smackbilly posted:

Always and never, respectively. There's no reason to use C I/O functions in C++ when there are C++ I/O functions that do everything the C functions do.

One big reason to avoid C++ I/O functions is that they add an implicit dependency on exception handling mechanisms which isn't always an acceptable option.

Smackbilly posted:

In some respects "using namespace" is poor style because you're polluting your current namespace with lots of variables that you may not really need. You can be more restrictive by writing "using std::cout;" and "using std::endl;", etc, to import specific variables from another namespace.

In practice there's nothing wrong with "using namespace ...", in fact as someone who used to work in QA I greatly encourage people to use it because seeing fully qualified names littered throughout code is ugly as sin and in an individual translation unit there's no real danger regarding namespace pollution. The exception to this is in public header files -- people who import namespaces in public headers need to be shot.

# ¿ May 30, 2008 03:23

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

Mustach posted:

That's not a big reason for any beginner.

I didn't see the "for the beginner" qualification in the post I was responding to, just a blanket qualification that there's no reason to ever choose standard C I/O over C++ I/O.

Smackbilly posted:

Okay but if you're eschewing all forms of exceptions, then you're also tossing out STL and basically working in C-with-classes. I suppose some people do that, though.

A language isn't its standard library.

floWenoL posted:

Except the C++ I/O functions are much more verbose and heavyweight. Also, good luck using C++ I/O for binary I/O.

Yeah, they're not that intuitive. Compare

code:

printf("%08x\n", 0xc0ffee);

code:

cout.fill('0');
cout.width(8);
cout << hex << 0xc0ffee << endl;

Which isn't really that intuitive. Why do I set the fill character with cout.fill() but hex formatting by passing in that "hex" value? Why can't I do something like

code:

 cout <<< fill('0') << width(8) << hex << 0xc0ffee << endl;

instead? Why do I manually have to remember and reset the fill and width parameters for the next field I want to output?

Needless complexity bugs me and the C++ standard library unfortunately is full of it (vector<bool>, I'm looking at you).

# ¿ May 30, 2008 05:59

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

Clanpot Shake posted:

I've got a little problem I need solved. I'm coding in C++ and need to connect to a Microsoft SQL database, but I can't use .NET, I can only use straight C++. How do I go about doing this?

Microsoft's ODBC documentation is probably a good place to start: http://msdn.microsoft.com/en-us/library/ms710252%28VS.85%29.aspx

This functionality should be included in the Windows Platform SDK

# ¿ Jun 2, 2008 19:06

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

Forward declarations will only work for pointers or references, where the compiler doesn't need to figure out the size of the type. In your "Another" class, it will have to contain either a pointer or reference to SomeClass. It's a pretty common usage pattern

# ¿ Jun 12, 2008 05:14

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

Avenging Dentist posted:

Macros are evil, and unless you absolutely have to, it's preferable to use an inline function to enforce type safety and all that good stuff.

Inline functions are all fine and dandy until your compiler decides that, no, it doesn't actually want to inline any more.

# ¿ Jul 5, 2008 01:25

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

Zombywuf posted:

Your compilers guess as to whether it should inline is probably as good as yours. It's a bit of a black art.

Actually, no. Really lovely compilers like Metrowerks pretty much force you to forego inline functions and use macros to avoid function calls. VC++ and GCC which are far better in this area can still inject unwanted function calls, even when using stronger inline hints like __forceinline.

# ¿ Jul 5, 2008 21:37

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

I've fought the compilers may times on these fronts, off the top of my head the last time this was specifically an issue was for vectorized trigonometry routines. The only way I could get them inline consistently was to turn them into a macro

# ¿ Jul 5, 2008 22:40

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

ValhallaSmith posted:

Anyone familiar with LLVM? http://llvm.org/ How does it compare to Phoenix? I've been wanting to do a few experiments with targeting very specific CPUs and it seems like a good fit.

Also, what magic is it that lets MS compilers get a 10-20% edge on GCC/LLVM? Does MS have some crazy superior optimization in the compiler? Or is it because they have a superior library?

I work on LLVM daily at work as we use it as a compiler back end, targetting x86 and some PowerPC variations, for languages that we maintain. I don't have any experience with Phoenix so I can't really say how the two compare.

One thing the LLVM project has been quite adamant about is not including optimizations that may be patented and if I recall a few have had to be removed from the project because of this reason. It does get better and better with each successive release, though I haven't done a thorough LLVM vs MSVC comparison yet.

# ¿ Jul 13, 2008 23:36

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

crazypenguin posted:

Any the last little bit probably comes from the fact that Microsoft mostly just has x86 to worry about, while GCC is more general and supports a ton of different architectures. So they may have the opportunity to push things like vector optimizations up to a higher level than crammed down at the bottom in the instruction selection phase.

Microsoft works on several back ends for their compilers, including x86, x86-64, IA-64, PowerPC, ARM, SuperH, and MIPS. I imagine x86 gets a lot of energy directed toward it but such a wide variety of processor support means they can't bias toward it too much.

# ¿ Jul 14, 2008 00:45

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

I've whipped a Gaussian random variate generator in C++ that generates numbers via a rejection technique and thrown in an implementation of the Mersenne Twister random number generator for fun. It has no dependencies aside from the standard math library

http://av8r.ca/~max/gaussian.cpp

The only thing to be aware of is that you need to call twister_initialize() before calling gaussian() otherwise you won't get any valid numbers.

# ¿ Aug 5, 2008 06:07

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

Sounds like it's a legitimate warning. Any particular reason you narrowed those indices?

# ¿ Aug 18, 2008 01:02

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

I'd be willing to bet that due to member padding within data types that the savings you see by narrowing those types won't actually be realized

# ¿ Aug 18, 2008 02:05

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

Have you come across the MSDN page for EnumWindows?

http://msdn.microsoft.com/en-us/library/ms633497(VS.85).aspx

# ¿ Sep 11, 2008 23:04

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

floWenoL posted:

This is the worst way to solve compile errors in C/C++.

Your solution isn't that great either. Why not pass in L"MyString" or _T("MyString")? (I forgot the right one to use.)

The documentation for GetClassName() says it takes an LPTSTR, which you construct with _T("MyString")

(don't forget to include tchar.h!)

# ¿ Sep 13, 2008 04:56

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

rjmccall posted:

(2) dynamically sized and compiled with a pre-C99 compiler.

You could always use alloca() to get around that, too.

# ¿ Sep 16, 2008 01:35

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

That Turkey Story posted:

alloca is nonstandard.

So is the Win32 function GetWindowText() which the original question poster was using.

Though alloca may be nonstandard it is fairly well supported by most compilers and standard libraries.

# ¿ Sep 16, 2008 01:53

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

Avenging Dentist posted:

I recall there being an idiom in C++ for "template polymorphism", but I'm probably calling it by the wrong name, since Google isn't much help. I think TTS posted it in #cobol, if that helps any.

Does anyone know what I mean?

The curiously recurring template pattern?

# ¿ Sep 30, 2008 22:48

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

That's correct because the concept of vector immediates generally doesn't exist. You'll need to splat that value across a vector variable before you can use it

# ¿ Oct 1, 2008 16:53

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

I didn't realize you were talking about compiler autovectorization. I dunno, I find compiler autovectorization to be questionable at best and completely useless at worst.

You'd want to break them into what fits into a single SIMD register, in this case two doubles fit into a single XMM (128-bit wide) register. Vectorization works best also when you don't read and write to the same area in memory because then you can leverage compiler niceties like restricted pointers. Help the compiler by doing as little per statement as you need to when vectorizing.

For an averaging function below, I would step through the array two at a time, like this:

code:

// Assumes out, a, and b all point to different arrays
void average(__m128d* restrict out, const __m128d * restrict a, const __m128d* restrict b, int n)
{
    const __m128d half = _mm_set1_pd(0.5);

    for (int i = 0; i < n; ++i)
    {
        const __m128d a0 = a[i];
        const __m128d b0 = b[i];
        const __m128d sum = _mm_add_pd(a0, b0);
        const __m128d avg = _mm_mul_pd(half, sum);
        out[i] = avg;
    }
}

# ¿ Oct 7, 2008 22:05

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

You don't get the JIT debugger with Visual C++ Express, IIRC

# ¿ Oct 14, 2008 19:46

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

Perhaps it's a memory ownership issue? I'm wondering if it's trying to delete the strings that exist in the DLL heap with an allocator that manages the main process heap.

# ¿ Nov 2, 2008 20:21

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

xluna posted:

This is going to be a slightly neophyte question, but you guys have helped in the past.

I'm a relatively new C++ programmer. I can write in it just fine, but I'm still learning some of the idiosyncrasies. I've reached a topic that has left me scratching my head. I need to know more about casting.

For example, static_cast, dynamic_cast, const_cast, etc. I know what these do. I understand that you can alter the variable type or cast up / down a class hierarchy if need be. With that, I understand what is happening when I read code where casting occurs.

I'm having a problem understanding when I should cast. What sort of giveaways tell let you know that you will need to cast? Any common situations or examples?

Most casts are used for narrowing or widening types. For example, casting a float to a double, or an int to a short. They're also used for changing the signedness of integer types, like (signed) int to unsigned int. Most of the situations where casts end up in code are when the compiler warns or errors that an operation can't occur because the types are incompatible.

Generally my rule of thumb for casting is if I need a cast chances are I'm doing something wrong because I should have been using the right data type in the first place. If I need a reinterpret_cast there's a high chance I'm doing something wrong. If I need a const_cast then it's virtually assured that I'm doing something wrong.

# ¿ Nov 16, 2008 21:23

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

Avenging Dentist posted:

I can't think of a single non-mathematical language that does that.

Haskell!

edit: beaten

# ¿ Nov 21, 2008 02:44

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

hexadecimal posted:

actual C++ question: Do C++ compilers optimize tail recursive functions into iterative ones?

Some do, under certain circumstances, but I don't think anything is guaranteed. I've seen Visual C++ optimize tail recursion into a loop (/O1 and above). It sounds like GCC does it, from rjmccall's post, and I'd assume that Codewarrior does not mostly because it doesn't seem to optimize anything at all.

# ¿ Nov 24, 2008 18:01

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

I do believe so -- the object has to be copied somewhere safe (ie: not the stack) where it lives while the stack is unwound.

# ¿ Nov 26, 2008 16:21

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

csammis posted:

I've got an MFC-based .lib, and for the life of me I was sure there was some tool that came with Visual Studio that could show me what symbols it is exporting. Am I smoking more crack than usual and making this tool up? If I am hallucinating, what's a tool that can show me its exports?

dumpbin /exports

# ¿ Nov 28, 2008 18:02

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

ante posted:

After 7-odd years of C and other languages where OOP is easily avoided, I've finally started learning it. Why is this throwing an exception as soon as I try to assign a value to iWidth?

It's a System.NullReferenceException, and everything I'm reading is telling me that that should be fine. It's not like it's a tricky section of code.

What does the code look like that's calling Initialize? If you're calling through a pointer/reference/handle, has storage for the object been allocated through new/gcnew?

# ¿ Dec 1, 2008 08:20

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

Rottbott posted:

I've found that the reported time can jump backwards on some dual core systems when the thread changes core. The only workaround we found that worked was setting the thread affinity to a particular core before the QPC call.

QPC was reportedly fixed for Vista but at a huge execution cost. It already took thousands of cycles to execute on XP and it's much more expensive now

# ¿ Dec 12, 2008 18:09

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

csammis posted:

The answer is probably "no," but I thought I'd ask anyway: Is there a way to tell Visual Studio's linker, when it encounters a multiply defined symbol, which one is the "right" one?

The scenario is sort of asinine. Our company's application is MFC-based, v2.5 I believe, and we're having trouble throwing exceptions through it. Most of the time this is handled by a redefined AfxWinMain that handles our application's exception class - which is not derived from CException. We're getting some odd activation context exceptions in certain scenarios when an exception is thrown from a window's OnCreate handler. The architect working with me on this thinks the band-aid solution is to redeclare AfxCallWndProc to be able to handle our exceptions as well as CExceptions, but that is proving difficult because AfxCallWndProc isn't declared as extern by MFC. AfxWinMain is one of only a handful of externs in MFC, as far as I can tell, and none of the others have dick to do with the problem.

So yeah, any way to force the linker to accept a specific location of a symbol as The Symbol?

Have you tried decorating the symbol with __declspec(selectany)?

# ¿ Dec 17, 2008 19:57

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

csammis posted:

In text mode output streams on Win32, \n is automatically expanded to \r\n

This should probably go into the coding horrors thread because the automatic new line conversion makes it impossible to pipe binary data between processes.

Le sigh.

# ¿ Jan 8, 2009 18:04

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

hexadecimal posted:

Why did they choose to do it this way? Is sign bit shifting to high order positions on right shift happen in hardware? Does hardware even care if an integer is signed or not? I am kinda confused

You have just enountered the difference between logical and arithmetic hardware operations.

# ¿ Jan 14, 2009 08:24

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

Gvaz posted:

I cant vm on this machine or whatever. :[ And I can't get Msys to work (it just opens up a billion windows then crashes)

Vista 64? Try this: http://www.nabble.com/Installing-MSYS-on-Windows-Vista-x64-td16904988.html

# ¿ Jan 20, 2009 03:59

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

What about named pipes?

edit: here's the list of the IPC methods that Windows supports: http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx

# ¿ Feb 3, 2009 00:37

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

Contero posted:

Well at least I got gprof working.

You could roll your own with penter/pexit hooks (cl.exe's /Gh and /GH switches) but it can be a bit of a bear to do so.

# ¿ Feb 17, 2009 04:03

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 05:34

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

CImg or CImage? If it's the latter, can't you use CImage::Attach()?

# ¿ Feb 20, 2009 02:42

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

«‹›2 »

fret logic posted:

fret logic posted:

FigBug posted:

vanjalolz posted:

Smackbilly posted:

Smackbilly posted:

Mustach posted:

Smackbilly posted:

floWenoL posted:

code:

code:

code:

Clanpot Shake posted:

Avenging Dentist posted:

Zombywuf posted:

ValhallaSmith posted:

crazypenguin posted:

floWenoL posted:

rjmccall posted:

That Turkey Story posted:

Avenging Dentist posted:

code:

xluna posted:

Avenging Dentist posted:

hexadecimal posted:

csammis posted:

ante posted:

Rottbott posted:

csammis posted:

csammis posted:

hexadecimal posted:

Gvaz posted:

more falafel please posted:

Contero posted: