Searched full:foo* (Results 76 - 100 of 234) sorted by relevance

12345678910

/gem5/src/
H A DDoxyfile788 # The HTML_FOOTER tag can be used to specify a personal HTML footer for
790 # standard footer.
792 HTML_FOOTER = doxygen/footer.html
803 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
/gem5/src/gpu-compute/
H A Dwavefront.hh96 * int foo(int arg1, double arg2)
/gem5/tests/test-progs/asmtest/src/riscv/isa/rv64ua/
H A Dlrsc.S30 la a0, foo; \
37 la a0, foo; \
45 # have each core add its coreid+1 to foo 1024 times
46 la a0, foo
66 lw a0, foo; \
84 foo: .word 0 label
/gem5/ext/googletest/googlemock/docs/
H A DCheatSheet.md9 class Foo {
11 virtual ~Foo();
18 (note that `~Foo()` **must** be virtual) we can define its mock as
22 class MockFoo : public Foo {
68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
88 MockFoo foo; // #2
90 ON_CALL(foo, GetSize()) // #3
94 EXPECT_CALL(foo, Describe(5)) // #4
99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
258 1. a native array passed by reference (e.g. in `Foo(cons
[all...]
H A DCookBook.md8 readability, it is recommended to write `using ::testing::Foo;` once in
9 your file before using the name `Foo` defined by Google Mock. We omit
25 class Foo {
37 class MockFoo : public Foo {
54 class Foo {
57 // Must be virtual as we'll inherit from Foo.
58 virtual ~Foo();
69 class MockFoo : public Foo {
84 class MockFoo : public Foo {
86 using Foo
[all...]
H A DDesignDoc.md77 ACTION(Foo) {
84 defines an action `Foo()` that invokes argument #2 (a function pointer)
177 ACTION(Foo) {
201 | `ACTION(Foo)` | `Foo()` | `FooAction` |
238 * They have subtle semantics that easily confuses new users. For example, in expression `_1++ + foo++`, `foo` will be incremented only once where the expression is evaluated, while `_1` will be incremented every time the unnamed function is invoked. This is far from intuitive.
H A DForDummies.md111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?)
113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo
[all...]
H A DFrequentlyAskedQuestions.md85 *os << "the Foo property is " << value.GetFoo();
105 *listener << "the Foo property is " << value.GetFoo();
258 class Foo {
263 class MockFoo : public Foo {
270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
280 `const` modifier is _ignored_. Therefore, the `Foo` base class above
283 class Foo {
294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
322 EXPECT_CALL(foo, Ba
[all...]
/gem5/ext/googletest/googlemock/docs/v1_5/
H A DCheatSheet.md9 class Foo {
11 virtual ~Foo();
18 (note that `~Foo()` **must** be virtual) we can define its mock as
22 class MockFoo : public Foo {
68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
88 MockFoo foo; // #2
90 ON_CALL(foo, GetSize()) // #3
94 EXPECT_CALL(foo, Describe(5)) // #4
99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
235 1. a native array passed by reference (e.g. in `Foo(cons
[all...]
H A DCookBook.md8 readability, it is recommended to write `using ::testing::Foo;` once in
9 your file before using the name `Foo` defined by Google Mock. We omit
25 class Foo {
37 class MockFoo : public Foo {
54 class Foo {
57 // Must be virtual as we'll inherit from Foo.
58 virtual ~Foo();
69 class MockFoo : public Foo {
84 class MockFoo : public Foo {
86 using Foo
[all...]
H A DForDummies.md111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?)
113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo
[all...]
H A DFrequentlyAskedQuestions.md81 *os << "the Foo property is " << value.GetFoo();
101 *listener << "the Foo property is " << value.GetFoo();
254 class Foo {
259 class MockFoo : public Foo {
266 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
272 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
276 `const` modifier is _ignored_. Therefore, the `Foo` base class above
279 class Foo {
290 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
318 EXPECT_CALL(foo, Ba
[all...]
/gem5/ext/googletest/googlemock/docs/v1_6/
H A DCheatSheet.md9 class Foo {
11 virtual ~Foo();
18 (note that `~Foo()` **must** be virtual) we can define its mock as
22 class MockFoo : public Foo {
68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
88 MockFoo foo; // #2
90 ON_CALL(foo, GetSize()) // #3
94 EXPECT_CALL(foo, Describe(5)) // #4
99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
240 1. a native array passed by reference (e.g. in `Foo(cons
[all...]
H A DCookBook.md8 readability, it is recommended to write `using ::testing::Foo;` once in
9 your file before using the name `Foo` defined by Google Mock. We omit
25 class Foo {
37 class MockFoo : public Foo {
54 class Foo {
57 // Must be virtual as we'll inherit from Foo.
58 virtual ~Foo();
69 class MockFoo : public Foo {
84 class MockFoo : public Foo {
86 using Foo
[all...]
H A DForDummies.md111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?)
113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo
[all...]
H A DFrequentlyAskedQuestions.md85 *os << "the Foo property is " << value.GetFoo();
105 *listener << "the Foo property is " << value.GetFoo();
258 class Foo {
263 class MockFoo : public Foo {
270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
280 `const` modifier is _ignored_. Therefore, the `Foo` base class above
283 class Foo {
294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
322 EXPECT_CALL(foo, Ba
[all...]
/gem5/ext/googletest/googlemock/docs/v1_7/
H A DCheatSheet.md9 class Foo {
11 virtual ~Foo();
18 (note that `~Foo()` **must** be virtual) we can define its mock as
22 class MockFoo : public Foo {
68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
88 MockFoo foo; // #2
90 ON_CALL(foo, GetSize()) // #3
94 EXPECT_CALL(foo, Describe(5)) // #4
99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5
253 1. a native array passed by reference (e.g. in `Foo(cons
[all...]
H A DCookBook.md8 readability, it is recommended to write `using ::testing::Foo;` once in
9 your file before using the name `Foo` defined by Google Mock. We omit
25 class Foo {
37 class MockFoo : public Foo {
54 class Foo {
57 // Must be virtual as we'll inherit from Foo.
58 virtual ~Foo();
69 class MockFoo : public Foo {
84 class MockFoo : public Foo {
86 using Foo
[all...]
H A DForDummies.md111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?)
113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed.
115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo
[all...]
H A DFrequentlyAskedQuestions.md85 *os << "the Foo property is " << value.GetFoo();
105 *listener << "the Foo property is " << value.GetFoo();
258 class Foo {
263 class MockFoo : public Foo {
270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier
276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
280 `const` modifier is _ignored_. Therefore, the `Foo` base class above
283 class Foo {
294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`.
322 EXPECT_CALL(foo, Ba
[all...]
/gem5/ext/googletest/googlemock/include/gmock/
H A Dgmock-actions.h55 // To implement an action Foo, define:
56 // 1. a class FooAction that implements the ActionInterface interface, and
58 // const FooAction*.
197 // // Sets the default value for type T to be foo.
198 // DefaultValue<T>::Set(foo);
412 // class FooAction {
423 // MakePolymorphicAction(object) where object has type FooAction. See
471 // MakePolymorphicAction(foo);
473 // PolymorphicAction<TypeOfFoo>(foo);
520 // Foo fo
[all...]
H A Dgmock-cardinalities.h48 // To implement a cardinality Foo, define:
49 // 1. a class FooCardinality that implements the
52 // const FooCardinality*.
H A Dgmock-generated-actions.h829 // 'foo', you can write 'foo_type'. For example, in the body of
838 // ACTION_Pk(Foo, p1, ..., pk) { ... }
843 // FooActionPk<p1_type, ..., pk_type> Foo(p1_type p1, ..., pk_type pk) { ... }
846 // explicitly when invoking Foo(), as in Foo<long, bool>(5, false);
849 // Foo(p1, ..., pk) to a variable of type FooActionPk<p1_type, ...,
922 // EXPECT_CALL(mock, Foo(
[all...]
H A Dgmock-generated-actions.h.pump311 // 'foo', you can write 'foo_type'. For example, in the body of
320 // ACTION_Pk(Foo, p1, ..., pk) { ... }
325 // FooActionPk<p1_type, ..., pk_type> Foo(p1_type p1, ..., pk_type pk) { ... }
328 // explicitly when invoking Foo(), as in Foo<long, bool>(5, false);
331 // Foo(p1, ..., pk) to a variable of type FooActionPk<p1_type, ...,
400 // EXPECT_CALL(mock, Foo(
[all...]
H A Dgmock-generated-function-mockers.h831 // Foo(1);
832 // Foo(2);
833 // Foo(3);
835 // and want to verify that Foo(1) and Foo(3) both invoke
836 // mock.Bar("a"), but Foo(2) doesn't invoke anything, you can write:
838 // TEST(FooTest, InvokesBarCorrectly) {
849 // Foo(1);
851 // Foo(2);
853 // Foo(
[all...]

Completed in 46 milliseconds

12345678910