Posts by mike_2000_17

Let's start with a couple of definitions:
"Array": A sequence of elements packed next to each other in memory.
"Pointer": An address to a location in memory.

So, when you have this:

int arr[10];

you have a variable called arr whose type is an "array of 10 integers".

When you have this:

int* ptr;

you have a variable called ptr whose type is a "pointer to an integer", which means that it contains an address to a location in memory at which it is expected that there will be an integer value.

When you have this:

int (*aptr)[10];

you have a variable called aptr whose type is a "pointer to an array of 10 integers", which means that it contains an address to a location in memory at which it is expected that there will be 10 integers value next to each other in memory (i.e., an array of integers).

When you do this:

ptr = arr; // pointer to array

the type of ptr is still a "pointer to an integer", however, after this assignment it just so happens that ptr will be pointing to the start of the array arr (which is implicitly converted to a pointer there). And so, we say that ptr points to an array, but it's type is still int* (or "pointer to an integer"). The thing is this, the int* type only requires (by way of the type rules) that there is an …

One of my longtime favorite starts to a song is AC/DC's kick-start to "You shook me all night long":

She was a fast machine she kept her motor clean
She was the best damn woman that I ever seen
She had the sightless eyes telling me no lies
Knocking me out with those American thighs

Another nice one is the biblically-inspired first line of Coolio's "Gangsta's Paradise", it just flows so well and starts off the song so perfectly too:

As I walk through the valley of the shadow of death
I take a look at my life and realize there's nothin' left

Well, from looking just in this thread, it appears that both diafol and ddanbe have not been featured... they should be.

How do you know that this is not a delay created by your email server? In the old days, it was common for some emails server to be slow or have a naturally delay (and 1 hour wasn't uncommon). AFAIK, this is no longer a common issue.

I second the others, I would nominate rubberman for sure.

And also, the "eternally awesome" deceptikon (or is it "eternally confuzzled".. I'm confuzed.. wink wink).

And, here are a few common encounters in the C++ forum for a long time: Labdabeta, Moschops, L7Sqr, .. that's all I can think of for now.

Yeah, the copyright should normally state the period that it covers: from the date that the material was written to the date that the material was last modified. That has always been my understanding. I don't know if this is a requirement or not, but it is certainly the conventional thing to see.

Are you kidding? You really thought Dani copyrighted the site just last year?

Technically, the copyright refers to the site itself, i.e., the web-pages accessible to the public. It doesn't necessarily include the Daniweb brand or company, or any of it's back-end. The notice is there to tell people who can access it that they cannot copy it. Things that are not accessible are not accessible, period.

Then again, I'm not sure if Dani should put the start date of Daniweb as the start of the copyright or the start of the latest overhaul of the site. Most likely, she should start the date at the creation of Daniweb, because the overhaul was not integral (graphics, theme, the color purple, etc.., all stayed mostly the same).

And even if the copyright notice was not up-to-date, it wouldn't really change much. Technically, people might "steal" anything that was modified after the end of the copyright notice, but only the modifications, which kind of like stealing a patch from a software, but not the software itself, pretty much useless.

Like I say, in the UK you register yourself with an agency which maintains your copyright.

@deceptikon: You misunderstood what the OP was referring to. She is referring to a local class, not a nested class. In other words, this is the case in question:

void f() {
  class inside
  {
    public:
      static int x; // Forbidden!
  };
};

And the explanation for why this is not allowed is that static data members require linkage (be visible to the linker), while a local class is, by definition, not visible outside the function, i.e., it has no linkage. It is simply impossible to have a "visible" entity as a member of an "invisible" entity. Also, there would be a bit of an ambiguity with regards to the static data member if it was allowed (assuming the linkage rules were different), because of the life-time of that static data member. Would it be like a local variable, or like a global variable, or like a local static variable? Where would you define the data member? I assume inside the function. But would that mean that that is the point of initialization? What if you define the data member within a if-statement or some other conditional block?

I think that I am glad that this is not permitted because it would be quite difficult to come to a decent solution to all this ambiguity.

alexanpasha already mentioned the very huge systems like mainframes and supercomputers where Linux is extremely important, and at the very least, Unix variants (incl. Linux) dominate the scene completely. Especially in the last decade, the industry has been migrating to Linux systems more aggressively as they realized that it is easier and cheaper to adapt a Linux derivative to work on their systems than it would be to keep maintaining / improving the old legacy proprietary systems (usually Unix variants) that they have been using since the 60s.

But I would also mention another large area of application, which are the tiniest things, i.e., embedded systems. These are the small programmable chips that control various things like various systems in cars, home appliances, TVs / DVD players / DVRs / etc., industrial automation systems, robots, etc... Sure, once in a while you see such a device running Windows CE, or, conversely, not having an operating system at all, but the most common solution is to use a stripped-down distribution of Linux as it fits just perfectly for most purposes, with the exception of cases where hard-real-time operation is needed, which is usually done with QNX (also a Unix variant).

I think that this is really the thing that speaks volumes about Linux (and its Unix-like cousins), that it's so versatile that it can be used in such a wide array of applications with what are essentially the same ground-works (either pimped up to run a super-computer, or stripped down to …

Hi, and welcome to Daniweb!

C++ is indeed a wonderful language, and I look forward to your contributions / questions on it.

The one who does not know how to access it will be confused but that really does not mean that we are restricting user to access it accidently.

That's not exactly true. Private or protected data will restrict the user from accessing the data accidently. It is true that in many cases there are hack-ish ways to access private / protected data, but most of these techniques are, by nature, very deliberate. The likelihood that a careless programmer just happens to access / modify the data by accident is generally very low, and that's the point of those access rights, it's to put access to the data (or functions) outside the realm of "normal" uses of the class or objects. That's what "hiding" means, not to be confused with "protecting".

So, is it not like that programmer has prepared logic in detail thinking that unknown user can’t access it?

When we are talking about normal programming, i.e., not in the context where you are trying to implement security measures, the relationship between the library programmer (e.g., writes the class) and the library user (e.g., uses the class) is one of cooperation, not of antigonism. In other words, the library programmer wants to help the user be able to do his work as easily and safely as possible (safely, as in, without unintentional bugs). And in that context, hiding away certain details can help make it easier for the user to know what he can use safely, …

Happy Birthday AD!

MACROs must be upper-case because this is the convention throughout the programming world of C and C++ and related languages. Basically, MACROs have a number of quirky things about them, and are riddled with pitfalls, and therefore, all programmers want to know, just by looking at something, that it is a MACRO, and thus, need to pay special attention when using it. MACROs allow you to do all sorts of crazy stuff (and that's why they are sometimes the only option), but that also means that they make it easy to cause really weird and hard-to-find errors. So, whenever you use a MACRO for something, you have to put up a huge red flag to announce to the world that this is a MACRO, and the convention for doing that is to use the ALL_UPPER_CASE convention.

and not like other names?

MACROs are nothing like other things (functions, variables, classes, etc.) because they are not handled by the compiler but by the pre-processor. MACROs (or simpler #define tokens) are basically markers for the pre-processor that passes over the code and does a kind of "find-and-replace" for all instances where it finds the MACRO name. The problem is that the pre-processor does not consider context, it does not do scope-based name lookups, it ignores namespaces and scopes, i.e., it is a completely brainless find-and-replace tool. This means that the compiler does not care if the MACRO is used in the right place or if the macro name might refer …

see how i declare the Age property and the macro defined.

Well, there is an error in your MACRO definition, you have an extra semi-colon. It should be:

#define Property(TypeName,PropertyName,getfunction, setfunction) \
  property<TypeName> PropertyName{std::bind(&getfunction, this),std::bind(&setfunction, this, std::placeholders::_1)};

why isn't showed? it's because is a macro?

Yes. Code completion tools do not, in general, expand macros (they can't risk opening that can of worms). So, they won't show stuff that is buried in a macro.

but what you think about it? and the macro?

I think the macro is completely pointless. And you certainly should never use a name like Property for a MACRO. It should something along the lines of CAMBALINHO_LIBRARY_CREATE_PROPERTY instead. Macro names must obey two conventions: (1) all written in UPPER_CASE_LETTERS, and (2) be prefixed with a unique name that identifies your library. I cannot condone any macro use that does not obey these rules. And the name Property is pretty much the worst possible name for a macro that I could imagine.

The break; statements in the outer switch statements should be moved to after the inner switch statements. The break instruction marks the end of the code within a switch-case. That's why your inner switches don't ever execute. So, Line 42 should be moved to Line 71, and Line 78 should be moved to between Line 98 and 99.

You don't need that. There is no reason to use that method for initializing data members, and I'm not even sure it's possible with this kind of stuff, I think you can only initialize with a constant expression, and this is not possible in this case. In any case, this method of data member initialization is merely syntax sugar, it provides nothing special that is "necessary" for anything.

I'm sure there are ways to check the power supply for issues. But anything I can imagine would involve appropriate equipment (to measure the voltage, to provide an electrical load, etc..).

I dont think the power source is too weak, since the components are not really high-end (GIGABYTE GTX 660 Ultra Durable 2GB, Intel Core i5-3350P,

Your graphics card is rated as drawing 450W, and your CPU is rated as drawing 69W, that 519W right there, and that doesn't even count the HDD, motherboard, and the rest (e.g., main fan). Of course, these are "max" power ratings, but still, a good power supply needs to be able to provide that power in case it's needed. If your power supply is too weak, sometimes you might get sporadic drops in voltage which could cause random components to misbehave at random times (i.e., basically like flickering light-bulbs, but in your computer). That could explain some of the weird behavior.

Sorry about that placeholder _1, it is in the namespace std::placeholders. So, it should be std::placeholders::_1 instead of just _1. The error was due to me being more used to using the Boost version of bind. You can see this docs on bind.

Well, that variable is there all the time, whether you "need" it or not. So, you might as well use it.

It seems that what you are looking for is essentially the same as this audio changer.

And I would imagine that they just use code similar to virtual audio drivers to achieve this. Which seems like a pretty good starting point for making your own.

I don't know what else you could want.

I think that function should just be this:

friend istream& operator>>(istream &input, property &dt)
{
    input >> dt.PropertyValue;
    if (dt.setf!=nullptr)
        dt.setf(dt.PropertyValue);
    return input;
}

It's a typo, you had this:

property(std::function<void(void)> GetFunction=nullptr,std::function<T(void)> SetFunction=nullptr)

It should be this:

property(std::function<T(void)> GetFunction=nullptr,std::function<void(T)> SetFunction=nullptr)

Notice the first parameter should be std::function<T(void)>, not std::function<void(void)>, and similarly for the second one.

And the bind expression for the setter should be:

test() : Name(), 
         Age(std::bind(&test::getage, this),
             std::bind(&test::setage, this, _1))
{

seasonic 500w energy knight source

This seems like a very weak power-supply for a relatively new computer. I had a relatively new computer about 3 years ago with a 550W power-supply, and it ended up breaking because it was under-powered, and so, replaced it with a 850W power-supply and has been running smoothly since. And your description sounds a little bit like a power-supply problem, although the bios corruption stuff is a bit weird. In any case, I don't think that a relatively new computer could possibly run well on a 500W power-supply, that's just too weak. It is very common for computer stores or suppliers to package weak and obsolete power-supplies into their products because customers often don't pay much attention to that component, so they can pass off cheap, obsolete or under-rated power-supplies easily to unsuspecting customers. So, I would definitely try to get that power-supply upgraded.

Beyond that, it is hard to tell exactly what the error is. If there seems to be some bios error, then you might want to try a factory reset of the bios, which is a very simple thing to do.

Beyond that, you basically work your way up the ladder of components. First, check the hard-drive by: (1) booting into a recovery-disk or LiveUSB/LiveCD and do a full scan of the hard-drive; and, (2) try to get another hard-drive (maybe from an older computer) and swap it out to see if it works fine with another hard-drive. …

The default constructor is ambiguous with this constructor:

property(std::function<void(void)> GetFunction=NULL,std::function<T(void)> SetFunction=NULL)

because both can be called without any parameters. You should just remove the default constructor because that constructor with default parameters achieves the same result (setting both functions to null) when called without parameters.

The property<int> Age(&getage,&setage); line gives an error because both getage and setage are member functions, not free functions. You need to create pointers to member functions for that. Like this:

test() : Name(), Age(std::bind(&test::getage, this), std::bind(&test::setage, this))
{
    //nothing
}

property<string> Name;
property<int> Age;

That's that.

i was wondering if you could give sample code here which uses two files(both a.cpp and b.cpp) in a progarm.

The code I posted in my earlier post is one such example. In the tutorial that I linked to, there is another such simple example.

Like AD said, all projects of any substantial size will have a ton of source files. For example:

• Boost libraries: ~9,000 .cpp files; ~11,000 headers.
• My own library: ~400 .cpp files; ~500 headers.
• GSL (GNU Scientific Library): ~1,500 .c files; ~600 headers.
• LAPACK: ~3,300 .c files; ~3,500 .f files (fortran); ~800 headers.

and I could go on and on like this.

The main reasons for splitting things into multiple files like this are that (1) files are easier to manage (smaller), (2) a team of developper can work on separate files, and (3) you only have to compile the source files that you have changed. The last point is especially important when projects become large and their development occurs over a long period with many updates and changes. For example, my own library can take up to an hour or two to compile in its entirety, I certainly don't want to have to do this every time I change something somewhere.

i don't know how a program can use two files(up to now ,i haven't seen such a topic in the book).

To compile a project with multiple source files, you just add all the cpp files to your project, …

From our talks in the chat room, the issue seems to be that you have upgraded to kernel version 3.8.x, from the original 3.2.x. The problem is that you have kept the graphics driver (Catalyst 13.x) that you installed for the 3.2.x kernel. The graphics drivers are very tightly linked to the kernel, and having a mismatch between the two is a very bad thing. It may work, but it causes some problems, like hanging during the shutdown process.

You said you tried to re-install the graphics driver after the kernel upgrade, but that it failed, and so, you kept the old one. It appears that this is a known issue with kernel 3.8.x and later with your graphics driver (the ATI Catalyst drivers). Here are instructions on how to apply a patch to make it work:
http://henryhermawan.blogspot.ca/2013/03/amd-catalyst-patch-for-kernel-38x.html

Yeah, that's right, I never thought of that. Imagine all the aggrevation that Microsoft has caused to people who have googled for information on:

"Good products to clean windows"
"Guide to repairing windows"
"Windows maintenance"
"How to keep bugs away from windows"
...

I smell a class action lawsuit...

Technically-speaking, there is no such thing as a "C++ program", because once you have "compiled" the C++ source code, you have an "executable program" (i.e., a ".exe" under Windows, or no-extension under Unix/Linux/Mac). And running an executable program is the same regardless of language or platform (either go into the command-line interface, go to the directory where the program is and type in the file-name of the program and hit "enter"; or, in the file explorer, you double-click on the executable program file).

I'm guessing that what you are having trouble with is compiling the C++ code to obtain an executable program. If you want us to help, we need more information about what compiler you have installed, and what IDE (development environment) and platform (Win / Linux / Mac) you are using. If you don't have an IDE or compiler, just get CodeBlocks.

Oh, sorry about those errors, I wrote the thing a bit too quickly. The first error you got about "could not deduce template argument for 'FuncPtrType'" is solved exactly as you did.

The second error, about "expects 1 arguments - 2 provided", has to do with a name conflict. The problem is that the GetProcAddress function could refer to either the member function of CDLLLoader or the Win32 API function of the same name. So, just change the name of that function in the CDLLLoader class:

class DLLLoader {
  private:
    HMODULE h_inst;
  public:

    //...

    template <typename FuncPtrType>
    FuncPtrType GetFunctionPtr(const char* procName) const {
      return (FuncPtrType)(GetProcAddress(h_inst, procName));
    };
};

And then call it with:

CreateFoo = spDLL->GetFunctionPtr<fpFunct1>("CreateFooClassInstance");

That should work (sorry, I can't test it, I'm not under Windows at the moment).

Given your example code, here is how it should normally be structured:

In "functions.h":

#ifndef MY_LIB_FUNCTIONS_H
#define MY_LIB_FUNCTIONS_H

int factorial(int n);

bool IsEven(int n);

double sqr(int n);

#endif // MY_LIB_FUNCTIONS_H

In "functions.cpp":

#include "functions.h"

int factorial(int n)
{
    if(n==0)
        return 1;
    else
        return n*factorial(n-1);
}

bool IsEven(int n)
{
    if (n%2==0)
        return true;
    else
        return false;
}

double sqr(int n)
{
    return n*n;
}

And in the "main.cpp":

 #include <iostream>
 #include "functions.h"

 int main() {

     std::cout << "Please enter a number: ";
     int x = 0;
     std::cin >> x;

     std::cout << "You entered: " << x << std::endl;

     std::cout << "Factorial is: " << factorial(x) << std::endl;
     std::cout << "Square power is: " << sqr(x) << std::endl;
     if( IsEven(x) )
         std::cout << "It is an even number." << std::endl;
     else
         std::cout << "It is an odd number." << std::endl;

     return 0;
 };

The way you compile this program is simply that you compile all the cpp files together. You can do this in your CodeBlocks settings or project management somewhere, i.e., you "add sources to project", and it will compile and link together all the cpp files.

compiler generate functions.o . so how to generate functions.obj.

.o and .obj files are the same, it's just a different convention depending on the compilers (and the internal format is different too). Conceptually, they are the same thing. Microsoft's compiler and a few other Windows-only compilers use .obj format, but the vast majority of …

Technically, you could make this work using this:

boost::shared_ptr<HINSTANCE__> spHDL (LoadLibrary("DllMain.dll"), FreeLibrary);

// get the function pointer
CreateFoo = (fpFunct1)(GetProcAddress(spHDL.get(), "CreateFooClassInstance"));

However, this reliance on HINSTANCE__ makes me cringe. The problem is that you are not really supposed to assume that HMODULE is defined as HINSTANCE__*. The Win32 API does not specify what HMODULE is defined as, and you should not rely on what it is. Anything that isn't specified is something you should not rely on. For example, HMODULE could be an integer type, and not a pointer.

I don't think that using a shared_ptr is really appropriate here. I think you should simply create a RAII wrapper around the loaded module, like this:

class DLLLoader {
  private:
    HMODULE h_inst;
  public:

    DLLLoader(const char* libName) : h_inst(LoadLibrary(libName)) { };
    ~DLLLoader() {
      if( h_inst )
        FreeLibrary(h_inst);
    };

    DLLLoader(const DLLLoader&) = delete;
    DLLLoader& operator=(const DLLLoader&) = delete;

    DLLLoader(DLLLoader&& rhs) : h_inst(rhs.h_inst) {
      rhs.h_inst = HMODULE(0);
    };
    DLLLoader& operator=(DLLLoader&& rhs) {
      h_inst = rhs.h_inst;
      rhs.h_inst = HMODULE(0);
      return *this;
    };

    template <typename FuncPtrType>
    FuncPtrType GetProcAddress(const char* procName) const {
      return (FuncPtrType)(GetProcAddress(h_inst, procName));
    };
};

And then, you can create a DLLLoader object either by itself or wrapped in any smart-pointer you like. Like, for example:

boost::shared_ptr<DLLLoader> spDLL(new DLLLoader("DllMain.dll"));

// get the function pointer
CreateFoo = spDLL->GetProcAddress("CreateFooClassInstance");

There is absolutely no difference between the two. Personally, I prefer int* var because it keeps the variable name clean and the type definition together. But this is merely a matter of personal preference, i.e., it's esthetics. But functionally, it makes no difference at all.

I just wanted to point this out. There is a very important error in the truth table that you posted, it should be this:

A B C D Y
0 0 0 0 0
0 0 0 1 0
0 0 1 0 0
0 0 1 1 0
0 1 0 0 1
0 1 0 1 1
0 1 1 0 1
0 1 1 1 1
1 0 0 0 0
1 0 0 1 0
1 0 1 0 0
1 0 1 1 0
1 1 0 0 1
1 1 0 1 1  <--- notice this line (compared to original)
1 1 1 0 1
1 1 1 1 1

Without that correction, there is no way that this could work. And with the correction, it becomes pretty obvious that only A and B matter, so, concentrate on that.

@TheDude: How is it possible that with the name you bear you didn't name "The Big Lebowski" in your list?

4) The Toy - 1982

It's one of the least terrible Hollywood remake, but the original French version is still much better.

9) The Girl with the Dragon Tattoo series of films (originals not the dog-aweful Hollywood waste of time)

They did do a pretty good job with those movies (especially Noomi Rapace as Lisbeth Salander), but if you like the series you really need to read the books (if you haven't already), there are so many more dimensions to the story in the books than what they could transpose to the movies. And yeah, I agree, the Hollywood version was, again, a complete betrayal of the original material.

Ok, now for my own top 10, I can't rank them in a particular order, and I'm sure I'm leaving out some, cause it's really hard to narrow it down like that. Here goes nothing...

1. Three Amigos (1986, ... don't ask why)
2. A Fistful of Dynamite (1971, Sergio Leone, Western)
3. Du Levande ("You, the Living", 2007)
4. Scent of a Woman (1992)
5. The Great Escape (1963)
6. V for Vendetta (2005)
7. A Clockwork Orange (1971)
8. The Shawshank Redemption (1994, no top 10 can be without it)
9. The Big Lebowski (1998)
10. The Godfather, Part II (1974, again, not very original, but eh)

Honorable mentions: Fargo, Apocalypse Now!, Scarface, Goodfellas, Le Diner de Cons, In Bruges, Donnie Darko, Gran Torino, …

17 people called Sky TV about SkyDrive
x time required to say "Sorry sir/mam, SkyDrive is run by Microsoft, please call them."
<= 5 minutes of lost employee time for Sky TV

Why this would make it to court == a complete mystery.

I wonder if any of these people also asked if they could only access their cloud storage on cloudy days or if it still worked on a sunny day.

A long time favorite of mine is "nincompoop". I just think it is such an odd word, by sound and purpose. I don't know if anyone ever uses it. I like odd words, like "vichyssoise" which I use from time to time in formal writing too (in the figurative sense, not to describe a kind of soup).

although many power supplies have limiter circuitry (fuse or circuit breaker) that can limit the damage to the system.

It's not really a matter of having fuses or breakers, but some do have those as an extra protection (usually a fuse.. but it is sometimes soldered into the board!?!? Tell me what's the purpose of a soldered fuse!!). What I was referring to was the fact that an AC to DC converter (commonly known as a power-supply) work through induction through a magnetic core (a lump of iron), which is why they are so heavy, and a series of large capacitors. But basically, you have a part of the circuit on the "AC side" and part of the circuit on the "DC side", and energy is transferred via the magnetic core. Normally, if a competent engineer designed the power-supply, a power surge on the AC side should not cross over to the DC side, meaning that the AC circuitry will fry, while the DC circuitry (and all the computer components connected to it) will not feel much except a sudden shutdown when the AC side is busted. So, usually, good power-supplies that have a fuse, have it mainly to protect the AC side from frying. A good power-supply will have both of these features because a fuse cannot protect from everything (like electric resonance).

A simple way to guarantee that the DC side is protected is to design the magnetic core to be just the right size such …

We have a little quirky thing here (in Canadian-French), and I'm not sure if it's common elsewhere, or other languages. It's the use of the third person instead of the first or second person. It's basically talking about yourself in the third person, like this:

John (comes up to Paul): Hi, how's he doing today?
Paul: He's doing fine. But he's really busy at work these days.
John: He's not about to burn out, is he?
Paul: No, no, he'll be fine, he just gotta get his boss off his back.
..

where Paul is talking about himself this whole time. This is somewhat common here in popular speech (i.e. lower-class). I don't think I've heard it elsewhere (in the "French world", or in English). Ever heard something like that?

Well, I always sound pretentious anyways, so I'll keep using "one". ;)

"This is my friend."

Strangely enough, we have the same problem in French if you say: "C'est mon amie." Where "amie" is feminine but the "e" is silent and the article "mon" is masculin (used because "amie" starts with a vowel).

In my language we use a suffix to point that out. To me this is a bit confusing in English.

Yeah that's true. It's nice to have a built-in cue about the gender of the person being talked about. Otherwise, there are these awkward little moments like when you talk back and you either make a guess with a 50% chance (and maybe seem like you're making a skewed presumption, like a "nurse" is a "she"), or you have to ask "is it a guy or a girl", often leaving the impression that it's a big deal, even though all you want is to be able to use the right pronoun.

In French, it's kind of half-way, most professions and stuff like that have both forms (masc/fem), but sometimes, the feminine form sounds exactly the same (e.g., "auteur" / "auteure", "ami" / "amie"), or one of the forms doesn't exist (e.g., a male secretary is still "une secrétaire" (feminine) because the masculine form is a piece of furniture).

I have to use "he" or "she",

I'm curious what people think here, I've seen many people write using "she" and "her" when the gender is unknown or undefined. I often find this odd, I …

Open the computer and assess the damage. If it blew up and puffed smoke, then you should see evidence of burning, hard to miss.

Now ive noticed that the voltage switch was on 115v instead of 230v.

I think you meant the other way around.. anyways, that difference in voltage will certainly cause an overload. Fortunately, if that new computer is not complete garbage quality, the power supply will have protections against overloading the motherboard. Usually, power supplies act as an electrical buffer. A full explanation of this would be too long, but long story short, the damage should be limited to the power supply (unless the power supply is of extreme poor quality).

I am almost 100% sure that replacing the power supply is going to fix it. At least, it's worth a try.

Just one thing to make sure it, have you disabled back-face culling? It's a common mistake that can cause faces to not be drawn just because the vertices are wound in the wrong direction (cw / ccw).

Other than that, it is hard to see a problem with a partial piece of code. I think you should try to make a very simple model file (only a few triangles), and then, step through the loading using a debugger to see if it gets loaded correctly, and to see exactly what happens when it gets drawn.

Dell is alright for desktop computers, they have good bargains and you can hand pick it all.

However, Toshiba is far superior on laptops. They build really solid machines, and their consumer service is great. At least, that's been my experience, a grain of salt.

From the prints, it seems that your sorting function sorts the number in decreasing order, but your binary search function assumes that the array is sorted in increasing order (from lowest to highest). You need to reverse the logic in one of these two methods if you want things to work.

1.) It does still show all the FooX classes to the user, which also makes the doc more complicated.

That's not true, in the factory pattern, the user only sees the IFoo class. The FooX classes are encapsulated in the cpp file where the factory function is defined, and are thus not in any header and don't need to be distributed with your library, and are not visible to the user at all. The only class that the user has to interact with is IFoo.

2.) We want to add higher level, common functions to Foo - and not to IFoo!

Like I said, if this is the case, use the wrapped pattern.

Again the reason being the doc: we dont want the user to see IFoo.

If you look at the wrapped pattern, you will see that there is no particular need for IFoo to be exposed at all. A simple forward-declaration will do the trick:

In foo.h:

#ifndef MY_LIB_FOO_H
#define MY_LIB_FOO_H

#include <memory>

class IFoo; // <- forward declaration.

class Foo {
  private:
    std::unique_ptr<IFoo> p_impl;
  public:
    void foo() const;

    Foo(int impl = 1);
};

#endif

In foo.cpp:

#include "foo.h"

class IFoo {
public:
    virtual void foo() const = 0;
    virtual ~IFoo() { };
};

class FooA : public IFoo {
public:
    void foo() const {
        cout << "Implementation specific foo A!!" << endl;
    }
};

class FooB : public IFoo {
public:
    void foo() const {
        cout << "Implementation …

Some USB drives have a physical switch on them to enable a read-only lock. Make sure that your USB stick is not one of those, and if it is, then make sure the read-only lock is in the "off" position.

Other than that, are you having trouble following the steps that you quoted? Or did they fail? It's not clear to me.

That is a nice little find. I didn't know that shared-ptr had this behavior built-in. But now that I think about, it makes perfect sense. One of the required features of shared-ptr is to be able to share ownership of one object through different shared-pointers which could be different kinds of pointers (to different base classes or data-members), so, there needs to be mechanisms included within the shared-ptr implementation to keep track of the original raw-pointer type (and value) that the very first shared-pointer was created with, and only delete that pointer. This is how you get the correct destructor called, as long as you create the shared-pointer with a raw pointer of the most derived type (which is usually the case).

But still, that doesn't mean that you shouldn't make the destructors virtual in the base class. It's an oddity, i.e., an artifact of the implementation of shared-ptr. And in any case, the existence of one way to create and use derived-class objects safely (even without a virtual destructor), does not make it "safe", because there were already plenty of ways to do this, it's the presence of all the very easy ways to have broken code as a result of a non-virtual destructor that make it unsafe, and those have not gone away.

I was pretty shocked that was even possible..

Oh.. this is easy. It's a simple type-erasure technique. It certainly adds overhead to the implementation, and this is why shared-pointers are expensive compared to …

I baught a samsung notebook windows 8 but it seems so laggy and I hate pc's so my dad wanted to take it to work.

If you have a PC, but hate Windows and want a good and performing development environment, then you should just install a Linux distribution on your PC. It will be much better, faster and nicer for development than a Mac, and much cheaper, obviously.

How can I ask my mom or convince my mom to buy a mac.

I'm not sure you really should. If your mom is the one who is supposed to have the money to buy it, then you have to respect her decision if she says no. You can do as rubberman suggested, try to struck some sort of deal (e.g., doing chores, getting it if you get good enough grades at the end of the year / semester, etc.).

triumphost is correct about the destruction. The destructors of the FooA or FooB classes will never be called in your code. Instead, only the (default) destructor of the IFoo class will be called. You need to create a virtual destructor in the IFoo class:

class IFoo {
public:
    virtual void foo() const = 0;
    virtual ~IFoo() { };
};

The thing is, the problem is not about the destructors being "deleted" in the derived classes, but rather that the derived-class destructors are unreachable from the destruction (through delete in this case) through a base-class pointer. If the base-class destructor is not virtual, then when you destroy a base-class object, it calls the base-class destructor (default or not) directly. In other words, it won't call the derived-class destructor, as it should. You need the base-class destructor to be virtual for the destruction to be dispatched to the correct "most-derived" destructor.

As for your general problem, I'm not exactly sure what you hope to achieve. From what I understand, you want to encapsulate the existence of the FooX classes. I would not recommend the template version, just because you don't really gain anything from doing this, all you are doing is changing the name of the classes that the user sees, i.e., instead of seeing FooA, the uses sees Foo<FOO_A>, which doesn't seem particularly helpful as it does not provide encapsulation ("hide what it really is") nor polymorphic construction ("construct whatever is appropriate").

I would say, you can either go …

diafol is right:

"tu": singular "you" (2nd person)
"vous": plural "you" (2nd person) and formal singular "you"

And it's true that there is an on-going debate about the use of the formal "vous" for people that you don't know or that you want to keep some sort of formal distance from (like your boss or your clients, or some other people you don't want to be too familiar with). It's a mark of respect, but also a mark of distance, and conversely, not using it (using "tu" instead) could be seen as disrespectful, but could also be seen as welcoming or warm. I'm not sure if it will ever disappear completely. I don't use "vous" too much, but sometimes (especially with the elderly) I use it just to make sure that they feel "respected". But there is a trend of using the formal form less and less.

Many other languages have this thing too. In Spanish, there is "tu" and "usted" with the same usage as "tu" and "vous". In German, they have "du" for "you" (singular, informal), and "Sie" (with a capital letter) for the formal 2nd person, but it is actually conjugated like the "sie" of the plural 3rd person. Swedish only recently dropped the formal person, and is rarely used. Here is a table about this distinction.. you will quickly see that a lot of languages have this. English is an exception, not the rule, it seems.

Among other things, I could never …

Whom seems to be disappearing from common usage over here (UK).

I don't understand.. Who seems to be disappearing? I'm asking you, who is disappearing? ... just kidding.

English lost almost all its inflecions except for some sporadic words like "Who / Whom ..." or "while / whilst", and things like that. It really doesn't make sense to keep only a few archaic inflections. They should just be gone, all gone. Are people supposed to learn about grammatical functional cases just so that they can understand these few inflections and disregard it everywhere else where the inflections have disappeared? Seems like a waste and an irritant.

I hate English verb tenses because they tend to reuse the same word a lot.

Really?!? Try learning French, and then, tell me if you still hate English verbs for being too much the same all the time. French has different transformations (inflections) of the verbs for pretty much every single combination of persons, tenses (present, past, future), moods (indicative, conditional, subjunctive, imperative, participle, infinitive), and voices (active, passive, pronominal), plus a ton of irregular verbs (just a few hundred!). So, don't complain about English conjugations being "too simple". The mandatory 13 years of French grammar in school was no joke... more like torture. Part of the reason I like English grammar is that it's so simple, like child-play, easy to grasp and easy to play with and appreciate.