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

«‹›5 »

floWenoL: Oct 23, 2002

feedmegin posted:

Correct. What matters is the raw function name. (which is why C compilers, unlike C++, don't have to do name mangling)

In other words, C doesn't support function overloading.

# ¿ Feb 22, 2012 23:54

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 02:45

floWenoL: Oct 23, 2002

pseudorandom name posted:

edit: The best part is that for the decade between the introduction of tgmath.h in C99 and the introduction of _Generic in C11, there was literally no standards-compliant way to implement tgmath.h.

Isn't this more indicative of a need for type parametrization rather than function overloading?

# ¿ Feb 23, 2012 02:30

floWenoL: Oct 23, 2002

Hughlander posted:

code:

    {
       ResourceHolder* pResource = GetResource(); // Call to GetResource blocks until  m_TheCritSection can be locked
        if(pResource) // pResource has a weak ref to the resource so can still be NULL
        {
            pResource->UseResource();
        }
    } // pResource out of scope, ref count of the smart pointer to m_TheCritSection decremented and lock released if it reached 0

This code doesn't make sense. pResource (a pointer) goes out of scope, but how can you possibly hook into that to (say) decrement a ref-count?

You probably want something like:

code:

  {
    ResourceHandle h(some_shared_resource);
    if (h.get()) {
      h.get()->UseResource();
    }
  }

But that's just your original code. So what are you trying to do?

I assume you have a good reason for doing concurrency with shared data instead of, say, a message loop to control access to the resource.

# ¿ Feb 25, 2012 00:18

floWenoL: Oct 23, 2002

Hughlander posted:

Not sure which is worse, secretly acquiring some lock, or spending tons of hours tracking down cases where coders don't feel like they need to acquire the lock and testing for the existence of the object is sufficient. (Which is what happened and led to a crash in the live environment that never came up in 3 years of development.)

It sounds like the problem is needing a lock in the first place.

P.S.:
Your avatar is making me confuse you with CptMath.

# ¿ Feb 25, 2012 01:52

floWenoL: Oct 23, 2002

Flobbster posted:

If and when I decide I need it, I'll just snag the appropriate part of the C++ grammar and build a parser from that, which should cover just about all the behavior someone in my position might need (as long as they stay away from horrible examples like Vanadium's).

You seem to be unaware of how complicated the C++ grammar really is.

You could always shell out; that may be the most practical option.

# ¿ Feb 27, 2012 23:06

floWenoL: Oct 23, 2002

GrumpyDoctor posted:

Uh, yeah, that's why I asked the question. It seems like there should be a relatively easy way to get one of those from a list iterator but I can't figure one out.

Well, what exactly are you asking? Your angle brackets are unbalanced.

# ¿ Mar 16, 2012 19:29

floWenoL: Oct 23, 2002

Princess Kakorin posted:

I'm tired as shrek, so I probably did something wrong putting it up on here.

Yeap, you didn't post your entire code like everyone is asking you to.

# ¿ Mar 24, 2012 20:21

floWenoL: Oct 23, 2002

Suspicious Dish posted:

root **input_roots;

Pointers are arrays.

No, they're not.

# ¿ Jun 2, 2012 06:36

floWenoL: Oct 23, 2002

Yonic Symbolism posted:

http://pastebin.com/CRA81kH5

I've ripped out almost everything. Definitely all of the actual computing.
It still acts like there's a memory leak. I don't think I know what I'm supposed to be looking for.

I see a lot of 'new' calls and no 'delete' calls.

Edit:
I missed that he was actually talking about uninitialized memory. But the code does still have a lot of leaks.
vvv

floWenoL fucked around with this message at 19:19 on Jul 20, 2012

# ¿ Jul 20, 2012 19:15

floWenoL: Oct 23, 2002

Yonic Symbolism posted:

But why would I delete anything before I actually use it? The init just initializes the array, there's two or three other subroutines that need to be performed using the arrays defined using init, in both the class and in main.

Okay, so I guess you didn't post the code that does the deletion. Which would make investigating an actual memory leak difficult, but it sounds like your problem is different.

# ¿ Jul 20, 2012 19:26

floWenoL: Oct 23, 2002

OneEightHundred posted:

Aliasing rules are bothering me. Long story short, I need a version of memcpy that is guaranteed to copy aligned pointers atomically (on any platform I care about, that means loading and storing as a pointer-sized value), but the data can contain anything. I'm pretty sure the stock memcpy will do this in most scenarios, but I can't be 100% sure it won't optimize to rep stos or something like that.

At the same time, I'm trying to stay strict aliasing clean and it looks like that can only be accomplished if I was copying char-sized data, or was using a union, but a union will only guarantee aliasing of types contained in the union.

Is there a way to do this? Would declaring the destination volatile enforce that potentially-aliased values are reloaded after?

What's wrong with casting your pointers to char pointers, which can alias anything?

# ¿ Sep 7, 2012 21:22

floWenoL: Oct 23, 2002

OneEightHundred posted:

The problem is that if they're copied as chars, then the pointer-sized value copies may not be atomic, which is necessary in this case. I'm pretty sure recasting the pointers won't fix that since aliasing affects value load/stores, not pointer conversion.

Wait, so you're relying on the value type for atomic copying? i.e., are you saying you think that if you treat the array as a word array instead of a char array, it'll be atomic? That seems dangerous. I don't think there's any guarantee as to atomicity of value copies based on type. You may have to use atomic instructions. If so, then you can just use char *.

# ¿ Sep 8, 2012 02:22

floWenoL: Oct 23, 2002

Volte posted:

code:

float exp2(int x) {
    int a = (x + 127) << 23;
    return *(float *)&a;
}

This is undefined behavior.

(Use a union.)

# ¿ Oct 31, 2012 06:49

floWenoL: Oct 23, 2002

Hammerite posted:

code:

inline int SensibleIntegerDivision (int a, int b) {
    return a / b - ((a % b) < 0 ? 1 : 0);
}

Pretty sure this is unportable in C++ and C before C99 (since the sign of % is implementation-defined for negative numbers).

# ¿ Feb 16, 2013 00:16

floWenoL: Oct 23, 2002

Hammerite posted:

I was under the impression that given integers a and b (b not zero), if you write
code:
q = a / b
r = a % b
then you're guaranteed that

q*b + r will be equal to a
The absolute value of r will be less than that of b
If a and b are both positive then r will be nonnegative.

I want to do integer division like this (calculating q) except that I want it to always be guaranteed that r will be nonnegative, regardless of the signs of a and b.

As far as I can tell, the code I posted does this, but maybe there is something more you know that I do not (it has been my impression that C/++ has many "gotchas" that can trip programmers up).

Ah, I see what you're trying to do. However, the function as posted is buggy: SensibleIntegerDivision(-5, -3) gives 0, where it should give +2 (if I understand you correctly).

Edit:
-2 should be +2. Thanks, Jabor!

floWenoL fucked around with this message at 02:43 on Feb 16, 2013

# ¿ Feb 16, 2013 02:36

floWenoL: Oct 23, 2002

astr0man posted:

If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator.

That is true, although you're leaving out the part where (a/b)*b + a%b is supposed to equal a. In that case, it's possible to write code that does what Hammerite wants regardless of the implementation.

# ¿ Feb 16, 2013 02:37

floWenoL: Oct 23, 2002

Ciaphas posted:

I've been tasked with seeing how well our code, currently compiled and running only on a Solaris 10 sparc using SunCC 12.1, would compile on a generic linux intel box with g++.

This is probably a normal enough task for most of you professionals but so far I wish to curl up into a ball and die. The most common problem so far by far is screwed up #includes in the codebase, for example someone using strcmp or whatever without including <string.h>. I presume it's compiling on SunCC and not on g++ because some header we're including (<string>? <sstream>? I have no clue) includes <string.h> on SunCC but not on g++.

Which leads to my question: is it generally possible to make the compiler emit a warning or error if it has to go through more than one level of #includes to find the declaration for any given symbol?

I suspect the answer is no, or maybe a slight possibility of 'platform specific'. I don't know, I'm not thinking too well today.

_{^{someone please kill me}}

https://code.google.com/p/include-what-you-use/ might be the closest thing to what you want, if you can get your code compiling on Clang.

# ¿ Mar 2, 2013 09:56

floWenoL: Oct 23, 2002

Otto Skorzeny posted:

Dang that's a lot of Googlers that don't understand what an include guard does and does not do! I enjoyed the cameo from yung ~LoNeWoLf~ as well.

I don't think there was a lot of misunderstanding going on, just a lot of miscommunication back and forth.

# ¿ May 10, 2013 21:35

floWenoL: Oct 23, 2002

MrMoo posted:

Importantly: 10 seconds slower with #pragma once.

We might be looking at two different runs, but the original data that drove the inclusion of #pragma once was a ~1 minute speedup with it on Visual Studio.

# ¿ May 11, 2013 02:44

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 02:45

floWenoL: Oct 23, 2002

MrMoo posted:

It's cargo cult copying when you see poo poo like this:
code:
#ifndef blaa_h_
#define blaa_h_

#ifdef _MSC_VER
#pragma once
#endif
...

That's not actually how #pragma once was used in Chromium. ??

# ¿ May 12, 2013 07:01

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

«‹›5 »