Am I just a very bad coder or is this an abuse of C++ ?

Yamikuronue

Agilefall, I like to call it. Agile + waterfall = gracefully tumbling down a flight of stairs.

tar

Agilefall? Hmmm, I think I've seen that in action myself from time to time...

tar

@Yamikuronue said:

Agilefall

@tar said:

Agilefall

Jinx!

CatcherInTheTry

Or quickly tumbling down a hill for that matter.

dkf

My advice: keep a few low-hanging fruit lollipops in your back pocket that you can pop in while you are actually doing the necessary maintenance grind. You don't need to tell people that they're trivial things; they're just little ideas that you can deploy rapidly to keep people off your back.

And I've seen even good bosses back developers into a corner with a constant demand for new features that prevents doing proper maintenance. Doing the maintenance makes it much easier to put in the new features, or to know for sure that they're something that must not be done. All software should have both clear goals and clear non-goals, and management should definitely be told what the non-goals are.

PleegWat

We're agile in theory. But the VP who introduced it is gone. And at the SVP level they're like? Agile? That's fun. Now, which features are you going to finish in the March 2016 release? Because we'll be wanting them code-complete in February and QA-complete in May.

dkf

@PleegWat said:

Now, which features are you going to finish in the March 2016 release? Because we'll be wanting them code-complete in February and QA-complete in May.

QA-complete in May for a release the following March? Or is the software being burned into hardware that is being shipped to space or something?

Bulb

@CatcherInTheTry said:

Oh, you must mean Never because, as in all corporate environments, that's all the time we'll get for refactoring anything.

@CatcherInTheTry said:

So true, and we've recently decided to implement "agile" as in that kind of agile…

Of course you never get time to refactor and produce no new features. But that's not how it's supposed to work anyway.

The right way is to properly fix the code when you need to fix it. So from the management point of view, the work is simply part of implementation of the next feature.

This is what extreme programming tells you to do and it's what you could take from it even if the management bits of agile don't work. You however need whole team in for it; if some developers are willing to hack it up in shorter time, you'll have hard time defending the larger estimates at the points you want to do things properly.

It's also your responsibility to find balance between development time and quality. You need the code to be good enough to be easy to debug, not perfect. Then the overall project time should not suffer (because you'll reduce the number of obscure, hard-to-fix bugs) and your estimates will actually be more accurate (because you'll spend less time with unestimable bug fixing) which the management will appreciate. But then, the responsibility for writing shitty code is your either way, because management does not tell you to write shitty code.

@dkf said:

And I've seen even good bosses back developers into a corner with a constant demand for new features that prevents doing proper maintenance.

Bosses need new features. You need features too. They are what makes money for the company and ultimately pays your bills. That's why you should do maintenance bit by bit as part of tasks that benefit from it.

Bulb

@tar said:

Now I'm wondering whether there are any situations where something like size_t c = vector.size(); is actually going to bite me on the as...

For std::vector never. Because std::vector is required to hold the data in consecutive block of memory and size_t is required to be large enough to hold size of the largest memory block possibly obtainable.

It is however possible with other types of containers. On i486 huge model pointers are 48-bit (16-bit segment id + 32-bit offset). The largest possible allocation is only 2³² , so size_t can legally be 32-bit, but the program can span multiple segments and can therefore allocate more memory for something like std::list or std::deque. The former has rather high overhead, so it's unlikely to exceed 2³² items, but the later is typically a list of pages and could exceed 2³² items. I haven't seen actual compiler for huge mode though so I don't know whether it actually used larger type for std::deque::size_type.

You can also have larger size when using stxxl, but that does have the size_type as template parameter, so you know what you configure for you.

tar

@Bulb said:

You can also have larger size when using stxxl, but that does have the size_type as template parameter, so you know what you configure for you.

That looks pretty interesting—bookmarked for if I do ever find myself running calculations on supercrazylarge datasets!

Bulb

It can be also useful if the datasets are not that large, but need to be stored on disk for whatever reason and database is not a good fit.

tar

That's a good point, I was idly wondering about that. Well then, it's directly relevant to my interests! :D

PleegWat

I think that means QA must have done first test pass over all features. Not sure. In non-agile departments, there may be a 'convert-features-to-bugs' pattern going on.

dkf

@PleegWat said:

there may be a 'convert-features-to-bugs' pattern going on

That sounds like some software developers I know…

PleegWat

I think that pattern has been on the front page at some point in the past.

powerlord

@RaceProUK said:

In the case of Java, you're forced into handling them; at least C# makes it optional

Not all exceptions in Java are checked exceptions and only checked exceptions have to be caught.

It'd be just silly if you had to have a try/catch block for NullPointerException... well... ever.

dkf

@powerlord said:

Not all exceptions in Java are checked exceptions and only checked exceptions have to be caught.

I wasn't going to tell them. They've convinced themselves that they're superior and so aren't going to listen…

riking

Here's a try-catch that will catch NPEs.

try {
  ClassLoader pluginClassLoader = new PluginClassLoader(pluginJar);
  String mainClass = pluginDescription.getMainClass();
  Class<? extends JavaPlugin> pluginClass = pluginClassLoader.loadClass(mainClass);
  Constructor<? extends JavaPlugin> constructor = pluginClass.getConstructor(new Class[]{});
  JavaPlugin pluginInstance = constructor.newInstance();
  pluginInstance.onLoad();
  
  pluginMap.put(pluginDescription.getName(), pluginInstance);
} catch (Throwable t) {
  log.throwing(t, "Plugin %s failed to load", pluginDescription.getName());
}

EvanED

@NeighborhoodButcher said:

Jesus, I actually quoted myself so you could read it without searching. Let me do it again:

You also said

@NeighborhoodButcher said:

It wasn't deprecated because it didn't do its job. We got a new tool and the old one couldn't be upgraded because of backwards compatibility.

@NeighborhoodButcher said:

No they're not. Raw pointers give you nothing - no info about ownership or lifespan.

Here's my view. First, let's look at pointers that are a member of a class. In the case of auto_ptr, if you don't take special care in the copy constructor and assignment operators, your class is almost certainly buggy. In the case of raw pointers, if you don't take special care in the copy constructor and assignment operators, your class is almost certainly buggy buggy. In the case of raw pointers, you also have to deal with them in the destructor; I'll come back to that in a bit. That's by far the most common case of owning pointers, at least IME. In the case of locals and globals, usually you don't need to use pointers at all and can just talk about the object directly; the one exception is if you are constructing parts of an object and pass the pointers into some container later.

I will admit that there are a couple extra errors that you can make in the case of the raw pointer, but I'd also argue that it's not as clear cut as that. In particular, deleting owned pointers in a destructor is the easy part of resource management; the hard part is figuring what to do when you copy the owning object, and you have to deal with that in both cases. Getting the destructor wrong is also almost always about the least damaging memory bug you can have. Then you also have to deal with non-owning pointers, at which point you're out of auto_ptr land and its semantics don't help you. Meanwhile, if you use auto_ptr you are much more likely to run into potential implementation deficiencies (such as a VS2008 stdlib bug that, IIRC, lets you construct auto_ptr<Foo> ap(new Bar()); where Foo and Bar are unrelated classes), you get surprising & nonobvious semantics, and you get what I say is a false sense of security.

@NeighborhoodButcher said:

I didn't actually understand that.

I think you did, actually; your reply seems to indicate you got the gist of what I meant. Part of why you say

@NeighborhoodButcher said:

You always should look at base classes first, if there are any

is because if you don't have an indication of what functions are inherited, that's what you have to do. If you have that indication, you have more options available. You could deliberately look at the subclass because you think that's where the functions of interest are located. Or maybe you often have to use the subclass, but because you see the indication of what is inherited your brain files that away and later, when you're working on something else, you remember that the function you need are likely available in the base.

@CatcherInTheTry said:

Virtual keyword is commented because that's how it is in the original source.

Sure, but that just begs the question as to why it's like that in the original.

(Maybe more replies as I catch up, finally?)

EvanED

@dkf said:

Most C++ authors seem to be extremely keen on avoiding exceptions, probably due to the legacy of truly awful implementations

It's not just "legacy"; we switch off exceptions for most of our code base because even nowadays, with relatively recent compilers (i.e. well after they actually got good at supporting C++98) the compilation speed gained by disabling them is significant. They weren't being used much in our code base to begin with, and we are doing ugly things with templates and stuff that are already incredibly stressful to the compiler so the benefit is significant for us.

(Note: I don't condone this really, just... reporting.)

powerlord

I said it'd be silly, not that it was impossible.

Am I just a very bad coder or is this an abuse of C++ ?

The Go Programming Language Specification - The Go Programming Language