Would struct be a good way to store program settings in memory?

Question

I'm writing an application and need to store program settings (Input Directory, Output Directory, etc) while the application is running. I'd like to have the program be able to load and use (based on an option) a production environment and a test environment.

I would set the structs up like so:

Class AppSettings
{
    struct prodAppSettings
    {
        var settingName;
        var settingName2;
        var settingName3;
    }

    struct testAppSettings
    {
        var settingName;
        var settingName2;
        var settingName3;
    }
}

I would then, in my main class, load the appropriate settings based off of what environment option the user wanted.

The class AppSettings would handle the loading of the settings (the application will interface with a web service for settings OR it can use, in times where a network connection is unavailable, a XML file that stored the last known good settings). I'm not overly familiar with structs and I'd like to get familiar with them, so this project might be a good place to do that.

EDIT

Clarified a couple of things.

Is there a reason not to use the App.config file? Or are you looking to build an object to wrap/abstract that? — David, Dec 31 '13 at 15:58
[When to use struct in C#?](http://stackoverflow.com/questions/521298/when-to-use-struct-in-c) — huMpty duMpty, Dec 31 '13 at 15:58
@user1693074: Why are you looking to use a `struct` rather than a `class`? — Jon Skeet, Dec 31 '13 at 16:00
@JonSkeet Truth be told -- I'm not all that familiar with structs, so it seemed like a good exercise. — mlw4428, Dec 31 '13 at 16:01
@user1693074 put it this way: I use `unsafe` a **lot** more than I use `struct`, and I hardly ever use `unsafe` — Marc Gravell, Dec 31 '13 at 16:02

score 10 · Answer 1 · answered Dec 31 '13 at 15:59

10

No, basically. Use a class. The number of times you need to use struct is vanishingly small (unless you're writing for XNA etc) - and this isn't one of them. If you use a struct here you're likely to run into at least two problems:

passing around a really big struct on the stack (rather than just a reference)
lost updates to inner-copies of the struct

and quite possibly a third (torn values, via multi-threaded code)

answered Dec 31 '13 at 15:59

Marc Gravell

1,026,079
266
2,566
2,900

6

@gleng game devs are **very** reluctant to do anything that could trigger GC, so it is not uncommon to see `struct` representations of things that would *intuitively* be classes; to help with the stack-passing overhead and lost-updates issue, they are often passed as `ref`. So: two things that a lot of devs struggle to get their head around (`struct` and `ref`) - sounds like a recipe for fun ;p – Marc Gravell Dec 31 '13 at 16:04

score 6 · Accepted Answer · answered Dec 31 '13 at 16:04

You already have a class:

class AppSettings

Why not just use that? You can internally structure things further using nested classes:

class AppSettings
{
    public SettingsGroup SomeGroupOfSettings { get; set; }
    // other settings

    public class SettingsGroup
    {
        // properties which are logically grouped together
    }
}

It even seems reasonable to me that there would be (or at least could be) more logic applied here, making a class more and more appropriate.

Structs tend to be good for small groupings of immutable data. A common struct would be two coordinates to form a point, for example. If either coordinate changes, it's an entirely new point and one might as well make a new instance of the struct for it. Larger and potentially more complex things like this really belong in a class which represents more of an "object" than a "grouping of immutable data points."

score 0 · Answer 3 · answered Dec 31 '13 at 17:23

0

In such cases the classic way of managing your settings is through the built in Settings class

answered Dec 31 '13 at 17:23

RE6

2,684
4
31
57

Would struct be a good way to store program settings in memory?

3 Answers3